Booches.nl

NBAR and smart filtering

NBAR (Network Based Application Recognition) is a cool Cisco tool to identify and classify content flowing through a router. You can identify applications as mission critical, business-related, non-critical or unwanted. Once these mission critical applications are classified they can be guaranteed a minimum amount of bandwidth, policy routed, and marked for preferential treatment. Non-critical applications including Internet gaming applications and MP3 file sharing applications can also be classified using NBAR and marked for best effort service, policed, or blocked as required.

In the following example you will see how to block access to YouTube and block the extension .exe. I will block the content when it tries to “enter” the router on the internal interface Vlan1. To start with you need to enable NBAR on the interface.

RTR#configure terminal
RTR(config)#interface Vlan 1
RTR(config-if)#ip nbar protocol-discovery

Create a class-map to identify the content which needs to be blocked.

RTR#configure terminal
RTR(config)#class-map match-any cm-blocked-content
RTR(config-cmap)#match protocol http url “*.exe”
RTR(config-cmap)#match protocol http host “*youtube*”

The following step involves creating a policy-map to block the traffic matching the previous class-map.

RTR#configure terminal
RTR(config)#policy-map pm-blocked-content
RTR(config-pmap)#class cm-blocked-content
RTR(config-pmap-c)#drop

You can also police or shape the identified content so it cannot “consume” all the available bandwidth. The final steps is to apply the policy-map to the internal interface in the input direction.

RTR#configure terminal
RTR(config)#int Vlan 1
RTR(config-if)#service-policy input pm-blocked-content

To verify the operation of NBAR you need to try to browse to the YouTube website or download a file with the .exe extension. Check the operation with the show policy-map interface vlan 1 command, like shown below.

RTR#sh policy-map interface vlan 1 input

Vlan1

 Service-policy input: pm-blocked-content

  Class-map: cm-blocked-content (match-any)
   228 packets, 121574 bytes
   5 minute offered rate 0 bps, drop rate 0 bps
   Match: protocol http url “*.exe”
    9 packets, 7090 bytes
    5 minute rate 0 bps
   Match: protocol http host “*youtube*”
    24 packets, 12813 bytes
    5 minute rate 0 bps
   drop

  Class-map: class-default (match-any)
   111703 packets, 12021043 bytes
   5 minute offered rate 33000 bps, drop rate 0 bps
   Match: any
RTR#

From now on your users aren’t able to browse to YouTube or download .exe files over HTTP. With NBAR you can also block a specific content type, like streaming  media. I use WireShark to retrieve the content-type I would like to block. By following the TCP stream from a WireShark session you can find the exact content-type or other useful information.

Use the match protocol http mime command to classify a content-type. In MIME type matching, NBAR classifies the packet that contains the MIME type and all subsequent packets, which are sent to the source of the HTTP request. This means that the corresponding policy-map should be applied inbound (input) on the external interface or outbound (output) on the internal interface. For MIME type matching, the MIME type can contain any user-specified text string. A list of the Internet Assigned Numbers Authority (IANA)-supported MIME types can be found here.

XS4ALL, Cisco 877 and IPv6

A while ago my ISP XS4ALL started with the distribution of IPv6 prefixes to their customers. So as a network engineer I wanted to have my own /48 prefix. Sadly I didn’t had time to start testing at the beginning of the IPv6 “launch”.

Last week I found some time to start my testing. I started by configuring my external DSL interface to run in dual-stack mode. The IPv4 configuration is straightforward and isn’t part of this article.

Below you see the basic configuration of the Dialer interface to enable IPv6. The commands configure the Dialer interface as DHCP client (autoconfiguration on the interface) and the prefix delegation name is “my_prefix”.

interface Dialer1
ipv6 address autoconfig
ipv6 enable
ipv6 dhcp client pd my_prefix rapid-commit
end

You can check the allocation of the IPv6 address prefix with the following command:

C877W#show ipv6 general-prefix
IPv6 Prefix prefix_ipv6, acquired via DHCP PD
2001:980:3441::/48 Valid lifetime , preferred lifetime
BVI1 (Address command)

More information about the allocation can also be obtained with the following command:

C877W#show ipv6 dhcp interface
Dialer1 is in client mode
State is OPEN
Renew will be sent in 00:11:48
List of known servers:
Reachable via address: FE80::90:1A00:1A1:88E6
DUID: 000200000A4C453332302F373435414333334558322F01
Preference: 0
Configuration parameters:
IA PD: IA ID 0×00100001, T1 3600, T2 5760
Prefix: 2001:980:3441::/48
preferred lifetime 7200, valid lifetime 7200
expires at Jan 31 2011 12:24 PM (4310 seconds)
DNS server: 2001:888:0:6::66
DNS server: 2001:888:0:9::99
Information refresh time: 0
Prefix name: my_prefix
Rapid-Commit: enabled

Now you need to configure IPv6 routing, especially the default route and enabling unicast-routing, with the following commands:

ipv6 unicast-routing

ipv6 route ::/0 Dialer1

The next step involves the configuration of the LAN interface to support IPv6. RFC 3177 recommends the delegation of /48 prefixes to home network subscribers, small and large organizations. It looks like my ISP follows that recommendation. The same RFC states that a /64 prefix should be assigned to different host subnets. So I can configure 2^16 host subnets and each subnet can contain 2^64 IPv6 addresses. Seems enough for my home environment.

The inside interface (a Bridged Virtual Interface in my scenario) is configured with the following /64 prefix.

ipv6 address my_prefix 0:0:0:1::/64 eui-64

You can use the following command to look at the IPv6 configuration of the different interfaces.

C877W#show ipv6 interface brief
BVI1                       [up/up]
FE80::21A:6DFF:FE7D:B684
2001:980:3441:1::FFFF
Dialer1                    [up/up]
FE80::21A:6DFF:FE7D:B684

The basic IPv6 configuration is done. The next step is testing IPv6 connectivity via an IPv6 ping to ipv6.google.com

C877W#ping ipv6 2a00:1450:8005::68 source bvi1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2A00:1450:8005::68, timeout is 2 seconds:
Packet sent with a source address of 2001:980:3441:1::FFFF
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/25/28 ms

Ping can reply with different characters. The characters are listed below.

Prefix Delegation (PD) in IPv6 is very useful when deploying IPv6 in the network. The deployment of IPv6 to hosts also involves the distribution of additional parameters, like IPv6 DNS servers. The next step involves the configuration of Router Advertisement (RA) messages on the Bridged Virtual Interface.

I configured an DHCPv6 pool and configured the BVI interface as DHCP server interface with the following commands:

ipv6 dhcp pool ipv6_inside
dns-server 2001:888:0:6::66
domain-name booches.nl
!
interface BVI1
ipv6 address my_prefix 0:0:0:1::/64 eui-64
ipv6 nd other-config-flag
ipv6 dhcp server ipv6_inside rapid-commit
end

The other-config-flag sets the O-bit in IPv6 RA messages to inform hosts that they can use autoconfiguration for their IPv6 configuration. This results in DHCPv6 INFORMATION-REQUEST messages from the hosts to the DHCPv6 server. The router will reply to these message, because it is configured as DHCP server for the prefix.

I started testing, but my hosts didn’t receive any IPv6 address and debugging IPv6 on the router didn’t output any useful information. Of course the hosts couldn’t receive any IPv6 address, because of the well-known bug CSCej50923 (CCO ID required) on BVI interface routing, which does not work for IPv6 addressing. I didn’t want to upgrade my router directly, so I created another VLAN with the appropriate Switched Virtual Interface. I configured the same commands as under the BVI interface, but this time with prefix 0:0:0:2::/64. Now I have 3 interfaces enabled for IPv6 addressing, like shown below:

C877W#show ipv6 interface brief
BVI1                       [up/up]
FE80::21A:6DFF:FE7D:B684
2001:980:3441:1:21A:6DFF:FE7D:B684
Dialer1                    [up/up]
FE80::21A:6DFF:FE7D:B684
Vlan2                      [up/up]
FE80::21A:6DFF:FE7D:B684
2001:980:3441:2:21A:6DFF:FE7D:B684

You can see the difference in the prefix between BVI1 and Vlan2. I issued a ipconfig /release6 and ipconfig /renew6 on the hosts and IPv6 is working like a perfectly.

The complete output of the ipconfig /all and a ping to ipv6.google.com can be found below.

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix  . : booches.nl
Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
Physical Address. . . . . . . . . : 00-25-64-F6-1C-D7
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2001:980:3441:2:c527:8966:a47f:55d2(Preferred)
Temporary IPv6 Address. . . . . . : 2001:980:3441:2:cd4d:b38b:e861:f43(Preferred)
Link-local IPv6 Address . . . . . : fe80::c527:8966:a47f:55d2%11(Preferred)
IPv4 Address. . . . . . . . . . . : 10.10.2.2(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Monday, January 31, 2011 4:02:01 PM
Lease Expires . . . . . . . . . . : Thursday, February 03, 2011 4:02:00 PM
Default Gateway . . . . . . . . . : fe80::21a:6dff:fe7d:b684%11
10.10.2.1
DHCP Server . . . . . . . . . . . : 10.10.2.1
DHCPv6 IAID . . . . . . . . . . . : 234890596
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-13-65-AE-74-00-25-64-F6-1C-D7

DNS Servers . . . . . . . . . . . : 2001:888:0:6::66
10.10.2.1
NetBIOS over Tcpip. . . . . . . . : Enabled
Connection-specific DNS Suffix Search List :
booches.nl

C:\Users\RJN>ping ipv6.google.com

Pinging ipv6.l.google.com [2a00:1450:8005::68] with 32 bytes of data:
Reply from 2a00:1450:8005::68: time=29ms
Reply from 2a00:1450:8005::68: time=25ms
Reply from 2a00:1450:8005::68: time=25ms
Reply from 2a00:1450:8005::68: time=26ms

Ping statistics for 2a00:1450:8005::68:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 25ms, Maximum = 28ms, Average = 26ms

Policy-based routing in a nutshell

Lately I received some questions about routing decisions and how to influence the routing decisions via access control lists. The following example shows a simple configuration for policy-based routing. The example uses the following logical setup:

I configured two routers and connected each router to two PVC’s on the same ATM interface. I configured one subnet per location. All normal traffic is router through PVC #1, but all traffic to or from the servers in the picture should be routed to PVC #2.

The top router has SVI VLAN 1 configured to connected to the inside LAN. The first step in configuring policy-based routing is defining which traffic should be routed over PVC #2. I configured the following access-list.

ip access-list extended acl-pbr
permit ip 10.10.10.0 0.0.0.255 host 192.168.1.100
permit ip host 192.168.1.100 10.10.10.0 0.0.0.255

Next you need to configure a route-map with a “match” statement and configure the appropriate “set” conditions.

route-map rm-pbr permit 10
match ip address acl-pbr
set ip next-hop <PVC #2 IP address>

The last step is applying the configured route-map to the correct interface. As stated before, we are using SVI VLAN 1.

interface Vlan1
ip address 10.10.10.254 255.255.255.0
ip policy route-map rm-pbr

As you can see, configuring policy-based routing is very simple, and yet very powerful.

One issue is when testing policy-based routing from the router. By default, locally-generated packets are not inspected by outgoing access-lists. To enable local packets from being re-entered into the router, you should issue the ip local policy route-map <rm-name>.

ISDN Backup – still alive?

Nowadays everybody wants redundancy within their network, especially when using remote sites. Customers are using multiple ISP’s for redundancy and/or configure BGP solutions. In the old days (hear me talking with my 27 years) ISDN was often used for backup purposes and I still use it sometimes as redundancy mechanism. Everybody knows that bandwidth is the main limitation for ISDN connections, but for emergency purposes or for low-bandwidth applications, ISDN could be the ideal backup mechanism.

Lets take a look at the scenario, where two networks (HQ and branch office) are connected by an IP VPN connection. This connection is the primary channel for communication between the HQ and the branch office. The IP VPN connection is terminated by a Cisco router or something comparable. Both locations also have a backup connection based on ISDN technology. The ISDN connection is also terminated on a Cisco router. You can also terminate both connections on the same router, but to increase the availability you should use separate routers. The IP VPN is preferred over the secondary ISDN connection. Both routers within the same location are configured with HSRP and the IP VPN router is the active gateway for its LAN.

The failover from the primary to the secondary connection should be performed automatically. This requires at least the configuration of a routing protocol. Since I often use Cisco routers, I would configure EIGRP as routing protocol to exchange routing information. You could also choose to use OSPF. Choosing EIGRP or OSPF as the preferred routing protocol could be worth a blog post on its own.

To form an adjacency between to routers, both routers need to be neighbors of each other. I normally configure a GRE tunnel between the two IP VPN routers, so they become “directly connected”. Both IP VPN routers can now exchange routing information. Next I would configure the dial-up connection. Mostly all traffic is directed from the branch office to the HQ, so the branch office would dial the HQ.

The ISDN router could participate in the EIGRP process. If you do so you need to exclude the EIGRP packet from the ISDN interesting traffic to prevent the ISDN connection from dialing to the HQ. There are more choices to make, like letting the ISDN routers form adjacencies when the ISDN connection is active. You can also use floating static routes on the ISDN routers and redistribute these routes into the routing protocol. You can tweak the HSRP operation by using HSRP tracking to promote the ISDN router to the active default gateway, when the IP VPN connection is unavailable.

In my opinion ISDN connections could still be a very valid way to provide a backup connection between two network locations. What is your opinion about this technology?

Huh? Interface SSLVPN-VIF0?

While checking interface statistics on a Cisco 3845, I noticed the following layer 3 interfaces.

Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         74.124.155.67   YES NVRAM  up                    up
GigabitEthernet0/1         10.10.10.1      YES NVRAM  up                    up
GigabitEthernet0/0/0       unassigned      YES NVRAM  administratively down down
SSLVPN-VIF0                unassigned      NO  unset  up                    up
Tunnel0                    192.168.255.2   YES NVRAM  up                    up

I can explain all interfaces, except the SSLVPN-VIF0 interface. I tried to look at the internet, but that didn’t result in any useful information. I used Cisco’s Output Interpreter, but that didn’t help either.

INFO: The following interfaces show the interface configuration ‘method’ as ‘unset’. SSLVPN-VIFO This means that no configuration changes were made to the interface since the last reload.

I noticed the same interface on a Cisco 1811 router, but not on the Cisco 871 and Cisco 878 routers. The interface cannot be related to SSL VPN functionalities, because that feature isn’t configured on the routers. At least that was what I thought at first. I checked my home router, because it has SSL VPN configured and found that the SSLVPN-VIF0. As the abbreviation implies, SSLVPN-VIF0 stands for “SSLVPN Virtual Interface 0”.

An IP address is assigned to the interface, after establishing a SSLVPN connection. You can retrieve more information about the SSLVPN-VIF interface by using multiple show interface SSLVPN-VIF commands. An example is shown below:

router#show interface SSLVPN-VIF 0 switching
SSLVPN-VIF0 ***Internally created by SSLVPN context home***

Protocol  IP
Switching path    Pkts In   Chars In   Pkts Out  Chars Out
Process         26       2657          4        240
Cache misses          0          -          -          -
Fast          0          0          0          0
Auton/SSE          0          0          0          0

NOTE: all counts are cumulative and reset only after a reload.

So don’t panic when you see the SSLVPN-VIF0 interface on your router. You now know where it is coming from.