EIGRP Packet Capture - Route Poisoning

In an ongoing thread regarding the behavior of EIGRP, I stated that I
would not expect to see two routers advertise routes to each other if
they were on a common subnet together and that common subnet was also
where they learned of their currently active paths to reach any
prefixes from a third party router. I didn't really want to muck with
my current lab setup but in the end I just couldn't resist. What I
observed was actually route poisoning, not a failure to advertise
routes, per se. To stay with the topology that's been discussed up
'til now (many if not most of you have probably tuned out of the other
thread by now so here it is):

    R3 R4
      | |
      SW1 <-- One single VLAN connecting R2, R3, and R4 all together
         |
       R2
         |
       R1

I hate ASCII art because spacing always seems to get messed up. But
the bottom line is that R2, R3, and R4 all share a common subnet
together (10.1.234.0/24) and are EIGRP neighbors, as are R1 and R2.
R3 and R4 are learning of a route to R1's Lo0 (1.1.1.1/32) via R2. I
'shut' R3's interface, waited for things to settle, started a capture,
and then 'no shut' the R3 interface. Interestingly, R3 poisoned it's
routes learned from R2 with the destination of the updates set to both
its configured neighbor R4 and to the all EIGRP routers address of
224.0.0.10:

No. Time Source Destination
Protocol Info
      40 15.390516 10.1.234.3 IGRP-ROUTERS.MCAST.NET
EIGRP Update

Frame 40: 111 bytes on wire (888 bits), 111 bytes captured (888 bits)
Ethernet II, Src: c2:02:01:5c:00:00 (c2:02:01:5c:00:00), Dst:
IPv4mcast_00:00:0a (01:00:5e:00:00:0a)
Internet Protocol, Src: 10.1.234.3 (10.1.234.3), Dst: IGRP-
ROUTERS.MCAST.NET (224.0.0.10) <<<<<<
Cisco EIGRP
     Version: 2
     Opcode: Update (1)
     Checksum: 0x71b3
     Flags: 0x00000002
     Sequence: 75
     Acknowledge: 0
     Autonomous System: 100
     IP internal route = 10.1.12.0/24 - Destination unreachable
<<<<<<
     IP internal route = 1.1.1.1/32 - Destination unreachable <<<<<<

No. Time Source Destination
Protocol Info
      41 15.390537 10.1.234.3 10.1.234.4
EIGRP Update

Frame 41: 111 bytes on wire (888 bits), 111 bytes captured (888 bits)
Ethernet II, Src: c2:02:01:5c:00:00 (c2:02:01:5c:00:00), Dst:
c2:03:01:5c:00:00 (c2:03:01:5c:00:00)
Internet Protocol, Src: 10.1.234.3 (10.1.234.3), Dst: 10.1.234.4
(10.1.234.4) <<<<<<<
Cisco EIGRP
     Version: 2
     Opcode: Update (1)
     Checksum: 0x7170
     Flags: 0x00000000
     Sequence: 75
     Acknowledge: 69
     Autonomous System: 100
     IP internal route = 10.1.12.0/24 - Destination unreachable
<<<<<<
     IP internal route = 1.1.1.1/32 - Destination unreachable <<<<<<

And here is R4's perspective of things following this:

R4#sh ip eig neigh
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO
Q Seq
                                             (sec) (ms)
Cnt Num
0 10.1.234.3 Fa0/0 11 01:03:12 1082 5000
0 81
1 10.1.234.2 Fa0/0 12 01:40:18 34 204
0 81

R4#sh ip route

<output omitted>

      1.0.0.0/32 is subnetted, 1 subnets
D 1.1.1.1 [90/2300416] via 10.1.234.2, 01:40:18, FastEthernet0/0
      10.0.0.0/24 is subnetted, 2 subnets
D 10.1.12.0 [90/2172416] via 10.1.234.2, 01:40:18, FastEthernet0/0
C 10.1.234.0 is directly connected, FastEthernet0/0

R4#sh ip eig top all-paths
IP-EIGRP Topology Table for AS(100)/ID(10.1.234.4)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
        r - reply Status, s - sia Status

P 1.1.1.1/32, 1 successors, FD is 2300416, serno 46
         via 10.1.234.2 (2300416/2297856), FastEthernet0/0
P 10.1.12.0/24, 1 successors, FD is 2172416, serno 45
         via 10.1.234.2 (2172416/2169856), FastEthernet0/0
P 10.1.234.0/24, 1 successors, FD is 28160, serno 44
         via Connected, FastEthernet0/0

This isn't terribly surprising (poisoning being a more assertive and
aggressive approach relative to mere silence). But it is interesting
to see that IOS goes even a step further by unicasting as well as
multicasting the poisoned update. Interesting also to note that R4,
which was already neighbored up with R2 at the start of my capture,
did *not* turn around and likewise poison its routes to those same two
destinations reachable via R2. It presumably did that immediately
following its neighboring up with R2 and then did not repeat that
poisoning to R3 (nor to the "All EIGRP Routers" mcast address) in
response to R3's having done so at a later time. I found it
interesting, anyway, and thought I would go ahead and post to the
group since my earlier comment that these simply wouldn't be
advertised was incorrect; they're advertised as unreachable and more
than just once...

Blogs and organic groups at http://www.ccie.net
Received on Mon Jan 10 2011 - 19:52:28 ART