Category: Routing

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.

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

There are different documents and books which are claiming that Administrative distance for static routes configured using exit interface is 1 and for the static route configured using next-hop IP address Administrative distance is 0.

R1(config)#ip route 20.0.0.0 255.255.255.0 10.10.2.1
R1(config)#ip route 20.0.0.0 255.255.255.0 fastEthernet 0/0

This is not true. Both of them are having AD value of 1. The confusion is coming from the info that directly connected interface has AD of 0, but static route outbound that interface is having the AD of 1.