That’s really helpful, thanks Laz!
1 Like
Hi community,
I found out something interesting in cloudshark and I even saw this in my GNS3 Lab I did when I traced neighbor adjacency.
Seems like that the initial Update Packet is Unicasted to it’s Neighbor after receiving a Hello Packet but that Update at that time doesn’t contain any Network Information, only a Flag is set (Init Flag).
The receiver of this seems to Acknowledge this Unicast Update Packet but not with an ACK as i thought it actually will use a Update Packet with the same Flag and also no information about the network yet.
Now the most confusing point is that the actual “Full Update” with all Network Information is sent as Multicast to all EIGRP Listeners (224.0.0.10) with a new Sequence number but later on it is also sent again as Unicast.
The full trace is here:
https://www.cloudshark.org/captures/bdcc74327b71
Can someone explain this trace to me ?
Best regards,
Marcel
2 Likes
Hello Marcel
It’s great to see that you’re looking at the operation of EIGRP in such detail, it helps to learn more about the protocol’s operation!
What EIGRP will do is it will initially send an empty update during the neighbor establishment phase. After hellos are exchanged, an empty update will be sent to verify unicast and multicast reachability between the neighbors before beginning to exchange routes.
This sequence is described in detail in RFC7868 which fully describes the neighbor adjacency procedure using UPDATE packets.
According to the RFC, Reliable Transport Protocol (RTP) is used to provide guaranteed, ordered delivery of EIGRP packets to all neighbors. It supports intermixed transmission of multicast and unicast packets. Now it states in the RFC that:
The UPDATE exchange sequence requires UPDATE packets sent to be delivered reliably. If the UPDATE or the ACK packet is lost on the network, the UPDATE packet will be retransmitted. The initial packet is always multicast and subsequent retransmissions are unicast addressed. The acknowledgments sent are always unicast addressed.
You can find the above text specifically at the following location.
So there are cases where an update will indeed be sent via unicast, as is the case in the particular packet capture you shared.
I hope this has been helpful!
Laz
3 Likes
Hi,
When I used below to advertise only 1.1.1.1/32 loopback it’s still advertising 1.1.1.0/24 to R2. Why? And how can I advertise /32 only?
//int loo0
//ip address 1.1.1.1 255.255.255.0
Router(config)#router eigrp 1
Router(config-router)#network 1.1.1.1 0.0.0.0Hello Murat
Remember that the network command indicates to the router which connected SUBNETS will be advertised, not which range of addresses will be advertised. If the network of a connected interface falls within the range of IP addresses stated by the network command, then the subnet of the interface is advertised.
In your case, since you have configured the interface as 1.1.1.1 255.255.255.0, the subnet that will be advertised is 1.1.1.0/24. If you want only 1.1.1.1/32 to be advertised, then you should configure the IP address of the loopback interface with the command ip address 1.1.1.1 255.25.255.255. The router will then advertise the subnet of the interface, which is confined to a single address.
I hope this has been helpful!
Laz
2 Likes
Hi,
you stated ’ If the network of a connected interface falls within the range of IP addresses stated by the network command’ but here oppositely the range of IP addresses stated by the network command (1.1.1.1/32) falls within the network of a connected interface(1.1.1.0/24). So, is is the same with which you mention?
regards,
Hello Murat
According to Cisco, the network command for EIGRP works as follows:
When the network command is configured for an EIGRP routing process, the router matches one or more local interfaces. The network command matches only local interfaces that are configured with addresses that are within the same subnet as the address that has been configured with the network command.
So even if you have stated within the network command that you want to include network 1.1.1.1 0.0.0.0, this IP address/subnet mask combination, when compared with the network assigned to the loopback of 1.1.1.0/24, and it will match, even though the whole network doesn’t fit into the range configured with the network command. It matches 1.1.1.1/32 with the 1.1.1.0/24 network on the interface.
The above statement from Cisco was obtained from this Cisco Documentation.
I hope this has been helpful!
Laz
1 Like
Hi Rene/Laz
When we advertise the 1.1.1.0/24 network in the topology in the lesson, having already applied the no auto-summary command, is it necessary to send the wildcard mask in the network command? Doesn’t the router pick up the subnet mask from the interface configuration?
Thanks in advance,
Phil.
1 Like
Hello Philip
Yes, you are correct. If you disable auto-summary there is no need to enter the subnet mask in the network command as this will be taken care of by the subnet mask on the interface itself. Sometimes it just feels better to include the subnet mask in the network command, but it is not necessary in this case. I have labbed it up and confirmed this.
Just a note here, Rene states that by default, EIGRP will behave like a classful routing protocol, but since the writing of the lesson, for more recent versions of IOS, auto-summary is actually disabled by default for EIGRP. You can find out more about this command at this Cisco command reference.
I hope this has been helpful!
Laz
2 Likes
Hi Laz,
Just to reference your answer to Philip:
If no auto-summary makes EIGRP classless, then why would you add a Wildcard mask of 0.0.0.255 in the network command if the loopback0 interface is configured as 1.1.1.0 255.255.255.0 ?
Hello Joseph
The no auto-summary command doesn’t actually make EIGRP classless, but it makes what it advertises classless. In the EIGRP Auto-Summary lesson, Rene states:
EIGRP will check if you have any subnets that fall within the range of your network command(s) and if so, it will advertise the classful A, B or C network to its neighbors. It will only summarize routes from subnets on its own interfaces, not the ones you learn from other routers.
So it’s function is not fully classless, but the way it advertises directly connected networks is classless.
If you don’t specify a wildcard mask, EIGRP will use the subnet mask of the interface associated with that network. If you specify the wildcard mask, EIGRP will take all networks configured on interfaces that fall within the specified range. The only exception is loopback addresses, which, regardless of the subnet mask on the interface, they are always advertised as /32 networks, unless no auto-summary is configured.
A little bit of experimentation in a lab environment using the following lesson as a guide should clarify all of these issues concerning how EIGRP functions.
I hope this has been helpful!
Laz
Thanks Laz, I went through it and tested in a lab and it worked as expected. I understand where you might use the Wildcard when into “no auto-summary”. What I noticed was the following:
Let’s say I have loopback 0 configured with IP address 172.16.1.0 255.255.255.0.
If under command “router eigrp 1”, I enter “network 172.16.1.0” then when I perform a “show run | section eigrp” the entry is “network 172.16.0.0”.
So it has been treated “Classful” as a Class B under EIRGP.
Now I understand that it will advertise the network based on the connected interface subnet mask, but if we have multiple connected interfaces configured which may have the same range such as:
172.16.1.0 /24
172.16.2.0 /24
172.16.3.0 /24
172.16.4.0 /24
172.16.5.0 /24
172.16.6.0 /24
Then these networks will also be advertised. Even though I originally I specifically entered “network 172.16.1.0” it resolves to Class B “172.16.0.0” in my config under EIGRP and will advertise all the routes within this range.
R2:
And from my understanding where the Wildcard Mask can be useful is when I want to specify a network/s that I want to advertise. So instead of using “network 172.16.1.0” I can in fact use “network 172.16.1.0 0.0.0.255” And this will then advertise just this particular network, and not the remaining networks:
Now only these specific routes are available sticking in the config:
and being advertised in to R2.
Would you say my outlay here is correct or have I got anything wrong? I’m just a little confused and trying to iron that out.
Hello Joseph
Yes, your train of thought is correct, and your explanation was very nicely done!
Laz
Hi Laz,
I do have one follow up question. I went through the example in the Auto-Summary lesson to experiment as you suggested. I have it configured exactly the same as in the lesson.
To quote “If you specify the wildcard mask, EIGRP will take all networks configured on interfaces that fall within the specified range. The only exception is loopback addresses, which, regardless of the subnet mask on the interface, they are always advertised as /32 networks”
In the example above the Loopback0 “1.0.0.0/8” doesn’t look to be advertised as a /32 network. Can you just explain that bit out for me please?
Hello Joseph
You are correct, this is not a behaviour that we see in this case. I was doing some lab work recently and noticed this behaviour and I assumed it was always the case. Going back and doing some testing, I found that it is only OSPF that advertises loopback addresses as /32 regardless of the network command or of the subnet mask of the loopback. For example, I have R2 and R3 as OSPF neighbors, and R2 has the following configuration:
interface Loopback0
ip address 2.2.2.2 255.255.255.0
router ospf 1
network 2.2.2.0 0.0.0.255 area 0
R3 has the following in the routing table:
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/2] via 192.168.23.2, 00:00:01, GigabitEthernet0/2
Showing a /32 prefix.
EIGRP however doesn’t do this, and includes the actual subnet mask configured on the loopback interface.
I hope this has been helpful!
Laz
1 Like
It’s been more than helpful, thanks Laz 
1 Like
Which Layer 2 MAC Address is being used by EIGRP ??
Hello Narad
When EIGRP packets are sent using the multicast destination address of 224.0.0.10, which is the reserved address used for EIGRP, the corresponding MAC address used, is also a multicast MAC address, specifically, 01:00:5e:00:00:0a.
When a source or destination corresponds to a particular interface, the MAC address used is that of the interface itself. If it is a physical interface, the MAC address of that interface is used. You can see that MAC address using the show interface command on the router. If the interface is a subinterface, it will inherit the MAC address of the physical interface. If it is an SVI, then it will (depending on the platform) use the same virtual MAC address for all SVIs, or assign one using a particular algorithm.
Take a look at some cloudshark captures that show the MAC addresses being used in the exchange of EIGRP packets.
I hope this has been helpful!
Laz
Hey Rene,
Awesome breakdown of this. Made sense. I am attempting to recreate in my lab. Question for you, is this lab done on physical equipment? Reason why i asked is that when doing this in a virtual lab, i did not see “Hellos” sent/recieved from the loopback interface.
Configs are correct, the only thing i can think of is the diff between physical vs virtual which i seen that difference before
Hello David
Most of the labs created on NetworkLessons are done using Cisco’s VIRL (older labs) or Cisco’s CML (newer labs). Even on other emulators such as GNS3 and even Packet Tracer, you should see the hellos sent. Now emulators, in general, do sometimes have some quirks and may behave strangely, so there’s no guarantee that they will indeed show the hellos. Can you tell us what emulator you are using? Could you try to set up a Wireshark capture to see if you can detect the hellos in that way rather than using debugs?
Let us know how you get along…
I hope this has been helpful!
Laz