EIGRP Lab example for Query Scoping.
EIGRP Lab example for Query Scoping.
I have read about EIGRP Scoping , and in most of articles they recommend Summarization at the Edge router. I have tried that, and enabled Debug EIGRP Packets Query on other routers, and shut down interface on one of the routers behind the Edge router, but I still saw a Query sent by the Edge Router to other routers.
I am not sure if that's normal behaviour or the lab is not the right set up to test EIGRP Query Scoping.
Any Lab Example from EIGRP Expert that demonstartes EIGRP Query Scoping might help understand this topic..
Thank you
I have read about EIGRP Scoping , and in most of articles they recommend Summarization at the Edge router. I have tried that, and enabled Debug EIGRP Packets Query on other routers, and shut down interface on one of the routers behind the Edge router, but I still saw a Query sent by the Edge Router to other routers.
I am not sure if that's normal behaviour or the lab is not the right set up to test EIGRP Query Scoping.
Any Lab Example from EIGRP Expert that demonstartes EIGRP Query Scoping might help understand this topic..
Thank you
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Predrag Jovic
Always when link is lost EIGRP MUST send Query message. It is just question of limiting how far message will go - one or more hops. But, in your previous questions you were trying to eliminate Query completely - it is not possible to do, QUERY must be sent (it is attempt of router to find alternative path through other routers to network that is lost).
ASKER
I followed this link
https://ccieblog.co.uk/eigrp/eigrp-query-scoping-using-summarisation
I have not tested it in the Lab, but from what I have read..I do not understand why the query will go all the way to R6.
R3 should not send any query to other routers at the first place... R1,R2,R3,R4, R8,R9 should be in kind of Stub area..
https://ccieblog.co.uk/eigrp/eigrp-query-scoping-using-summarisation
I have not tested it in the Lab, but from what I have read..I do not understand why the query will go all the way to R6.
R3 should not send any query to other routers at the first place... R1,R2,R3,R4, R8,R9 should be in kind of Stub area..
ASKER
oops ..got carried away :)
I meant R1,R2, R3, R8,R9 not R1,R2,R3,R4, R8,R9
Can be in kind of (EIGRP Stub Area)..something like OSPF Stub Area
I meant R1,R2, R3, R8,R9 not R1,R2,R3,R4, R8,R9
Can be in kind of (EIGRP Stub Area)..something like OSPF Stub Area
ASKER
I wonder if we configure EIGRP Neighborship between R1,R2,R3,R8,R9 manually then when the Link between R8 and R9 fails whether the Query will travel up to R3 and not beyond ?
R3 must send query. Path to network is lost. Maybe there is alternative path to lost network , if query is not sent alternative path can never be found. Forget about that we human see the topology and know that there is no alternative path, routers don't know that, so query is sent - translation "Is there anyone knows path to network x.x.x.x?".
EIGRP is not link state protocol and it is not aware of all links that exist in AS. EIGRP is aware just of routes in its own topology table and EIGRP is distance vector protocol, Neighbors are advertising only the best of the best routes to it. After network is lost maybe some alternative path can be found.
Please read - EIGRP Stub Routing
EIGRP is not link state protocol and it is not aware of all links that exist in AS. EIGRP is aware just of routes in its own topology table and EIGRP is distance vector protocol, Neighbors are advertising only the best of the best routes to it. After network is lost maybe some alternative path can be found.
Please read - EIGRP Stub Routing
ASKER
Actually I test it in the LAB with the topology above..
On R1 interface fa0/0 facing towards R4 I configured
ip summary-address eigrp 1 192.168.0.0 0.0.0.0
R4#sh ip route eigrp
Gateway of last resort is 192.168.14.1 to network 0.0.0.0
D* 0.0.0.0/0 [90/30720] via 192.168.14.1, 00:00:09, FastEthernet0/1
R4#R5#sh ip route eigrp
Gateway of last resort is 192.168.45.4 to network 0.0.0.0
D* 0.0.0.0/0 [90/33280] via 192.168.45.4, 00:01:44, FastEthernet0/0
D 192.168.14.0/24 [90/30720] via 192.168.45.4, 00:42:41, FastEthernet0/0
R5#on R4 and R5
I configured Debug EIGRP Packets Query Reply
then I shut down interfaces on R2 and R3 linking each other.
on R4, I can see these messages:
*Nov 3 20:05:43.439: EIGRP: Received QUERY on FastEthernet0/1 nbr 192.168.14.1
*Nov 3 20:05:43.439: AS 1, Flags 0x0:(NULL), Seq 132/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Nov 3 20:05:43.439: Handling TLV: 242 42 for 0 route: 192.168.23.0/24
*Nov 3 20:05:43.451: EIGRP: Enqueueing REPLY on FastEthernet0/1 nbr 192.168.14.1 tid 0 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 46-46
*Nov 3 20:05:43.459: EIGRP: Sending REPLY on FastEthernet0/1 nbr 192.168.14.1 tid 0
*Nov 3 20:05:43.459: AS 1, Flags 0x0:(NULL), Seq 60/132 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 46-46
R4#
On R5# there was no message popped up
R4#sh ip interf brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 192.168.45.4 YES manual up up
FastEthernet0/1 192.168.14.4 YES manual up up
ASKER
What I concluded the Query will travel one more hop from the router on which we configured :
ip summary-address eigrp 1 192.168.0.0 0.0.0.0
ip summary-address eigrp 1 192.168.0.0 0.0.0.0
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you
You're welcome.