Connecting the world…

based

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.

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:

simple-pbrI 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>.

CB-WFQ Bandwidth Allocation

When configuring Quality of Service with CB-WFQ I am always puzzling to get the correct classes. When configuring CB-WFQ it is important to remember that the router does not allow the class queues to consume more than 75% of the total interface bandwidth. The remaining 25% are used for the default class as well as all non-IP packets, like routing protocols.

A quick example shows the problem. I have a router with a 10 Mbps Ethernet interface. I will add a service-policy to this interface and create a priority queue for voice traffic of 8 Mbps.

First I created the class-map and the policy-map:

class-map match-all VOIP
match ip dscp ef
!
policy-map policy-cbwfq
class VOIP
priority 8192

Next I try to apply the policy-map to the interface, but I receive an error-message like shown below:

Router(config)#int fa 0/0
Router(config-if)#service-policy output policy-cbwfq
I/f FastEthernet0/0 class VOIP requested bandwidth 8192 (kbps), available only 7500 (kbps)

The error message clearly tells me that I can use only 75% of the bandwidth for class queues. The router automatically adds a fair-queue configuration to the interface as a fallback.

fair-queue 64 256 256

You can increase the amount of bandwidth for reservation of class queues with the command max-reserved bandwidth. This gives you the opportunity to increase the reserved bandwidth to 90%.

Router(config-if)#no fair-queue
Router(config-if)#max-reserved-bandwidth 90
Router(config-if)#service-policy output policy-cbwfq

The service-policy is now accepted by the router.

Router#sh policy-map interface fa0/0 output
FastEthernet0/0

Service-policy output: policy-cbwfq

Class-map: VOIP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp ef (46)
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 8192 (kbps) Burst 204800 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0

Class-map: class-default (match-any)
23 packets, 2252 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any

A useful with more information (difference between bandwidth percent and bandwidth remaining percent) can be found here.

Juniper SA & GroupWise WebAcc SSO

While configuring a Juniper SA2500 in conjunction with Novell GroupWise WebAccess, the customers wanted single sign on (SSO) configured. The default Novell GroupWise WebAccess login page uses FBA (Forms Based Authentication). So it should be possible to push the correct POST parameters to enable SSO for GroupWise WebAccess.

I started with looking at the page source of the login page and found the POST configuration. You can find them by searching the string:

<form method=”post” action=”/gw/webacc” name=”loginForm” target=”_top”>

I configured a Web Resource Profile in the Juniper SA. This Resource Profile has a bookmark which displays the Novell GroupWise WebAccess page. Next I configured a Form POST Resource Policy. The picture below shows the configuration.

JuniperSA-gwwebacc-sso

The table displays the POST detail settings:

User label Name Value
error error login
User.displayDraftItems User.displayDraftItems 1
merge merge webacc
action action User.Login
Url.hasJavaScript Url.hasJavaScript 1
Low.bandwidth Low.bandwidth 0
User.interface User.interface css
User.Theme.index User.Theme.index 1
Username User.id <USER>
Password User.password <PASSWORD>
User.lang User.lang nl
User.settings.speed User.settings.speed high

The above configuration works in my situation. The user is automatically logged in to their corresponding Novell GroupWise WebAccess page.

Link State Tracking

Last week a friend called me and told me he was having serious problems with his network. A complete blade environment wasn’t able to communicate with the rest of the network. I asked what changed in the network and he told me that he had added a VLAN to a trunk allowed lists.

Because he is a friend, I dialed in and checked the configuration of the switch. I noticed that all ports on the switch were err-disabled. What happened here, that all switch ports were err-disabled!!! I noticed the configuration of link state tracking on all ports.

Link-state tracking, also known as trunk failover, is a feature that binds the link state of multiple interfaces. Link-state tracking provides redundancy in the network when used with server network interface card (NIC) adapter teaming. When the server network adapters are configured in a primary or secondary relationship known as teaming and the link is lost on the primary interface, connectivity transparently changes to the secondary interface.

At first I was skeptic about the link state configuration and asked my friend why it was used. He couldn’t give me any answer, because he didn’t configure the switch. For me it was hard to find a reason why link state tracking was used, because I wasn’t familiar with the network. I removed the link state configuration from the switch. All ports changed to a normal state. I noticed that the uplink (port-channel) configuration wasn’t correct. They added the VLAN to the trunk allowed lists on a member port and not on the port-channel interface.

After helping my friend and dreaming for a couple of days, I started thinking about the Link State Tracking feature. I tried to discover why someone configured the feature in my friends environment. Eventually, after some brain cracking, I found the solution. Let’s look at the following example environment.

LinkStateTracking

The figure shows one ESX server, which has two NIC’s. One NIC is connected to bl-sw01 and the other NIC is connected to bl-sw02. The ESX uses the load-balancing algorithm “Route based on Virtual PortID”.

Now lets assume the link between bl-sw02 and dis-sw02 loses its connection. Because the ESX server still has a connection with bl-sw02, it keeps sending packet that way. Switch bl-sw02 doesn’t have any uplink to the rest of the network, so the packet will get dropped.

When using Link State Tracking the connection between the ESX server and switch bl-sw02 will also loose its connection when the uplink between bl-sw02 en switch dis-sw02 gets lost. The ESX server will only use the connection with switch bl-sw01 to reach the rest of the network. Link State Tracking uses upstream and downstream interfaces. In the example the connection between the switch port, which connects switch bl-sw02 to switch dis-sw02, would be configured as an upstream port. The switch port to the ESX server would be configured as a downstream port. The downstream port is put in err-disable state when the upstream port loses its connection. This is exactly what you would like to accomplish.

The first step to enable Link State Tracking globally on the switch:

bl-sw02(config)# link state track 1

The next step is configuring the upstream and downstream interfaces.

interface GigabitEthernet0/16
description switch-uplink

switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
link state group 1 upstream
spanning-tree link-type point-to-point

!

interface GigabitEthernet0/10
description ESX01

switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
link state group 1 downstream
spanning-tree portfast trunk

You can check the status of the Link State Group with the following command:

bl-sw02#show link state group detail

Link State Group: 1 Status: Enabled, Up

Upstream Interfaces : Gi0/16(Up)

Downstream Interfaces : Gi0/10(Up)

In the future I will use Link State Tracking, especially in blade environments. At least in blade environments with multiple switch, which don’t support some kind of stacking technology, and servers with multiple NIC’s.