Author: Valter Popeskic

ICMP protocol is a bunch of error, queries and response messages that are helping us every day to troubleshoot and manage our networks. At least if you found yourself in a networking engineer role.

Network protocol “ICMP” is known as a control protocol because it is used for the purpose of administration and management within an IP network. Described in RFC 792 ICMP is a vital part of Internet protocol implementations, but it is not holding the application data. It carries the network status information. This protocol is being utilized to provide the details of:

• issues during the core communications and interactions of applications within a network
• network obstacles and congestion
• out-of-the-way hosts accessibility

ICMP e.g. PING utility that is being utilized the Internet control message protocol in order to check out if the distant hosts is reachable and in addition it generates info about round-trip point-in-time. Moreover, TRACEROUTE is a supportive feature of ICMP. This element can spot the intermediate hops in between a specified source machine and an end machine. TRACEROUTE will also give us a way to find where in the middle of the network one hop is blocking the path of the packet being delivered.

ICMP header part organization

Every one ICMP packet will take one header of 8-byte along with a variable-sized section for data. The initial header’s 4 bytes will be unchanging and consistent. And opening byte will be reserved for the type of ICMP while second byte will be kept to store the ICMP code. Consecutively the 3^rd and 4^th bytes serve as the whole message checksum. But the rest of header’s 4–byte can be varied and conditional on the ICMP type plus its code. ICMP4 was introduced for the IP version 4.

IPv6 Anycast Address

Anycast is basically the same on IPv4 and IPv6 so this part below refers to both.

As the name says it’s an address that can exist more than once anywhere in the network. If we look public IP space that’s available on the Internet, anycast IPv6 address can exist on multiple places all over the Internet. This kind of address is basically enabling us to have servers and services physically closer to us as they would be if the unicast address was used. It this way we are able to have, for example, a server with one anycast IP address somewhere in US and other server with same service and same IP address somewhere is Europe. If I am in Europe, closest server with that IP address will handle my request. Without to much additional technology solutions my service will automatically be resolved to server who is closer to me and it will probably also improve service security and speed. All that is called load balancing and can be accomplished by different networking solutions and technology designs but anycast addressing is basically the simplest method possible to enable this kind of “geo” localization for a service.

How anycast works?

As said before anycast addresses are called anycast because one address can be assigned to multiple interfaces inside the same network. Packets that are going to anycast IP destination address will be caught by nearest device. Today’s anycast IP addresses are used on some special routers and the most important thing that runs them is Global Internet’s DNS root servers service. Google also rely on anycast for all his different solutions and apps like gmail, search and so on.

If you imagine how DNS works you can see why anycast would be used on root DNS servers. You can then have one copy of the same DNS server on each continent. BGP will by himself bring your DNS query to server near you and in that way save you some delay time and bandwidth usage and thus some time.

In IPv6 world, what changes?

IPv6 had from the development phase the intention to support anycast just like described from RFC 1546. (RFC 1546 mentioned below in history section). IPv6 anycast has no special prefix and IPv6 anycast addresses are basically normal global unicast addresses. Each IPv6 configured interface on some device needs to be configured with one anycast address.

There is a big chance that anycast interfaces have no defined region, in that case every anycast entry would need to be propagated throughout the whole Internet. That would probably not scale well so support for that kind of global anycast addresses will be more or less impossible to handle.

If there are regions defined, inside the region devices with same anycast address will only need a separate entry in the routing table.

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?