Task 3.11 GRE Tunneling and Recursive Routing

Just want to share 2 more solutions here.

Solution 1:

SW3:

ip access-list standard PREVENT_RECURSIVE_ROUTING

  deny 150.1.10.10

  permit any

 

router rip

  distribute-list PREVENT_RECURSIVE_ROUTING in Tunnel0

 

SW4:

ip access-list standard PREVENT_RECURSIVE_ROUTING

  deny 150.1.9.9

  permit any

 

router rip

  distribute-list PREVENT_RECURSIVE_ROUTING in Tunnel0

 

Solution 2: Not really a solution here, but if in case distribute-list filtering is not allowed, you can use static routes

 

SW3:

ip route 150.1.10.10 255.255.255.255 155.1.79.7

 

SW4:

ip route 150.1.9.9 255.255.255.255 155.1.58.8

 

 

I have tested both solutions above and stabilizes the Tunnel0 interface from flapping and being flaky.

 

HTH

Alvin Galang [:)]

Comments


  • I was also able to stabilize the Tunnel. I was only successful in doing so by using static routes, however. ACL and prefix list did not neutralize the link. Whether I filtered the traffic in, out or both ways, it did not work unless the static routes were used.

    The recursive error,  %TUN-5-RECURDOWN:, did not stop showing its ugly face. Depending on where I made a change first, the error would occur on either SW3 or SW4.

    Has anyone else ran into this issue where the recursive routing isue is only resolved static routes?

    WMDO

     


     

     

     

  • Hi,

    I managed to get it working with no issues. I'm not quite sure why the prefix-lists are not working in your solution. Did you ever try again?

    It's good to see the alternative solutions posted above and static routes are the choice made by Cisco if you Google for GRE Recursive routing. The prefix-list versus ACL usage is more subtle but if I remember rightly Brian McGahan said that prefix-lists were designed to match routes and ACLs were designed to match traffic so in this instance you should be using prefix-lists.

    Cheers,

    Chris

  • Hi wdeoca,

    my lab has the same issue. The Recursive Rounting only stops when I put the static routes to the same next-hops learned by RIP.

    In my console of boths 3550 it's logged this line


    *Mar  1 00:57:38.579: Assert failure in ../src-vegas/vur_drv.c line 2439



    I know that the version of the image of the 3550 is 12.2(44)SE3, but the error is the same and the cenario has same characteristics, with multiple next-hops.

    So, I think with static routing we force the switch to rely only on the static route, ignoring the other routes with higher metrics. 

  • The issue I came up with had a simple solution.  Make sure you use the 'prefix' option in the distribute-list command.  Without it it won't match any of the clauses in the route-map/prefix-list...

     

    sh ip prefix details

     


    ip prefix-list BR8:

       count: 2, range entries: 1, sequences: 5 - 10, refcount: 2

       seq 5 deny 150.1.8.0/24 (hit count: 8, refcount: 1)

       seq 10 permit 0.0.0.0/0 le 32 (hit count: 186, refcount: 1)

  • The issue I came up with had a simple solution.  Make sure you use the 'prefix' option in the distribute-list command.  Without it it won't match any of the clauses in the route-map/prefix-list...

     

    sh ip prefix details

     

     

    ip prefix-list BR8:

       count: 2, range entries: 1, sequences: 5 - 10, refcount: 2

       seq 5 deny 150.1.8.0/24 (hit count: 8, refcount: 1)

       seq 10 permit 0.0.0.0/0 le 32 (hit count: 186, refcount: 1)

     

     

    I accomplished this task using access list and distance command. Here are my configurations for SW3 and SW4.

    Rack1SW3(config)#access-list 1 permit host 150.1.10.0
    Rack1SW3(config)#router rip
    Rack1SW3(config-router)#distance 255 10.34.0.10 0.0.0.0 1



    Rack1SW4(config)#access-list 1 permit host 150.1.9.0
    Rack1SW4(config)#router rip
    Rack1SW4(config-router)#distance 255 10.34.0.9 0.0.0.0 1

     

    Hope this help!

  • Generally speaking, unless a task forces you to use certain configuration, best approach to avoid GRE recursive routing is to use different IGPs and/or static routing. Use on IGP/EGP to learn through it tunnel endpoints and another IGP/EGP to advertise prefixes over the tunnels; avoid as much as possible RIP as it matches on classful networks and you can end up advertising all networks over the tunnel, including tunnel endpoints, thus having GRE recursive routing. Second approach is to use filtering, but this is more susceptible to erros and needs to be properly controlled.

    Task does not use static routes and floating static routes for recursive routing but to provide redundancy for some prefixes.

    Good luck with your studies!

  • The prefix list solution in the WB is also not working for me. The  %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing :-(

     

    I use standard access-list and it is working fine.

    SW3

    router rip

     version 2

     network 10.0.0.0

     network 150.1.0.0

     network 155.1.0.0

     distribute-list 1 out Tunnel0

     no auto-summary

    access-list 1 deny   150.1.9.0 0.0.0.255

    access-list 1 permit any

    SW4

    router rip
     version 2
     network 10.0.0.0
     network 150.1.0.0
     network 155.1.0.0
     distribute-list 1 out Tunnel0
     no auto-summary

    access-list 1 deny   150.1.10.0 0.0.0.255
    access-list 1 permit any

     

    Anyone think that prefix list is got problem?

  • Hi aristaw,

    There will be route recurssive problem if you advertise Tunnel source address via RIP (without distribute-list), I can't exact simulate this task now but this is my example about recursive routing:

    I have R1 to R5 on RIP domain and tunnel from R1 to R5. Now Tunnel IP
    is not advertised on RIP, source and destination IP is Loopback IP of
    R1 and R5. I hope you already know to up tunnel, source and destination
    IP should be already reachable.

    Before Advertising tunnel IP on RIP:

    R1#show running-config interface tunnel 0
    Building configuration...

    Current configuration : 116 bytes
    !
    interface Tunnel0
     ip address 192.168.0.1 255.255.255.0
     tunnel source Loopback0
     tunnel destination 5.5.5.5
    !
    R5(config)#do show run int tunnel1
    Building configuration...

    Current configuration : 116 bytes
    !
    interface Tunnel1
     ip address 192.168.0.5 255.255.255.0
     tunnel source Loopback0
     tunnel destination 1.1.1.1
    end
    !
    R5
    *Mar  1 00:53:16.979: RT: add 1.1.1.1/32 via 45.45.45.4, rip metric [120/3]
    *Mar  1 00:53:16.983: RT: NET-RED 1.1.1.1/32
    *Mar  1 00:53:16.983: RT: SET_LAST_RDB for 2.2.2.2/32
      NEW rdb: via 45.45.45.4
    R1
    *Mar  1 00:54:50.475: RT: add 5.5.5.5/32 via 12.12.12.2, rip metric [120/3]
    *Mar  1 00:54:50.475: RT: NET-RED 5.5.5.5/32
    *Mar  1 00:54:50.479: RT: SET_LAST_RDB for 23.23.23.0/24
      NEW rdb: via 12.12.12.2

    Now tunnel is up and let's create some additional network and create static route towards tunnel interface.

    R1(config)#ip route 192.168.55.0 255.255.255.0 Tunnel0
    R1(config)#do trace 192.168.55.1
    Type escape sequence to abort.
    Tracing the route to 192.168.55.1
      1 192.168.0.5 92 msec

    Let's advertise tunnel IP on RIP
    R5(config)#router rip
    R5(config-router)#network 192.168.0.0
    R5#
    *Mar  1 01:00:35.203: %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing
    *Mar  1 01:00:36.203: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
    R5#show ip route 1.1.1.1
    % Network not in table
    *Mar  1 01:02:54.071: RT: add 1.1.1.1/32 via 192.168.0.1, rip metric [120/1]
    *Mar  1 01:02:54.071: RT: NET-RED 1.1.1.1/32
    !

    Now R5 is trying to learn 1.1.1.1 IP from tunnel interface with
    metric 1 and RIP tried to install this route on routing table but tunnel
    to be up source/destination address should reachable via other path
    that's why tunnel went down.

    Now create a prefix-list to deny to advertise via tunnel
    interface(remember that loopback ip will be advertised to other
    interface) and advertise the tunne address on RIP.

    R1#show ip prefix-list
    ip prefix-list STOP_TO_R5_TUNNEL: 2 entries
       seq 5 deny 1.1.1.1/32
       seq 10 permit 0.0.0.0/0 le 32

    !

    R1#show running-config | section router rip
    router rip
     version 2
     network 1.0.0.0
     network 12.0.0.0
     network 192.168.0.0
     distribute-list prefix STOP_TO_R5_TUNNEL out Tunnel0
     no auto-summary

    !

    R5(config-router)#do show run | section router rip
    router rip
     version 2
     network 5.0.0.0
     network 45.0.0.0
     network 192.168.0.0
     distribute-list prefix STOP_TO_R1_TUNNEL out Tunnel1
     no auto-summary
    !
    *Mar  1 01:05:06.203: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

    Now tunnel is up because Tunnel source/destination is learning via
    different interface than tunnel itself. Now remove the static route and
    advertise on RIP.

    R5(config)#no ip route 192.168.11.0 255.255.255.0 Tunnel1
    R5(config)#router rip
    R5(config-router)#network 192.168.55.0
    R5(config-router)#
    !

    R1(config)#no ip route 192.168.55.0 255.255.255.0 Tunnel0
    R1(config)#router rip
    R1(config-router)#network 192.168.11.0

    Now all the network behind the tunnel are reachable via tunnel interface:

    R1#traceroute 192.168.55.1

    Type escape sequence to abort.
    Tracing the route to 192.168.55.1

      1 192.168.0.5 140 msec *  108 msec

    I hope this example helps to clear your doubts, any queries are most welcome.

    HAPPY STUDY

    [:D]

     

  • Hi aristaw,

       As the task is formulated, it does not matter what filtering technique you use, as long as you do not advertise loopbacks over the tunnel (however make sure generally speaking you know what are the advantages/disadvantages of using standard or extended or rpefix-lists in filtering). To conclude, it works also eith your solution, as well as with SG solution. My guess is that you enabled RIP over the tunnel before configuring filtering, thus you ended up in a recursive routing issue.

    Good luck with your studies!

  •  

     

    Access-list worked for me as well. But i really want to know why distribute-list isn't working for everyone.

  • Hi sherlock123,

    What do you mean distribute-list is not working but access-list is working? Can you elaborate little bit more? I would recommed you to see my prevous post on this same thread about Router recursive over Tunnel.

    HAPPY STUDY

    [:D]

  • I was experiencing the same problem like most ppl on this post but like one person stated ensure that you enter the distribute-list command as distribute-list prefix and not just distribute-list. That prefix word solved the problem immediately for me.

  • I agree, using static routes works great for preventing recursive routing, but with this example, the workbook has SW3 and SW4 using a distribute-list to prevent their "own" Loopback address from being learned through the tunnel...

    Please correct me if I am wrong, but shouldn't the distribute-list on SW3 be preventing 150.1.10.0/24 (it's tunnel destination) and SW4 should be preventing 150.1.9.0/24 (it's tunnel destination) from being learned through the tunnel?

    Regardless if you use static routes, ACLs or prefix-lists, in order to prevent recursive routing, you have to prevent the tunnel destination from being learned through the tunnel, so I don't see why you would prevent your own Loopback address from being learned through the tunnel like the workbook has you do. 

    I know that there is more than one way to skin a cat, so I'm just inquiring for clarification...

    Thanks in advance :)

  • Thinking outside of the box, I completely understand the concept...

    If you block your own router's tunnel source from being advertised out of the tunnel, then it won't be advertised to the router termintating the tunnel on the distant end (which prevents the distant end router from learning it's tunnel destination through the tunnel)... So regardless if you use a distribute-list to block your tunnel destination or your tunnel source, it is accomplishing the same task. Cool :).

    No need for clarification... THANKS!

  • I was totally looking at this one sided... Thanks for the post Narayan! 

  • Generally speaking, unless a task forces you to use certain configuration, best approach to avoid GRE recursive routing is to use different IGPs and/or static routing. Use on IGP/EGP to learn through it tunnel endpoints and another IGP/EGP to advertise prefixes over the tunnels;

    Hi Cristian i take inspiration from your sentence above to ask you how to set up those 2 IGPs.

    Maybe do you mean to redistribute prefixes between different IGPs in a controlled manner(metrics) to avoid poisoning of routing table and recursive loops?  Or just advertise separately the 2 prefixes (learned endpoints+advertised prefixes)? Im not sure i understood correctly your thought...

Sign In or Register to comment.