Lessons Learned:
EIGRP Update Types:
EIGRP uses multicast and
unicast
-HELLO, QUERY, UPDATE,
etc. Multicast to 224.0.0.10
-UPDATE, ACK, REPLY, etc
unicast to neighbor.
Neighbor statement
disables multicast
-implies that all
neighbors must agree
Passive interface -
stops both unicast and multicast hellos
- implies no adjacency on passive links
-----------------------------------
EIGRP is similar to RIP
v2 where by default the protocol is going to use multicast (going to
224.0.0.10)
EIGRP does use its own
transport protocol - protocol 88. However some these messages like the
initial
updates for syncing the
topology, acknowledgements to the updates, replies toe query messages will be
unicast to the neighbors.
This implies that both
unicast and multicast must be allowed between the neighbors.
This can become a
problem, if there's ACL's, etc.
You can disable the
multicast by using the neighbor statement, like in RIPv2. In RIP when you
configure the neighbor statement it send unicast as well as multicast to the
neighbor.
In EIGRP the neighbor statement
will disable the listening for and sending of multicast packets. Meaning if you
use the neighbor statement you'll need to use it for all devices on that
segment.
Passive interface (does
not have the same effect as RIP) will disable the ability for form adjacencies.
You should use the passive interface command in EIGRP is typically used at the
access-layer. where you want advertise an interface as an internal route in the
topology but we do not want to establish neighbors on the passive links.
---------------------------------------
I setup a small test lab
with 3 routers connected on a single segment and each whit its own
loopback.
I then enabled "debug ip packet" and "debug eigrp packet", to see
the unicast and multicast messages:
Debug ip packet detail output:
--------------------------------------------
*Mar 1 00:04:38.999: IP: s=192.168.11.2
(FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2, proto=88
*Mar 1 00:04:39.023: IP: s=192.168.11.3
(FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2, proto=88
Here we seen the the
source packet of 192.168.11.2 & 3 going to the multicast address of
244.0.0.10 with the protocol # of 88.
R1#
*Mar 1 00:04:40.095: IP: s=10.1.1.1 (local),
d=224.0.0.10 (Loopback1), len 60, sending broad/multicast, proto=88
*Mar 1 00:04:40.103: IP: s=10.1.1.1 (Loopback1),
d=224.0.0.10, len 60, rcvd 2, proto=88
R1#
--------------------------------------------
"debug ip packet" and "debug
eigrp packet" output together. Then a clearing of the ip eigrp neighbors.
Note: - sent this
traffic to the buffer and not the console or syslog server
*Mar 1 00:09:02.935: EIGRP: Sending HELLO on
FastEthernet0/0
*Mar 1 00:09:02.935: AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ
un/rely 0/0
*Mar 1 00:09:05.215: IP: s=10.1.1.1 (local),
d=224.0.0.10 (Loopback1), len 60, sending broad/multicast, proto=88
Here we see the local router (10.1.1.1) sending
an update
*Mar 1 00:09:05.219: EIGRP: Sending HELLO on
Loopback1
*Mar 1 00:09:05.223: AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ
un/rely 0/0
*Mar 1 00:09:05.227: IP: s=10.1.1.1 (Loopback1),
d=224.0.0.10, len 60, rcvd 2, proto=88
Here is the received AK
*Mar 1 00:09:05.227: EIGRP: Received HELLO on
Loopback1 nbr 10.1.1.1
*Mar 1 00:09:05.227: AS 500, Flags 0x0, Seq 0/0 idbQ 0/0
*Mar 1 00:09:05.227: EIGRP: Packet from ourselves
ignored
*Mar 1 00:09:07.439: IP: s=192.168.11.2
(FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2, proto=88
*Mar 1 00:09:07.455: EIGRP: Received HELLO on
FastEthernet0/0 nbr 192.168.11.2
*Mar 1 00:09:07.459: AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ
un/rely 0/0 peerQ un/rely 0/0
*Mar 1 00:09:07.495: IP: s=192.168.11.3
(FastEthernet0/0), d=224.0.0.10, len 60, rcvd 2, proto=88
*Mar 1 00:09:07.495: EIGRP: Received HELLO on
FastEthernet0/0 nbr 192.168.11.3
*Mar 1 00:09:07.495: AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ
un/rely 0/0 peerQ un/rely 0/0
*Mar 1 00:09:07.755: IP: s=192.168.11.1 (local),
d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
Now let’s put a device
in the middle that allows the or better yet an ACL that allows the Multicast
packets but drops the Unicast.
We can create an ACL
that filters the traffic (note: if we we’re connected to a switch we could
apply a Vlan ACL to the VLAN as a whole.) Since this is only router to router I
will create an ACL and simply apply it to the interface.
R1(config)#access-list
100 deny eigrp 192.168.11.2 255.255.255.0 any
R1(config)#access-list
100 permit ip any any
Apply to interface:
R1(config-if)#ip
access-group 100 in
*Mar 1 00:25:29.771: %DUAL-5-NBRCHANGE:
IP-EIGRP(0) 500: Neighbor 192.168.11.2 (FastEthernet0/0) is down: holding time
expired
R1(config-if)#
Almost immediately I
lost the adjacency with neighbor 192.168.11.2 – this is because the Unicasts
are used as the acknowledgements for the HELLO’s between the neighbors. I still
have connectivity from R3 – 192.168.11.3
R1#
*Mar 1 00:27:28.679: EIGRP: Sending HELLO on FastEthernet0/0
*Mar 1 00:27:28.683: AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ
un/rely 0/0
*Mar 1 00:27:31.719: EIGRP: Received HELLO on FastEthernet0/0 nbr 192.168.11.3
*Mar 1 00:27:31.723: AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ
un/rely 0/0 peerQ un/rely 0/0
*Mar 1 00:27:31.959: EIGRP: Sending HELLO on Loopback1
*Mar 1 00:27:31.959: AS 500, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ
un/rely 0/0
*Mar 1 00:27:31.959: EIGRP: Received HELLO on
Loopback1 nbr 10.1.1.1
*Mar 1 00:27:31.959: AS 500, Flags 0x0, Seq 0/0 idbQ 0/0
From R2’s perspective,
the neighbors want to establish adjacency but because of the filtering this log
message will appear over and over. Typically this means the neighbors are able
to see each other ( on a connected subnet, etc.) with the Multicast but when
they go to exchange topology information there’s an issue in the transport. In
this case it’s the ACL applied to R1’s FA0/0 interface.
R2#
*Mar 1 00:51:41.019: %DUAL-5-NBRCHANGE:
IP-EIGRP(0) 500: Neighbor 192.168.11.1 (FastEthernet0/0) is up: new adjacency
R2#
*Mar 1 00:53:00.543: %DUAL-5-NBRCHANGE:
IP-EIGRP(0) 500: Neighbor 192.168.11.1 (FastEthernet0/0) is down: retry limit
exceeded
If you do not to use the
Multicast and just send updates to a specific neighbor.
Under the EIGRP process
we would need to configure the neighbor statement for the specific neighbor.
IP-EIGRP neighbors for process 500
H Address Interface Hold Uptime SRTT
RTO Q Seq
(sec) (ms) Cnt Num
0
192.168.11.2 Fa0/0 12 00:03:58 40
240 0 41
1 192.168.11.3 Fa0/0 13 00:55:31 59
354 0 13
R1#
Let’s configure R2 with
the neighbor statement.
R1#sh cdp neighbors
Device ID Local Intrfce Holdtme
Capability Platform Port ID
R2.lab.local Fas 0/0 176 R S I 2691
Fas 0/0
R3.lab.local Fas 0/0 176 R S I 2691
Fas 0/0
Example on R1
neighbor 192.168.11.2
fastEthernet 0/0
Example on R2
neighbor 192.168.11.1 fastEthernet
0/0
Note: YOU DO STILL need
the network statement for the network under the EIGRP process.
So both the network
statement and the neighbor statement.
No comments:
Post a Comment