Slowly catching up where i was before;
Nugget 8 EIGRP Best Practices And Designs
This nugget is about best pratices and design options, its broken down into;
Eavesdropping on EIGRP neighbours
Understanding the QUERY process
Making EIGRP more efficient
Eavesdropping on EIGRP neighboursWe can do this via debug eigrp packets, now this is ALL packets;
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY) So the screen gets crowded rather quickly and if on a big network ... over power the router
What we can do, is focus in on the particular packets we are interesting in, say a network goes down, well in that case the routers are going to be sending querys and replys to them querys.
Lets investigate below;
I have created a loopback interface, added into the EIGRP process then shut it down (simulating a network out) watch the debug:
BB-Router(config)#int loopback 174
BB-Router(config-if)#ip address 174.40.40.1 255.255.255.0
BB-Router(config-router)#router eigrp 90
BB-Router(config-router)#network 174.40.40.1
BB-Router(config-router)#no passive-interface loopback174
BB-Router#debug eigrp pack query reply
BB-Router(config)#int loopback 174
BB-Router(config-if)#shut
BB-Router#
01:56:46: EIGRP: Enqueueing QUERY on Serial0/1 iidbQ un/rely 0/1 serno 19-19
01:56:46: EIGRP: Enqueueing QUERY on Serial0/0 iidbQ un/rely 0/1 serno 19-19
01:56:46: EIGRP: Enqueueing QUERY on Serial0/1 nbr 10.1.34.2 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 19-19
01:56:46: EIGRP: Enqueueing QUERY on Serial0/0 nbr 10.1.24.2 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 19-19
01:56:46: EIGRP: Sending QUERY on Serial0/1 nbr 10.1.34.2
01:56:46: AS 90, Flags 0x0, Seq 9/6 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 19-19
01:56:46: EIGRP: Sending QUERY on Serial0/0 nbr 10.1.24.2
01:56:46: AS 90, Flags 0x0, Seq 10/9 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 19-19
01:56:46: EIGRP: received packet with MD5 authentication, key id = 2
01:56:46: EIGRP: Received QUERY on Serial0/1 nbr 10.1.34.2
01:56:46: AS 90, Flags 0x0, Seq 9/9 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
01:56:46: EIGRP: received packet with MD5 authentication, key id = 2
01:56:46: EIGRP: Received REPLY on Serial0/0 nbr 10.1.24.2
01:56:46: AS 90, Flags 0x0, Seq 11/10 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
01:56:46: EIGRP: received packet with MD5 authentication, key id = 2
01:56:46: EIGRP: Received QUERY on Serial0/0 nbr 10.1.24.2
01:56:46: AS 90, Flags 0x0, Seq 12/10 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
01:56:46: EIGRP: Enqueueing REPLY on Serial0/0 nbr 10.1.24.2 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 20-20
01:56:46: EIGRP: Sending REPLY on Serial0/0 nbr 10.1.24.2
01:56:46: AS 90, Flags 0x0, Seq 11/12 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 20-20
01:56:47: EIGRP: received packet with MD5 authentication, key id = 2
01:56:47: EIGRP: Received REPLY on Serial0/1 nbr 10.1.34.2
01:56:47: AS 90, Flags 0x0, Seq 11/9 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0So we can see the querys queue first on the interfaces:
01:56:46: EIGRP: Enqueueing QUERY on Serial0/1 iidbQ un/rely 0/1 serno 19-19
01:56:46: EIGRP: Enqueueing QUERY on Serial0/0 iidbQ un/rely 0/1 serno 19-19Then the messages queue for the particular neighbour;
01:56:46: EIGRP: Enqueueing QUERY on Serial0/1 nbr 10.1.34.2 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 19-19
01:56:46: EIGRP: Enqueueing QUERY on Serial0/0 nbr 10.1.24.2 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 19-Querys are then immidately sent out to them neighbours
01:56:46: EIGRP: Sending QUERY on Serial0/1 nbr 10.1.34.2
01:56:46: EIGRP: Sending QUERY on Serial0/0 nbr 10.1.24.2We then get a REPLY back, saying we dont have a backup route to that network, thats your loopback interface!
01:56:47: EIGRP: Received REPLY on Serial0/1 nbr 10.1.34.2
01:56:47: AS 90, Flags 0x0, Seq 11/9 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
01:56:46: EIGRP: Received REPLY on Serial0/0 nbr 10.1.24.2
01:56:46: AS 90, Flags 0x0, Seq 11/10 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0This makes it alot more easier to troubleshoot and easy to see what is going on
UNDERSTANDING THE QUERY PROCESS
When the network goes down on a router running EIGRP, it will send out a QUERY msg to neighbours if it does not have a backup route itself (Fessiable Sucessor)
Sent out of all EIGRP interfaces (except interface that is down/spit horizon)
Even if a neighbour has a route to the network that went down and passes this onto the first router, he still has to wait for all the other neighbours to reply!
BY DEFAULT THIS IS 3 MINUTES
Whilst the above is happening, this route to the network is "SIA, Stuck In Active" on the first router,
After 3 minutes has lapsed, the router will tear down all EIGRP Neighbourships and reform them
BUT whilst stuck in active, every network just went down on the router, plus the router within seconds of sending the QUERY could of had an answer back, BUT it has to wait for the reply!
TO HELP FIX THIS.........
As above, by summarising networks, we help stop SIA from happening,
how?
Well when the route to the network goes down, it will still send out a QUERY about that network, however the neighbour will not forward that QUERY msg on, as it has a summary route from router 2, so the other neighbours reply back saying NO, you told me you had the networks in
172.30.0.0/21
AWESOME, HUH!
So if you do proper summarisation in your network, you wont have to worry about SIA or about configuring the below method of a STUB router.
STUB CONFIGURATION
When neighbourships are formed with Router2 the other routers introduce themselfs as stubs (once you have configured them) this tell tells Router2, that the only routes you tell me about are the only ones you know about, its the end of the road, you dont go anyone else .... SO Router2 knows not to send QUERY msgs to these guys (bit like a cuddlesac)
If you wanted to go hardcore, then you could configure this guy as a stub recieve-only, so this would be like a passive interface in RIP (remember that lol)
A NOTE
As noted in the older IOS's ( before 12.3(2)T ) when a router was rebooted, or the neighbours were cleared or there was a power cut etc, the router didnt tell anyone, the neighbours hold down timers would just expire and then route to that neighbour would be marked as down, the router would check for a fesiable successor and if needed send out QUERY messages everywhere! ...
. NOT VERY EFFICIENT
