Lab 11, Task 2.2, EIGRP

Hi all. I have a question abot mentioned task of lab 11, the task is asking about a method that enables the EIGRP routers (R2, R3, R5) to maintain full reachability to the network, while one of the VCs goes down. the routing part is simple by disabling EIGRP split horizon on multipoint interfaces of these routers. I mean, the routing updates are received at routers in the case of a VC failure. but with regard to the fact that, this is a multipoint network and we use same L3 network inside the FR cloud between these three routers, the encapsulation failure is occured after breaking a VC; suppose a VC between R2 and R5 is broked. so R2 will receive routing updates from R3 by the means of disabling split horizone; but decpite router R2 will send traffic to R5's IP through R3 at L3, it will not have reachablility to R5 at L2, because the VC to R5's IP address is down now and it will fail to see any map to R5. so what we can do in this situation?

Comments

  • Hi Timaz

     

    You have a full mesh of PVC's so you can engineer the network to survive a VC failing.

     

    There are other things you can enable for EIGRP at the interface level as well is disabling split horizon :)

     

    Nick

  • JoeMJoeM ✭✭✭

    I just brought the lab, to experiment with it.   So, I am thinking out loud, as I am looking at this.

    ....

    suppose a VC between R2 and R5 is broken. so R2 will receive routing updates from R3 by the means of disabling split horizone;

    To set this up, how is the VC broken?  My method was to change the frame map to an incorrect PVC number.   If we remove the FRAME MAPs, we would defeat the purpose of the test.

    What should we ping for the test?    How about loopbacks?   Because we can no longer use the IP's that are tied to the frame maps.

     

    but despite router R2 will send traffic to R5's IP through R3 at L3, it will not have reachablility to R5 at L2, because the VC to R5's IP address is down now and it will fail to see any map to R5. so what we can do in this situation?

    SOURCE from a different IP, other than the mapped IP.

    R2/R5 will still see the mapped interfaces. This is the main problem when going from router to router R5<-->R2.

    It will not work if we are sourcing from the IP's tied to the FRAME MAPS. Otherwise, R3 will relay (route).

     

    EDIT:   also test from R6 (any interface) to R2's loopback.   This works also.    The only problem is connectivity between R2 and R5 S0/0 IP's.

     

     

  • JoeMJoeM ✭✭✭

    You have a full mesh of PVC's so you can engineer the network to survive a VC failing.

    Hi Nick,

    I am curious about this.  There must be a way.   

    To me, it seems like the only way to do it, would be to remove the frame maps.   If the PVC is broken, traffic between those two IPs (.2 and .5)  would be blackholed by the maps.

  • You have a full mesh of PVC's so you can engineer the network to survive a VC failing.

    Hi Nick,

    I am curious about this.  There must be a way.   

    To me, it seems like the only way to do it, would be to remove the frame maps.   If the PVC is broken, traffic between those two IPs (.2 and .5)  would be blackholed by the maps.

     

    Hi JoeM

     

    I was thinking the lab would expect traffic in the EIGRP domain or transiting the domain would surivive one of the PVC's going down but yes you would lose the ability to ping from .3 to .5 if that PVC was down, however, you should still be able to get to networks behind R3 or behind R5 by transiting R2.  I don't remember the specifics as my last Vol 2 lab was 17 but looks like next-hop-self would be useful here?

     

    Sorry if I am barking up the wrong tree but been a while since I did Lab 11.

     

    Nick

  • JoeMJoeM ✭✭✭

    It would probably need an EEM applet to remove the Frame Map.

    But that would be extreme, because the only thing we are losing is the ability to connect/ping addresses between R2-S0/0 and R5-S0/0.       

    All other traffic is good.

  • Hi. when one VC goes down, (e.g the VC between R2 and R5), every ping test from R2 to most EIGRP routes, fail, not just the ping from R2 to R5. I tested a ping from R2 to R6's loop when the VC is down between R2 and R5, but I was unsuccessful, because when R5, at the middle of the path, wants to forward the reply to R2, it will fail to find L2 map on its FR map table; don't you see this? i think if we had a way to change next hop, or if we use P2p interfaces instead the multipoint ones, we will survive the failure. any idea?

  • JoeMJoeM ✭✭✭

    Hi. when one VC goes down, (e.g the VC between R2 and R5), every ping test from R2 to most EIGRP routes, fail, not just the ping from R2 to R5. I tested a ping from R2 to R6's loop when the VC is down between R2 and R5, but I was unsuccessful, because when R5, at the middle of the path, wants to forward the reply to R2, it will fail to find L2 map on its FR map table; don't you see this? i think if we had a way to change next hop, or if we use P2p interfaces instead the multipoint ones, we will survive the failure. any idea?

    Hi Timaz,

    There is no problem, other than what I mentioned above.  The key to this is sourcing from a different IP address. 

    If you are pinging from R2 across the frame-relay (without sourcing the ping), R2 will use the direct interface (187.x.235.2).  That is a problem, because  when R5 is trying to return any traffic to that bad IP -- oops -- it will be blackholed out the bad pvc.

    There is another caveat.   The bad routes must be cleared (time to recognize the neighbor is down), so then, routing will change  R2<-->R3<-->R5     This will automatically solve the next hop you are wanting to change.

     

    Try sourcing the pings from R2 (across the Frame) from any interface besides the serial.

     

Sign In or Register to comment.