Category: Routing

BFD – Sub-second Failure Detection

If there’s no BFD

If you have two routers directly connected, like here:

In this case, it is normal that one of them will remove the routes learned from the other if the other one goes down completely. It is because the link will go to down state and the routing protocol adjacency will disappear.

If two routers are connected through an L2 device (switch) like down here:

In this case, when one of them goes down, it will not take down the interface of the L3 neighbour (other router) because the switch will still work fine and it will keep the other half of the like up:

If that’s the case, you will depend on routing protocol timers which are the failure detection mechanisms implemented in the routing protocol itself. Routing protocol timers will need to expire in order to bring the router adjacency down and start the convergence to some other path towards the destinations.

Routing protocols timers are not a bad mechanism and they can be tuned so that they detect the failure faster.

EIGRP hello and hold timers can be tuned to get you somewhere around 1 second for failure detection and the start of convergence. With IS-IS and OSPF you can enable fast hello option and this can get also to 1 second for failure detection.

You can probably guess by now that to speed things up the BFD from the title will be the best solution.

Whats is BFD?

To make failure detection fast, like really fast, like sub-second fast you should use BFD. BFD, which is a separate protocol for communication failure detection, uses small overhead probe packets (like smallish hello packets) that are sent many times in a second in order to get you to sub-second detection of communication failure.

MTU and TCP MSS

UPDATE on 20 Aug 2018:
Johannes – @webernetz from blog.webernetz.net pointed to some inconsistency in my numbers considering the Ethernet frame size in this article.

It was mentioned that Ethernet MTU is by default 1522 bytes and further on that the Ethernet MTU is 1500 bytes. The article is now corrected into stating that Ethernet frame is usually 1522 bytes long if VLAN tagging is used or 1518 bytes long without 802.1Q tag. That leaves a maximum of 1500 bytes for the payload which is effectively Ethernet MTU.

thanks, Johannes

sorry
————————————————-

Intro

The largest chunk of bytes that a transport protocol can forward across specific medium is called MTU – Maximum Transmission Unit. If we speak about Ethernet, which is today the most common, he has by default a frame size of 1522 bytes with the payload of 1500 bytes which is the amount of useful data he can carry in a single frame.

The story about MTU is that the MTU of specific protocol basically defines how much payload (or highest protocols headers + their payload) it can carry in its biggest packet, not counting his own headers. Putting more payload into a single packet than the MTU allows will result in fragmentation, the process of slicing the frame into more smaller frames so that they can get through the path.

Ethernet frame

So if we look at the wire and catch a standard Ethernet frame, we will see that he is able to carry 1500 bytes of data (Ethernet default MTU of 1500 bytes) and additional Ethernet header which is 18 bytes (14 bytes in header and 4 bytes in trailer) or 22 bytes when it has 802.1q VLAN tag added inside.

Different MTUs: Interface MTU, IP MTU and TCP MSS

Interface MTU (Ethernet MTU)

The image above is showing different MTU types. It is important for to note that Interface MTU (Ethernet MTU) is the maximum MTU size that a specific hardware port on our network device can forward. In the case of Ethernet (IEEE 802.3) the maximum frame size is 1522 bytes which was raised from 1518 bytes to allow VLAN tagging using 802.1q. Minimum Ethernet frame size can be 64 bytes. After some time, when Gigabit and faster ethernet ports started to appear, jumbo frames were introduced with the ability to increase the interface MTU to 9000 bytes for performance reasons (slightly less header overhead).

Redistribute Static on Juniper & Cisco

In case you wondered how to redistribute static routes into dynamic routing protocol you are at the right place. This is normally a basic thing to do, but I will let you know how to do it in different ways on different vendor devices so it might be interesting.

We will go through few examples of normal static to OSPF redistribution and then see how it can be partially done with only part of static routes using route filters. I’ll do it on Cisco and Juniper devices so we can see what’s the difference.

Cisco

In Cisco CLI, redistribute static is fairly simple thing to do:

Router(config)#router ospf 1
Router(config-router)#redistribute static subnets

But you need to know that this simple command will take all static router available on that router and push them to OSPF and redistribute them to all other routers participating in that OSPF process.

If you want to redistribute just some of the static routes, or in our next example only static route towards the network 10.10.10.0/24 you need route map filtering in redistribution command to reference only that one network:

Source-Specific Multicast Configuration

In SSM, Source-Specific Multicast, things are done differently from standard multicast forwarding. SSM is specifying a group of hosts that are receiving same multicast stream using group IP address and additionally using stream unicast source IP.

In this article it is shown how to configure Source Specific Multicast on Cisco and Juniper equipment.

In standard multicast, forwarding is done using group IP address which is an IP from multicast dedicated range 224.0.0.0/4 (224.0.0.0 – 239.255.255.255) or FF00::/8 in IPv6. Each multicast group IP address is a single address which specifies all hosts receiving a specific stream, streamed towards that group IP address from multicast source. In standard multicast everybody can start to stream with some IP multicast group IP, becoming in that way, the multicast source.

Unable to access Cisco ASA through AnyConnect VPN?

I stepped on this issue few weeks ago. I was implementing a new ASA Firewall solution, first time for me with software newer than version 8.4.2

It seems that all those stories about changes in the NAT logic after that version were true. This is what I found out about ASA packet processing.firewall

Configuration was really straightforward and everything worked fine except one thing. When connected remotely using Cisco AnyConnect I was able to access all devices inside the network (inside ASA firewall), but not the ASA itself. I wasn’t able to connect with SSH nor with ASDM.