We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 641 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

465 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: , ,


Forum 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)#
    ... Continue reading in our forum

  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 
    ... Continue reading in our forum

  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

    ... Continue reading in our forum

  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

27 more replies! Ask a question or join the discussion by visiting our Community Forum