how to interprete the output of show ip route loops

Whilst messing about with iBGP to understand various functions I ran into a problem that turned out to be a routing loop.

The message I saw that set me off investigating loops was:

Dec  9 16:05:47.379: %IPRT-3-RIB_LOOP: Resolution loop formed by routes in RIB

Reading up on this I came across the command show ip route loops, and when I ran it I had the following output:

R3#sh ip route loops
->default:ipv4:base 10.2.4.0/24 -> base 10.2.5.2 bgp 00:19:57
  default:ipv4:base 10.2.5.0/24 -> base 10.2.4.2 bgp 00:19:57 N

My question is, what is this output actually telling me?

 

 

Comments

  • Hi,

    it is just showing you that in the default vrf (normal routing table) for the address family IPv4 a loop accurred between the following two iBGP sessions.

     

    Remember that an iBGP configuration does not have the AS meachanism for loop prevention and therefore you need full mesh connections or a cluster (route-reflector)  to exchange with everyone in the iBGP sphere updates.

    Alessio

     

  • I know this is an old post, but thought I would chip something in as I found this myself in a lab set up and stumbled on this post whilst lookinginto it. The set up is bgp an OSPF in each AS and the AS are separated by a router that is not running any routing protocols (signifying a firewall in between zones).

    Topology looks like this 

    [ AS64513 ( R1 ------ R3 ) ] ------ R4 ------- [ AS64514 (R5 ---- R6) ]

    Routes that were being learnt by R3 in AS64513 from R5 in AS64514 were being learnt with a next hop of the peering address. A static route towards the peering address via the standalone router is needed. This is ok for R3, however, it was passing the route in to R1, its iBGP neighbour, with the next hop value unchanged, so the next hop was not reachable by the R1 iBGP peer in the same AS. I had to change the next hop value to resolve this issue in this instance. This to me, unless I am interpreting it wrong, seems like an error message that isnt necessarily accurate, there was no loop, it just failed the recursive check. 

    *Dec  3 10:34:04.617:
    %IPRT-3-RIB_LOOP: Resolution loop formed by routes in RIB

    R1#show ip cef 155.5.45.5

    155.5.45.5/32

      unresolved via
    155.5.45.0/28

      recursive-looped

    R1#show ip route loops










    ->default:ipv4:base 155.5.45.0/28 -> base 155.5.45.5
    bgp 00:14:37 N

    After changing the next hop to self and thus fulfilling the recursion requirement, the output changes with the next hop interface available.

    R1#show ip cef 155.5.45.5  

    155.5.45.0/28

      nexthop 155.5.13.3 Ethernet1/0

Sign In or Register to comment.