Tags: , ,


Notable Replies

  1. Hi Rene,
    Your post is very informative bro…keep it up!!

    Would you please help me understand what you really mean by this rule #1?
    (Don’t advertise the tunnel destination IP address on the tunnel interface. Don’t advertise it or use route filtering.)

    What if you used the network connected to R2 as the destination IP? like:

    R1(config)#interface tunnel 1
    R1(config-if)#tunnel source fa0/0
    R1(config-if)#ip address 192.168.13.1 255.255.255.0
    R1(config-if)#tunnel destination 192.168.23.3
    

    -

    R3(config)#interface tunnel 1
    R3(config-if)#tunnel source Fa0/0
    R3(config-if)#ip address 192.168.13.3 255.255.255.0
    R3(config-if)#tunnel destination 192.168.12.1
    

    Would we still have the same RR issues?
    Please give me your comment
    Thanks.!

  2. Hi Rene,
    Very interesting post and topics.

    please woul you give me more details on the 1st rule you listed to fix the issues? (Don’t advertise the tunnel destination IP address on the tunnel interface. Don’t advertise it or use route filtering)

    What if we set the tunnels this way below, would we have the same rr issue?

    R1(config)#interface tunnel 1
    R1(config-if)#tunnel source fa0/0
    R1(config-if)#ip address 192.168.13.1 255.255.255.0
    R1(config-if)#tunnel destination 192.168.23.3
    

    -

    R3(config)#interface tunnel 1
    R3(config-if)#tunnel source Fa0/0
    R3(config-if)#ip address 192.168.13.3 255.255.255.0
    R3(config-if)#tunnel destination 192.168.12.1
    

    Any comment will be appreciated
    Thanks.

  3. Hi Thom,

    In my example, R1 and R3 learn about each others tunnel destination IP address through R2 with a hop count of 2.

    Once the tunnel is established, they learn about each others destination IP address through the tunnel with a hop count of 1.

    Since 1 is a better metric than 2, they remove their entry from the routing table that points to R2 and insert an entry that points to the tunnel interface.

    The tunnel now collapses…because we are trying to reach the tunnel destination through the tunnel itself. The same problem will occur if you configure OSPF on the tunnel and advertise the tunnel destination IP addresses in OSPF.

    OSPF has a lower (better) administrative distance than RIP, so the RIP entries will be removed and the OSPF entries will be installed…and the tunnel collapses.

    In your example, when you use the IP addresses on the physical interfaces you will still have some issues because the hop count to the destination IP address will be 1 through R2 and also 1 through the tunnel.

    When RIP has two paths with the same metric, it will do load balancing…

    So in short, make sure that you never learn the destination IP address of the tunnel through the tunnel itself :slight_smile:

  4. Hi Rene, thank you for the excellent post.

    And if I’m running OSPF instead of RIP, how could I solve this situation since my tunnel has a lower cost than my physical interfaces?

    I tried to filter the tunnel destination address (LSA3) with distribute-list IN on the tunnel interface, but it didn’t work. Any idea?

    Thanks!

  5. I got “recursive routing” before applying the offset command.

    However ; I noted that traceroute works, before and after applying offset. It, also, displays the same result (below).

    **R1#traceroute 3.3.3.3**
    
    Type escape sequence to abort.
    Tracing the route to 3.3.3.3
    
      1 192.168.12.2 56 msec 8 msec 12 msec
      2 192.168.23.3 20 msec 20 msec 20 msec

Continue the discussion forum.networklessons.com

31 more replies!

Participants