3.3 Longest match routing

s0/0 -- FR

s0/1 - P2P serial to R4

->My config is as follows.

ip route 150.1.0.0 255.255.0.0 Serial0/0
ip route 150.1.4.0 255.255.255.0 Serial0/1

int s0/0
 frame-relay map ip 150.1.4.4 504


R5(config-if)#do show ip route 150.1.4.4
Routing entry for 150.1.4.0/24
  Known via "static", distance 1, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via Serial0/1
      Route metric is 0, traffic share count is 1


R5(config-if)#do traceroute 150.1.4.4

Type escape sequence to abort.
Tracing the route to 150.1.4.4

  1 155.1.0.4 16 msec *  32 msec


IP: tableid=0, s=155.1.45.5 (local), d=150.1.4.4 (Serial0/0), routed via FIB
IP: s=155.1.45.5 (local), d=150.1.4.4 (Serial0/0), len 28, sending
    UDP src=49203, dst=33434
IP: tableid=0, s=155.1.0.4 (Serial0/1), d=155.1.45.5 (Serial0/1), routed via RIB
IP: s=155.1.0.4 (Serial0/1), d=155.1.45.5 (Serial0/1), len 56, rcvd 3
    ICMP type=3, code=3
IP: tableid=0, s=155.1.45.5 (local), d=150.1.4.4 (Serial0/0), routed via FIB
IP: s=155.1.45.5 (local), d=150.1.4.4 (Serial0/0), len 28, sending
    UDP src=49204, dst=33435 *  16 msec
R5#
IP: tableid=0, s=155.1.45.5 (local), d=150.1.4.4 (Serial0/0), routed via FIB
IP: s=155.1.45.5 (local), d=150.1.4.4 (Serial0/0), len 28, sending
    UDP src=49205, dst=33436
IP: tableid=0, s=155.1.0.4 (Serial0/1), d=155.1.45.5 (Serial0/1), routed via RIB
IP: s=155.1.0.4 (Serial0/1), d=155.1.45.5 (Serial0/1), len 56, rcvd 3
    ICMP type=3, code=3

-> As a conclusion, routing points to correct interface s0/1, debug traffic shows that traffic flows as expected, yet a traceroute will report as a first hop 155.1.0.4

WHY is R4 respond with 155.1.0.4 via s0/1 and not 155.1.45.4 via s0/1 ???

 

Comments

  • Andreboit,

     

    did you ever figure this out?

     

    Perhaps, start the post with a description of what you are trying to do and then telling us what you found.  Starting with a configuration is hard to get into.

    ====

    okay, this post seems pretty good for troubleshooting.. so allow me to try and help.

     

    First of all your solution does not match the solution guide, so no surprise that your result is different.

    BUT WHY is it even working? 

    Here is thedebug that woudl have helped you: "debug frame packet" and maybe "debu ip packet"

    At least that is what I think.  You have an issue where encapsulation is failing for one route and the seond best route is used.

     

     

    NET_OG

  • ->My configuration is like in workbook and everything works fine.

     

    Now, I did modify my static route pointing to FR to point to s0/0 interface not next-hop IP address.

     

    it was      --> 150.1.0.0 255.255.0.0 155.1.0.4

    Now it is   --> 150.1.0.0 255.255.0.0 s0/0

    ->For this scenario a static mapping for R4's Loopback is requried.

    int s/0/0/0

     frame-relay map ip 150.1.4.4 504

    ->Now, i'm in the situation where traffic is routed as expected, via longes match(via P2P link), however, R4 replys are comming with source of FR link

    Rack1R5(config-if)#do show ip route 150.1.4.4
    Routing entry for 150.1.4.0/24
      Known via "static", distance 1, metric 0 (connected)
      Routing Descriptor Blocks:
      * directly connected, via Serial3/1
          Route metric is 0, traffic share count is 1

    *Mar  1 01:05:40.727: IP: s=155.1.45.5 (local), d=150.1.4.4 (Serial3/0), len 28, sending
    *Mar  1 01:05:40.727:     UDP src=49184, dst=33434

    *Mar  1 01:05:40.739: IP: s=155.1.0.4 (Serial3/1), d=155.1.45.5 (Serial3/1), len 56, rcvd 3
    *Mar  1 01:05:40.739:     ICMP type=3, code=3

     

    My question is WHY is using FR link as a source and not P2P link!?!??! I hope there will be someone who's going to be able to answer this. I can't find any answer anywhere :( for this.

  • int s/0/0/0

     frame-relay map ip 150.1.4.4 504

     

    My question is WHY is using FR link as a source and not P2P link!?!??! I hope there will be someone who's going to be able to answer this. I can't find any answer anywhere :( for this.

    I realize this is kind of old, and I don't want to necro unnecessarily, but as I just went through this lab myself last night, I ran into a similar problem. I tried the above solution as well, statically mapping the DLCI on the frame relay interface. 

    This solution is incorrect for this lab.

    If you look at the cef table (show ip cef), you'll see that while you have the frame-relay map statement on the frame relay interface, cef automatically associates the destination with that source. So while the routing may appear to be correct with this solution, when it gets to the switching portion, there's a disconnect.

    If you remove the frame-relay map statement, the association also goes away. 

  • This is an old post. However, no answer yet.

     

    I tried now this scenario and now everything works as expected. My returning traffic is sourced from my loopback.

    ->This is even more anoying now :).... Why is it working now and it was not working before. In addition of that i realized that that FR mapping for 150.1.4.0 is not required, as long as traffic is routed through my P2P link. Now, if my P2P link will fail i will need my mapping.

    R5(config-if)#do ping 150.1.4.4 re 1

    Type escape sequence to abort.
    Sending 1, 100-byte ICMP Echos to 150.1.4.4, timeout is 2 seconds:
    !
    Success rate is 100 percent (1/1), round-trip min/avg/max = 120/120/120 ms

    Mar  1 00:32:27.415: IP: tableid=0, s=155.1.45.5 (local), d=150.1.4.4 (Serial0/0), routed via FIB
    *Mar  1 00:32:27.419: IP: s=155.1.45.5 (local), d=150.1.4.4 (Serial0/0), len 100, sending
    *Mar  1 00:32:27.423:     ICMP type=8, code=0
    *Mar  1 00:32:27.523: IP: tableid=0, s=150.1.4.4 (Serial0/1), d=155.1.45.5 (Serial0/1), routed via RIB
    *Mar  1 00:32:27.527: IP: s=150.1.4.4 (Serial0/1), d=155.1.45.5 (Serial0/1), len 100, rcvd 3
    *Mar  1 00:32:27.531:     ICMP type=0, code=0

     

    ->Once i take down my P2P link, i have the same result

    R5(config-if)#do ping 150.1.4.4 re 1

    Type escape sequence to abort.
    Sending 1, 100-byte ICMP Echos to 150.1.4.4, timeout is 2 seconds:
    !
    Success rate is 100 percent (1/1), round-trip min/avg/max = 84/84/84 ms
    R5(config-if)#

    R5(config-if)#
    *Mar  1 00:41:14.143: IP: tableid=0, s=155.1.0.5 (local), d=150.1.4.4 (Serial0/0), routed via FIB
    *Mar  1 00:41:14.147: IP: s=155.1.0.5 (local), d=150.1.4.4 (Serial0/0), len 100, sending
    *Mar  1 00:41:14.151:     ICMP type=8, code=0
    *Mar  1 00:41:14.151: Serial0/0(o): dlci 504(0x7C81), pkt type 0x800(IP), datagramsize 104
    *Mar  1 00:41:14.215: Serial0/0(i): dlci 504(0x7C81), pkt type 0x800, datagramsize 104
    *Mar  1 00:41:14.219: IP: tableid=0, s=150.1.4.4 (Serial0/0), d=155.1.0.5 (Serial0/0), routed via RIB
    *Mar  1 00:41:14.223: IP: s=150.1.4.4 (Serial0/0), d=155.1.0.5 (Serial0/0), len 100, rcvd 3
    *Mar  1 00:41:14.227:     ICMP type=0, code=0

  • I tried now this scenario and now everything works as expected. My returning traffic is sourced from my loopback.

    ->This is even more anoying now :).... Why is it working now and it was not working before. In addition of that i realized that that FR mapping for 150.1.4.0 is not required, as long as traffic is routed through my P2P link. Now, if my P2P link will fail i will need my mapping.

    No, you don't need any frame relay mapping as part of the solution for this lab at all. The Longer route pointing to the P2P interface is fine, but the /16 route needs to be pointing to a next hop IP. That way you don't need an additional layer 3 to layer 2 mapping, and the lab works as expected.

  • I think you didn't get my point here. Scenario in the workbook was just a starting point. This is something a bit different(don't remember everything there anyway)

     

    This is the scenario configuration i was talking about.

     

    R4:

    int lo0

    ip address 150.1.4.4 255.255.255.0

    int s0/1

    ip address 155.1.45.4 255.255.255.0

    int s0/0

    encapsulation frame-relay

    ip address 155.1.0.4 255.255.255.0

    frame-relay map ip 155.1.0.5 405 broadcast

     

    R5:

    int s0/1

    ip address 155.1.45.5 255.255.255.0

    int s0/0

    ip address 155.1.0.5 255.255.255.0

    frame-relay map ip 155.1.0.4 504 br

    frame-relay map ip 150.1.4.4 504  ### this is required if s0/1 goes down otherwise you'll get an encapsulation failed when traffic will be sent through s0/0

    exit

    ip route 150.1.4.0 255.255.255.0 155.1.45.4

    ip route 150.1.0.0 255.255.0.0 155.1.0.4

  • Go look at your first log snippet. Note the section that says 'routed by FIB'. 

    Look at the FIB, show ip cef.

    it has the destination associated with your S0/0 interface, despite the fact that RIB wants to use S0/1. Why? Because of the frame relay map command. So with both interfaces up, your traffic to 155.1.4.4 is going to go out S0/0.

    R4 doesn't have that problem, so it routes it back to you via the RIB.It uses the longest match, which is the /24 through the P2P link.

     So you've introduced asymetric routing, and you're routing in a circle. 

    In your above config, if you remove the frame relay map to 150.1.4.4, you should still be able to route to it over the S0/0 interface with no frame relay map. Since you're using the next hop, and you have a mapping for the next hop, you shouldn't see an encapsulation failure.

  • Try disabling CEF on the interfaces, and it should start behaving like you think it should.

  • dcanceriandcancerian ✭✭✭

    I tried the same scenario and got the result as expected.

  • WHY is R4 respond with 155.1.0.4 via s0/1 and not 155.1.45.4 via s0/1 ???

     

     

    Normally, R4 should respond with 150.1.4.4 as the source IP address to the ICMP echos coming from R5. However, it seems like R4 is changing the source IP address the IP packets caring the ICMP echo-replies toward R5. If you look deeper in this behavior, you'll notice that NAT may be in there. So, look into your R4's configuration to know what is going on.

     

    Here is a sample configuration for the NAT scenario.

    ip nat inside source static 150.1.4.4 155.1.45.4

    interface Serial1/1
     ip nat outside

    Verification:

    Rack1R5#ping 150.1.4.4

    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 150.1.4.4, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 4/45/112 ms
    Rack1R5#
    *Mar  1 01:51:35.171: IP: tableid=0, s=155.1.45.5 (local), d=150.1.4.4 (Serial1/1), routed via RIB
    *Mar  1 01:51:35.175: IP: s=155.1.45.5 (local), d=150.1.4.4 (Serial1/1), len 100, sending
    *Mar  1 01:51:35.275: IP: tableid=0, s=155.1.45.4 (Serial1/1), d=155.1.45.5 (Serial1/1), routed via RIB
    *Mar  1 01:51:35.279: IP: s=155.1.45.4 (Serial1/1), d=155.1.45.5 (Serial1/1), len 100, rcvd 3
    *Mar  1 01:51:35.291: IP: tableid=0, s=155.1.45.5 (local), d=150.1.4.4 (Serial1/1), routed via RIB
    *Mar  1 01:51:35.295: IP: s=155.1.45.5 (local), d=150.1.4.4 (Serial1/1), len 100, sending
    *Mar  1 01:51:35.379: IP: tableid=0, s=155.1.45.4 (Serial1/1), d=155.1.45.5 (Serial1/1), routed via RIB
    *Mar  1 01:51:35.383: IP: s=155.1.45.4 (Serial1/1), d=155.1.45.5 (Serial1/1), len 100, rcvd 3
    *Mar  1 01:51:35.383: IP: tableid=0, s=155.1.45.5 (local), d=150.1.4.4 (Serial1/1), routed via RIB
    *Mar  1 01:51:35.383: IP: s=155.1.45.5 (local), d=150.1.4.4 (Serial1/1), len 100, sending
    *Mar  1 01:51:35.391: IP
    Rack1R5#: tableid=0, s=155.1.45.4 (Serial1/1), d=155.1.45.5 (Serial1/1), routed via RIB
    *Mar  1 01:51:35.391: IP: s=155.1.45.4 (Serial1/1), d=155.1.45.5 (Serial1/1), len 100, rcvd 3
    *Mar  1 01:51:35.391: IP: tableid=0, s=155.1.45.5 (local), d=150.1.4.4 (Serial1/1), routed via RIB
    *Mar  1 01:51:35.391: IP: s=155.1.45.5 (local), d=150.1.4.4 (Serial1/1), len 100, sending
    *Mar  1 01:51:35.395: IP: tableid=0, s=155.1.45.4 (Serial1/1), d=155.1.45.5 (Serial1/1), routed via RIB
    *Mar  1 01:51:35.395: IP: s=155.1.45.4 (Serial1/1), d=155.1.45.5 (Serial1/1), len 100, rcvd 3
    *Mar  1 01:51:35.395: IP: tableid=0, s=155.1.45.5 (local), d=150.1.4.4 (Serial1/1), routed via RIB
    *Mar  1 01:51:35.395: IP: s=155.1.45.5 (local), d=150.1.4.4 (Serial1/1), len 100, sending
    *Mar  1 01:51:35.407: IP: tableid=0, s=155.1.45.4 (Serial1/1), d=155.1.45.5 (Serial1/1), routed via RIB
    *Mar  1 01:51:35.407: IP: s=155.1.45.4 (Serial1/1), d=155.1.45.5 (Serial1/1), len 100, rcvd 3
    Rack1R5#

  • [email protected] - Man your cabling is all over the place!
    Second time if couple of days

    Andrius
Sign In or Register to comment.