Directly connected route learned via IGP

I have a full mesh frame relay between R1, R2, and R3. The frame-relay subnet is 132.1.0.0/24.

I shut down the serial link on R3 and then noticed that R1 is trying to send traffic to R2 (132.1.0.2) through R3! Why doesn't R1 see 132.1.0.2 as directly connected and do L3 > L2 recursion directly to R2? Instead, R1 is doing L3 > L2 recursion to R3!

RSRack1R1#
IP: tableid=0, s=132.1.0.2 (Serial0/0/0), d=132.1.17.7 (FastEthernet0/0), routed via FIB
IP: s=132.1.0.2 (Serial0/0/0), d=132.1.17.7 (FastEthernet0/0), g=132.1.17.7, len 100, forward    ICMP type=8, code=0
IP: tableid=0, s=132.1.17.7 (FastEthernet0/0), d=132.1.0.2 (Serial0/0/0), routed via FIB
IP: s=132.1.17.7 (FastEthernet0/0), d=132.1.0.2 (Serial0/0/0), g=132.1.0.3, len 100, forward    ICMP type=0, code=0
IP: s=132.1.17.7 (FastEthernet0/0), d=132.1.0.2 (Serial0/0/0), len 100, encapsulation failed    ICMP type=0, code=0

Looking at R1's routing table it shows 132.1.0.2 is known via ospf and 132.1.0.3 is directly connected. So why is 132.1.0.2 known via ospf?

RSRack1R1#show ip route 132.1.0.2
Routing entry for 132.1.0.2/32
  Known via "ospf 1", distance 110, metric 64, type intra area
  Last update from 132.1.0.2 on Serial0/0/0, 00:49:39 ago
  Routing Descriptor Blocks:
  * 132.1.0.2, from 150.1.2.2, 00:49:39 ago, via Serial0/0/0
      Route metric is 64, traffic share count is 1

RSRack1R1#show ip route 132.1.0.3
Routing entry for 132.1.0.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Serial0/0/0
      Route metric is 0, traffic share count is 1

Another thing I don't understand is why the gateway is listed as R3, when we can see above that to get to 132.1.0.2 the next-hop is 132.1.0.2.

IP: s=132.1.17.7 (FastEthernet0/0), d=132.1.0.2 (Serial0/0/0), g=132.1.0.3, len 100, forward    ICMP type=0, code=0

Comments

  • One thing to note about the full mesh frame relay is that it is configured as point-to-multipoint. This means that each end advertises it's serial interface as /32. So, R1 is preferring the /32 route advertised by R3 over the /24 route advertised by R2, is this correct?

  • Ok, I was able to filter out the /32 route advertised by R3 and now 132.1.0.2 is seen as directly connected.

    RSRack1R1#show ip prefix-list
    ip prefix-list R2_CONNECTED: 2 entries
       seq 5 deny 132.1.0.2/32
       seq 10 permit 0.0.0.0/0 le 32

    RSRack1R1#show ip route 132.1.0.1
    Routing entry for 132.1.0.0/24
      Known via "connected", distance 0, metric 0 (connected, via interface)
      Routing Descriptor Blocks:
      * directly connected, via Serial0/0/0
          Route metric is 0, traffic share count is 1

    But that didn't fix the problem. R1 is still trying to forward traffic destined for 132.1.0.2 to R3:

    RSRack1R1#
    IP: tableid=0, s=132.1.0.2 (Serial0/0/0), d=132.1.17.7 (FastEthernet0/0), routed via FIB
    IP: s=132.1.0.2 (Serial0/0/0), d=132.1.17.7 (FastEthernet0/0), g=132.1.17.7, len 100, forward    ICMP type=8, code=0
    IP: tableid=0, s=132.1.17.7 (FastEthernet0/0), d=132.1.0.2 (Serial0/0/0), routed via FIB
    IP: s=132.1.17.7 (FastEthernet0/0), d=132.1.0.2 (Serial0/0/0), g=132.1.0.3, len 100, forward    ICMP type=0, code=0
    IP: s=132.1.17.7 (FastEthernet0/0), d=132.1.0.2 (Serial0/0/0), len 100, encapsulation failed    ICMP type=0, code=0

  • i think if u can post ur diagram with addressing then i might help u ..yes u are correct if ur network type is P2M...it ll advertise links as /32....if u are running full mesh i don't think u should probably do...but u did thats nice :)...

     

    nad in frame-relay encapsulation failed occurs only when L3-L2 resolution failed whic u are familiar with...so u need to check that..

  • This is the diagram:

    Topology

    So, the reason for the encapsulation failed is because I shut down R3's serial interface, so the DLCI 103 is inactive. There is no frame-relay map toward R3. But, still R1 tries to forward to R3 which results in the enc failed.

Sign In or Register to comment.