Category: Networking

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).

The New Way of Generating IPv6 – SLAAC EUI-64 Address Format

There was an old way of generating Interface IPv6 address using SLAAC process (Stateless autoconfiguration). You simply configured that you want SLAAC autoconfiguration and the interface IPv6 was generated by squeezing “FFFE” in hex (11111111 11111110 bits) between two parts of physical MAC address of that interface.

Then, after a while, several comments came to IETF about the use of predictable Interface Identifiers in IPv6 addresses. They were pointing to the ease of correlation of host activities within the same network and across multiple networks. If Interface Identifiers are constant across networks this is negatively affecting the privacy and security of users on that network.

Create or Edit a File on Cisco IOS Flash

There is always the option to edit a file locally on your computer in notepad++ and then upload it to Cisco device.

With this trick, you can write or edit a file from Flash memory directly from Cisco IOS console. If you need it for whatever reason, maybe to change something in the config file or something else, this is the way to do it.

I was using if for my next article lab where I needed a file on the flash with at least 1600 bytes so I can pull it from neighbouring router with HTTP and check some details in new TCP connection. It was faster to just create the file directly on the router flash and not creating it on my laptop and then transferring it with FTP or TFTP.

Link Aggregation – LACP Protocol

EtherChannel enables bundling multiple physical links connecting same devices into a single logical link. I will try to show you how it is configured and how it works.

The issue with one uplink

I made an example with 8 clients connected to two Cisco 3850 switches. For start, those two switches are connected together with 1G copper on Interface Ge1/23. The clients are also connected to 1G ports. In this case, when all of those four clients on the left side start simultaneously sending traffic at full speed to different computers on the right side, they will congest the uplink between switches and some traffic will be dropped.