Booches.nl

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.

The table displays the POST detail settings:

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.

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.

Policy NAT on Cisco router

A colleague of mine had to implement an IPSec VPN tunnel from a customer to a supplier. The customer has a Cisco router for connecting to the Internet, so nothing special. The router is already setup and in production. Configuring an extra IPSec VPN tunnel isn’t very hard, the most important part is the negotiation of Phase 1 and Phase 2 credentials for the IPSec VPN connection.

This particular situation was different, because the customer has to NAT his local IP addresses into the VPN tunnel. I don’t actual configure this quiet often on routers, but more on firewalls. I setup a testing environment with GNS3 to do my own configuration.

The testing environment is displayed below. When connecting from the LAN from R1 (10.1.1.0/24) to the Internet normal NAT overload in configured. In the picture the network behind R3 represents the Internet. When connecting from R1 to R2, the source IP address (Inside Local) is translated to an address from the pool 10.22.44.0/24 (Inside Global). There is also a static NAT mapping for IP address 10.1.1.222 into the VPN tunnel (10.22.44.222).

At first I configured the environment like showed above. I configured the different interfaces and the corresponding IP addresses. Router R1 and R2 use router R3 as default gateway. The configuration of the specific routers is attached at the end of the post.

The first snippet shows the necessary NAT configuration on R1 for the Internet connection.

interface Loopback0
description INSIDE
ip address 10.1.1.1 255.255.255.0
ip nat inside
!
interface FastEthernet0/0

description OUTSIDE
ip address 212.123.212.9 255.255.255.248
ip nat outside
duplex auto
speed auto

!
ip nat inside source list ACL-NAT interface FastEthernet0/0 overload
ip route 0.0.0.0 0.0.0.0 212.123.212.11
!
ip access-list extended ACL-NAT
permit ip 10.1.1.0 0.0.0.255 any

When trying to ping Lo0 on router R3, I see the following NAT table on router R1.

R1#ping 192.168.3.1 source lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/46/76 ms
R1#sh ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 212.123.212.9:3   10.1.1.1:3         192.168.3.1:3      192.168.3.1:3

This proves that regular NAT overloading works perfectly with the current configuration. Next I configured the Policy IPSec VPN between routers R1 and R2. The configuration isn’t that spectacular, you should pay attention to the NAT statements and ACL statements. I even configured reverse route injection for the LAN network of R2. When enabling reverse route injection a route with the remote network (172.16.2.0) pops up in the routing table. This feature can be used when redistributing static routes into a routing protocol like EIGRP.

Next I will show some snippets, with some comments, of the configuration of router R1.

\\ Specifying the Phase I and Phase II properties for the IPSec VPN

crypto isakmp policy 10
encr aes 256
authentication pre-share
group 5
crypto isakmp key VPN@Booches address 212.123.212.10
!
crypto ipsec transform-set VPN-TS esp-aes 256 esp-sha-hmac
!
crypto map CM-VPN-R2 10 ipsec-isakmp
set peer 212.123.212.10
set transform-set VPN-TS
match address VPN-R2
reverse-route

!

\\ Loopback interface with 2 IP addresses for testing purposes

\\ Secondary IP address is used for static policy NAT testing

interface Loopback0
ip address 10.1.1.222 255.255.255.0 secondary
ip address 10.1.1.1 255.255.255.0
ip nat inside

!

\\ Outside interface with the crypto map applied to this interface
interface FastEthernet0/0
description OUTSIDE
ip address 212.123.212.9 255.255.255.248
ip nat outside
duplex auto
speed auto
crypto map CM-VPN-R2

!

ip nat translation timeout 30

\\ NAT pool for dynamic policy NATZ
ip nat pool LAN-R2 10.22.44.1 10.22.44.254 netmask 255.255.255.0

\\ Default NAT for regular Internet related traffic
ip nat inside source list ACL-NAT interface FastEthernet0/0 overload

\\ NAT statement for dynamic policy NAT and static policy NAT
ip nat inside source list ACL-POLICY-NAT pool LAN-R2 overload
ip nat inside source static 10.1.1.222 10.22.44.222 route-map RM-STATIC-NAT extendable

!

\\ ACL to define traffic to be NATted for regular Internet related traffic

ip access-list extended ACL-NAT
deny   ip 10.1.1.0 0.0.0.255 172.16.2.0 0.0.0.255
deny   ip 10.22.44.0 0.0.0.255 172.16.2.0 0.0.0.255
permit ip 10.1.1.0 0.0.0.255 any

\\ ACL to define traffic to be dynamic policy NATted into IPSec VPN tunnel
ip access-list extended ACL-POLICY-NAT

deny   ip host 10.1.1.222 172.16.2.0 0.0.0.255
permit ip 10.1.1.0 0.0.0.255 172.16.2.0 0.0.0.255

\\ ACL to define traffic to be static policy NATted into IPSec VPN tunnel
ip access-list extended ACL-STATIC-POLICY-NAT
permit ip host 10.1.1.222 172.16.2.0 0.0.0.255

\\ ACL to define interesting traffic for the IPSec VPN tunnel
ip access-list extended VPN-R2
permit ip 10.22.44.0 0.0.0.255 172.16.2.0 0.0.0.255
!

\\ Route map static to configure static policy NAT statement
route-map RM-STATIC-NAT permit 10
match ip address ACL-STATIC-POLICY-NAT

I issued some ping commands and looked at the IP NAT Translations table to test the environment. The test results are displayed below.

SOURCE 10.1.1.1 (R1) – DESTINATION 172.16.2.1 (R2) & 212.123.212 (R3)

R1#ping 172.16.2.1 source 10.1.1.1
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/52/120 ms
R1#ping 212.123.212.11 source 10.1.1.1
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/48/84 ms
R1#show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 212.123.212.9:29  10.1.1.1:29        212.123.212.11:29  212.123.212.11:29
icmp 10.22.44.1:28     10.1.1.1:28        172.16.2.1:28      172.16.2.1:28

SOURCE 10.1.1.222 (R1) – DESTINATION 172.16.2.1 (R2) & 212.123.212 (R3)

R1#ping 172.16.2.1 source 10.1.1.222
Packet sent with a source address of 10.1.1.222
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/48/84 ms
R1#ping 192.168.3.1 source 10.1.1.222
Packet sent with a source address of 10.1.1.222
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/44/60 ms
R1#sh ip nat translation
Pro Inside global      Inside local       Outside local      Outside global
icmp 212.123.212.9:37  10.1.1.222:37      192.168.3.1:37     192.168.3.1:37
icmp 10.22.44.222:36   10.1.1.222:36      172.16.2.1:36      172.16.2.1:36

 

SOURCE 172.16.2.1 (R2) – DESTINATION 10.22.44.222 (R1)

R2#ping 10.22.44.222 source 172.16.2.1

Packet sent with a source address of 172.16.2.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/53/112 ms

All ICMP testing gave positive results and policy-based NAT on the Cisco router is working perfectly.

Configurations:

• Router R1
• Router R2
• Router R3

Automatic Log In Reverse Proxy with FBA

Recently I configured another ISA 2006 server as reverse proxy to publish the Exchange 2007 OWA environment on a secure way to the internet. The customer where I configured the reverse proxy is migrating from Novell GroupWise to Microsoft Exchange.

During the migration period, the customer has specific requirements when connecting to the webmail environment from the internet. The customer is using GroupWise and OWA next to each other. He build an own log in page for webmail. The user enters this credentials, which are check against a directory with the help of LDAP. Depending on the LDAP group the user is member of, he is redirected to GroupWise webmail or OWA.

The problem was that when the client gets redirected to OWA, he had to provide his credentials a second time to log in to OWA. The customer wants to use Single Sign On, so the user credentials should be automatically posted on the OWA sign in page. The customer has the option to edit his own sign in page, so specific parameters can be added when redirecting the client to the ISA 2006 reverse proxy.

I had to figure out, which URL is posted to the ISA reverse proxy after the user credentials are entered in the web browser. I started to search the internet and different forums, but the solution wasn’t found. So there was nothing else left, than starting the good old sniffer and capture the complete process. I always use WireShark as sniffer, which is a very powerful tool. I added a filter so only the traffic to and from the ISA 2006 server is captured.

I started the sniffer, logged in on the ISA 2006 server, stopped the sniffer and started analyzing the sniffer results. After some digging I found the POST statement, which is displayed below.

Looking at the POST statements, I now knew the exact URL which is posted to the ISA 2006 server. I copied the URL to notepad, changed the username and password to another account. Copied the new URL and pasted that one in my browser and HIEHOE. After hitting enter, I don’t get any sign in page, but get directly to my webmail. So exactly as the customer wants.

The default POST URL has the following format:

https://<DNS name>/CookieAuth.dll?Logon?curl=Z2Fowa&flags=0&forcedownlevel=0& formdir=1&trusted=0&username=<username>&password=<password>
&SubmitCreds=Log+On