Monday, March 31, 2014

EIGRP Update Types, EIGRP Neighbor, EIGRP Passive-Interface

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