Ali Abbas

HSRP stands for “Hot Standby Router Protocol”

RCF 2281 defines in detail HSRP – http://tools.ietf.org/html/rfc2281

The purpose of this post isn’t to dive into the details of HSRP but simply to shed light on an HSRP feature often overlook when setting redundant routers for redundant ethernet path.

HSRP Election

When powering up routers running HSRP, the routers (by default in group 0) starts sending to each other (multicast: 224.0.0.2) hello packets to determine who else is part of the HSRP group. Past that, the routers start an election process based on the router’s set HSRP priority.

The HSRP priority is set by using the command “standby priority <number>”

interface fa0/0
standby priority 80

Keep in mind that the default priority is “100″… that is to say if no “standby priority” command is issue on this interface, this interface would have a priority of 100.

Once the routers elect the active router based on who has the higher priority, the other members of the HSRP group become “passive” routers or in Cisco terms “standby routers”.

What happens if all routers do not have a custom priority set or have the same priority?

If all routers have the same priority, then the router who has the “highest” IP address is elected the active router

A Typical HSRP Setup

As you can guess … the red path references the active router and the path through which the hosts on the LAN would be routed. Now keeping in mind that HSRP is running interface fa0/0 of both routers and that the link on s0/0 from the active router to the ISP would fail (see 2nd figure)

Since the serial link on the active router would fail, traffic would be redirected from the active router to the passive router on the secondary Ethernet interface… so in a nutshell, the active router still remains the active route (fa0/0 never fails) but the computers of the LANs have one more hop to go through to connect to the ISP.

The new path is show in “blue”

While this is not a technical issue in itself, it is possible to have the Virtual IP Address failover to the passive router by “monitoring” the state of the serial interface “s0/0″ and not only the state of fa0/0.

As we said earlier, the process of electing the active router in an HSRP group is to first evaluate the HSRP interface priority and then in case of a tie the highest IP address.

The command to enable interface tracking is

standby track INTERFACE PRIORITY_DECREMENT

So a typical configuration on both routers would look as follow

Active Router
int fa0/0
ip address 192.168.1.100 255.255.255.0
standby ip 192.168.1.1
standby track S0/0 30

Passive Router

int fa0/0
ip address 192.168.1.101 255.255.255.0
standby ip 192.168.1.1
standby priority 90
standby track S0/0 30

On both router’s fa0/0 we have setup “interface tracking” on serial 0/0 with a priority decremental value of 30 – that is to say if s0/0 on the active was to go down, the HSRP priority of fa0/0 would be of (100 – 30) so 70… since the HSRP priority of the passive router is 90, the VIP will then failover to the passive router which will become the active router.

Traffic will then be routed directly through the second router without having to be re-routed through the first router as seen in the 3rd figure.

Hi,

I am pleased to announce that quaggOS in alpha version has been released.

quaggOS is a live linux distribution I created which turns a server/pc into a full BGP/OSPF router. This is achieved by using the Quagga routing solution application.

For more information, visit http://quaggOS.org

To download and test the alpha release, click here

Pre-requiste: Understanding of the 802.1Q Protocol

The purpose of this post is to shed a light on how QinQ Vlan takes place in a bridged network environment.

Before continuing, it is important to keep in mind that 802.1QinQ or 802.1ad isn’t a defined protocol in itself but a mere amendment of the already existing 802.1Q protocol.

Having said that, in a nutshell where a single frame can hold a maximum of 4096 tags, QinQ extends the number of maximum tags to 16777216 tags, thus allowing switches to freely manipulate the tags of a single packet. A typical example where QinQ is used is in bridge networks where each customer’s frame can be easily forwarded through different topology network while appearing to the customer’s as a simple bridge with no frame modification.

That is to say, if a corporation has different offices across a region and wishes to build a single logical lan, the corporation can use QinQ and bridge all its sites through their subscribed network provider, without having to alter the existing vlan infrastructure of the customer.

This as said earlier is achievable through QinQ and S-Vlans. To keep it simple, S-Vlans are just the vlan tags that the frames of a customer gets when entering the vlan space of the Service provider and on which forwarding occurs.

For example

Office A is on vlan 1 —- Provider  — Office B is on vlan 1

For this to work such as the packet from customerA tagged with vlan 1 be tunneled through the ISP’s bridged network, the ISP must work on a different vlan space and assign a specific S-Vlan ID to the coorporation subscribed to its services.

Office A (vlan1) —- Provider (vlan20) — Office B (vlan 1)

When entering the Provider’s bridge, the frame from OfficeA will be tagged with S-Vlan 20 and be forwarded to OfficeB, once the packet reaches the other edge bridge’s endpoint, it is stripped off the S-vlan and enters the office’s B network.

Now what if I have many vlans? Remember, within the Bridged network, the Vlans aren’t looked at, only the S-vlan is looked at… based on the S-vlan, the provider’s switch makes a decision as to which S-vlan switch end point to forward to, to which the customer-network port is assigned. Only once it arrives at the other endpoint, that it is stripped off from the S-vlan tag and the customer’s own switch does the next step forwarding (based on the vlan tags).

I hope that was informative and will clear out a lot of common misunderstanding on QinQ and S-Vlans.

Cheers

Who talks about about TCP throughput unfortunately can’t step away from the congestion problem that often occurs in TCP session connections.

There are many TCP Congestion Algorithms, from Window Sliding to Fast Recovery; In this post I will only focus on the Nagle’s algorithm and how applications can be tweaked to either make use of the TCP delay induced by the Nagle’s algorithm or minimize latency for the sake of real time application.

Nagle’s algorithm

The Nagle’s algorithm was developed to prevent congestion due to tinygrams (small packets); that is to say, the % of IP and TCP headers is considerably larger than the packet’s data (MMS)

Remember

MTU = MSS – 40 bytes (20 bytes IP header and 20 bytes TCP header)

The problem is that application which only generates a small fraction of data (small bytes write) such as remote login (X server) would just generate each time a packet with 40 bytes headers (IP/TCP headers) + x byte data. This overhead including the amount of packets which are therefore generated would start clocking the link, especially on links with limited bandwidth.

If I connect remotely to an X server and move the mouse, that amount of information generated will obviously be quite small and thus generate a subsequent amount of small packets.

The Nagle’s algorithm delays the sending of tinygrams by buffering them till an ACK has been received for a packet with outstanding data sent earlier.

The algorithm is laid as followed

if there is new data to send
if the window size >= MSS and available data is >= MSS
send complete MSS segment now
else
if there is unconfirmed data still in the pipe
enqueue data in the buffer until an acknowledge is received
else
send data immediately
end if
end if
end if

ACK delayed

ACK delayed simply implies that the receiver does not need to acknowledge reception of each segment right after their reception. So instead of sending an ACK for each segment, then at some point later on (once the TCP buffer of the recipient is full), to send an ACK with a 0 value and then an ACK update, the recipient would be able to delay the ACK response and thus in one segment inform the sender of the window size.

It is important to note that the ACK delay should not exceed 0.2 seconds (200 ms)… an increased ACK delayed will therefore highly affect the round-trip timing, as much as no ACK delay will cause a high congestion on the network.

Small Scenario

If I were to send 88000 bytes to a remote host, I would technically be sending (88000/1460) ~= 60 packets + 400 bytes, this is of course excluding the TCP/IP headers

With ACK delayed, an ACK will be sent for each 2nd packet received, so using the Nagle’s algorithm, once the ACK of the 60th packets comes back, the 61th packet (441 bytes) will be sent. Now imagine we had a 62th packet? The receiver would still be waiting for the 62th packet in order to send the ACK… Nagle on the other side would not send the 62th packet unless it receives the ACK of the 61th packet…

Now as you can imagine, we would start hitting a deadlock till the ACK delayed timeout kicks in. Network degradation will be foreseen, especially with real-time application.

The issue

Now what would happen in such case if I were to use a remote X server and move the mouse, well Nagle would make sure your TCP buffer fills up to FULL size before sending a packet with a total delay of 200ms between each sent packet due to Delayed ACK… make the calculation, the lag will be highly noticeable

To prevent using the Nagle’s algorithm, make sure to set TCP_NODELAY in your application configuration.

As simple as this tip is, you will be amazed on how often it is overlooked during remote night maintenance work. I have therefore decided for that reason to post it here.

So, you are sitting at home, editing an IOS configuration of X router during a maintenance window. Your only available remote login is through the wan interface. A bad access list and you can be locked out of the router till you physically go to the office to undo the changes.

It is late and you don’t fancy driving!

Here is a small tip which could save you the hassle

Prior to editing

edge1#reload in 10

Reload scheduled in 10 minutes

Proceed with reload? [confirm]y

Now as you guessed, you just issued the router  to reboot in 10 minutes

Now start editing…

When done, if all is good and all is working as expected, you can then proceed to cancel the scheduled reboot

edge1#reload cancel

The scheduled reboot is now cleared… if you happened to lock yourself out of the router, within the 10mn lapse time from the moment you issued the reload command, the router would reboot with the startup-config and give you access back to your router (assuming of course you didn’t save your running-config changes).

I hope that was informative!