Year: 2013

EIGRP internals and getting hands dirty in debugging routing adjacency and solving EIGRP neighboring issues.

What is sequence TLV and Conditional Receive CR-mode and CR flag

Couple of days ago I got a strange network behavior in my CCIE lab. Something was wrong between a router and L3 switch connection and there was EIGRP neighbor relationship reset every few minutes. It was happening all the time so I decided to debug a little.

It was looking something like this and I was very confused about it:

*Mar 1 01:00:32.135: EIGRP: Received Sequence TLV from 155.1.1.2
*Mar 1 01:00:32.135: 155.1.1.1
*Mar 1 01:00:32.139: address matched
*Mar 1 01:00:32.139: clearing CR-mode
*Mar 1 01:00:32.139: EIGRP: Received CR sequence TLV from 155.1.1.2, sequence 5
*Mar 1 01:00:32.139: EIGRP: Received UPDATE on FastEthernet0/0 nbr 155.1.1.2
*Mar 1 01:00:32.139: AS 1, Flags 0xA, Seq 5/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1, not in CR-mode, packet discarded
………………………….
*Mar 1 01:10:00.123: EIGRP: FastEthernet0/0 multicast flow blocking cleared

The thing that was happening here is basically just some EIGRP internals doing their job. To be precise this was reliable routing information delivery over both multicast and unicast doing his reliable update delivery.

Normal EIGRP synchronization is done using multicast.

If we have two EIGRP routers that are trying to make initial sync and become neighbors they will intentionally see each other as “laggard” in the beginning. The term laggard is important here as it symbolize a neighbor to witch we are sending EIGRP updates in separate unicast communication.

Why?

If one EIGRP router is sending updates to, let’s say, 5 other neighbors. It will send that update to address 224.0.0.10 and it will include the update sequence number inside. Let’s say Seq=25.

When it sends the update Seq=25 to the network segment it will get ready to send next update with Seq=26 and wait for the acknowledgement of sequence 25 update. The problem is that the router will put newly prepared update Seq=26 onto the transmission lists for all 5 neighbors and it will not send it out to anybody until he acknowledges sequence 25 update from all 5 neighbors. That means that if one of 5 routers does not send back the acknowledgement for Seq=25 update our router will not continue sending multicast update Seq=26 to anybody and he will lose the neighbors after hold timer expires.

This will be a brief article but a good one. It will save you some walking time to server room. I have the need to capture traffic on the switch or on the router several times every week. That action needed from me to be physically near the switch and to configure SPAN port so that I can connect to the switch with my machine and capture some packets with wireshark. Okay, I could use RSPAN to get captured packets to the closest switch but this altogether is not good enough. It’s too time consuming for short packets captures in troubleshooting sessions.

Recently in my CCIE study I came across the info that Cisco IOS is able to capture packets on the device itself and on more interfaces in once. You can later export that capture to your PC and analyze it with wireshark.

You can do it like this

Please note that this article is more or less pure speculation. The fact is that CCIE R&S v5 blueprint will be presented 28th January 2014 on Milan’s Cisco live event everything else is yet to be announced.

From Milan’s Cisco live 28.1.2014 there is an CCIE R&S v5 blueprint event scheduled. When Cisco wants to speak about new CCIE lab blueprint on Cisco live it means that this blueprint will be announced prior to that event (couple of months before). That leads us to the conclusion that there will be new blueprint announcement this month. There is a big possibility that predictions about changes written in my article about CCIE v5 blueprint here should be changed for the lab exam somewhere around April 2014. Everything in details will be described on that event where Cisco will give out all the details of changes in new CCIE lab v5 blueprint.

There was a chance of announcement this summer when I was following Cisco Live in Orlando. After the event went through it was obvious that there was no mentions about the CCIE lab blueprint change. Later I was reading some blogs about Cisco’s way of changing the blueprint. From all of them it’s clear that new blueprint is never announced on some Cisco live event. It’s always discussed in detail in first event after the announcement. We have this situation now. There is a Cisco Live event in Milan, Italy in February and there is an CCIE v5 blueprint event scheduled for 28.2.2014. Based on all those information we are almost sure to see the announcement this month.

I am studying for the exam for 6 months now!?!

For us studying for the lab exam, the old topology and all the topics from v4 are still valid but for how long?

Now that my topology in GNS3 is exactly as in INE Workbook 1 I can share it with you if you don’t want to do all the basic configurations and connections by yourself.

After spending too much money on different rack rentals in the past few months I decided that I will definitely need to try to use GNS3 for simulating my CCIE labs. It will be the only solution if I didn’t want to spend all my money and then have no more left to pay myself trip to Cisco HQ.

After one whole day of struggling with different GNS3 issues I did succeed to configure almost everything. From now I am able to use GNS3 for almost all chapters of my loved INE Workbook VOL.1 and probably VOL.2 also.

There are some things that are not available on GNS3 simulated IOS and I will try to list them below at some point. Other thing that took me some time are that the interfaces are named differently. Cisco Etherswitch Module is added to router in GNS3 order to simulate some basic switch features that is normally not available in GNS3. There is no way to use 0/0 – 0/21 port names on that Etherswitch Module. The interfaces are 1/0 – 1/15 so you cannot do nobrainer paste of config to those “switch” devices. Some serial interfaces are for example Serial 0/0 and in the workbook they are Serial 0/0/0 so this is another one. There are furthermore some other changes to witch interfaces are different devices connected but all the devices now are connected to all other devices exactly as in VOL.1 physical topology. This file down there is prepared for BGP lab chapter of INE Workbook 1. but keep in mind that it can be good for all other parts of the Workbook as the interface configuration is not changed across the Workbook 1 so you just need to modify routing to get started with other chapters.

Do the topology by yourself, you will learn more!

We will speak here about some basics about Forwarding UDP broadcast traffic. If you were wondering what Forwarding UDP broadcast traffic actually is I will try to explain it here in few words.

If you have more that one broadcast domains in your local network, let’s say that you have three VLANs. In normal networking theory it’s normal that broadcast initiated on host inside one VLAN will get to all host inside that VLAN but it will not get across to other VLAN. Typically the broadcast domain border is router or a Layer’s 3 switch VLAN interface. Although this is normal for most of broadcast traffic there needs to be a way to forward some kinds of broadcast traffic across that border. Why? Here’s a simple example. If you use DHCP, and you are, you will probably have hosts in different VLANs and all of them need to get the IP address from DHCP. If Forwarding UDP broadcast traffic didn’t exist it will be needed to have one DHCP server on every VLAN. Remember that DHCP works using broadcast traffic in some of the steps.

Simple DHCP address leasing:

Host that connects on the network will in the first step send broadcast DHCP discover message in order to find where the server is or if the server actually exist. After the HDCP replies with unicast DHCP offer host will one again use broadcast to send DHCP request to server. Server will then acknowledge the IP address leasing with unicast ACK message and that’s it.

Forwarding UDP broadcast traffic