[j-nsp] JUNOS resolves indirect next-hops using other BGP routes

david.roy at orange-ftgroup.com david.roy at orange-ftgroup.com
Wed Feb 4 08:36:14 EST 2009


The protocol next-hop seems to be resolvable : but it is not directly known in our IGP. So you have a recursive lookup til you find a forwarding next-hop. 

The Junos next-hop resolver prevents infinite recursive lookup but I don't know if we can limite the number of recursive lookup allowed.

Regards,
David


 

-----Message d'origine-----
De : juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] De la part de Tore Anderson
Envoyé : mercredi 4 février 2009 14:23
À : juniper-nsp at puck.nether.net
Objet : [j-nsp] JUNOS resolves indirect next-hops using other BGP routes

Hi list,

I've just noticed that my MXes appears to be happily using external BGP routes in order to resolve indirect next-hops on other BGP routes.

See the following example.  Due to my own paranoia it's anonymised - 10.0.0.x is my own internal prefix.  195.18.241.97 is the next-hop on my transit link to AS3307, however I (intentionally) forgot to activate OSPF on this upstream interface.  So the route to this next-hop is only visible to other routers in my network through another transit link to
AS12552 on another router.  This is how it ends up looking on an MX 240 with no external BGP sessions:

tore at mx240> show route 60.235.0.0 extensive

inet.0: 274939 destinations, 548848 routes (274938 active, 0 holddown, 1 hidden)
60.235.0.0/18 (1 entry, 1 announced)
TSI:
KRT in-kernel 60.235.0.0/18 -> {indirect(1048576)}
        *BGP    Preference: 170/-51
                Next hop type: Indirect
                Next-hop reference count: 4
                Source: 10.0.0.4
                Next hop type: Router, Next hop index: 582
                Next hop: 10.0.0.21 via xe-1/1/0.0, selected
                Protocol next hop: 195.18.241.97
                Indirect next hop: 1ad1e500 1048576
                State: <Active Int Ext>
                Local AS: 12345 Peer AS: 12345
                Age: 1:06:05    Metric2: 20
                Task: BGP_12345.10.0.0.4+179
                Announcement bits (3): 0-KRT 7-Resolve tree 2 8-Resolve tree 3
                AS path: 3307 1299 4134 17633 I
                Accepted
                Localpref: 50
                Router ID: 10.0.0.4
                Indirect next hops: 1
                        Protocol next hop: 195.18.241.97 Metric: 20
                        Indirect next hop: 1ad1e500 1048576
                        Indirect path forwarding next hops: 1
                                Next hop type: Router
                                Next hop: 10.0.0.21 via xe-1/1/0.0
                        195.18.128.0/17 Originating RIB: inet.0
                          Metric: 20                      Node path count: 1
                          Indirect nexthops: 1
                                Protocol Nexthop: 10.0.0.1 Metric: 20 
                                Indirect nexthop: 8e2d140 1048575
                                Indirect path forwarding nexthops: 1
                                        Nexthop: 10.0.0.21 via xe-1/1/0.0
                                10.0.0.1/32 Originating RIB: inet.0
                                  Metric: 20                              Node path count: 1
                                  Forwarding nexthops: 1
                                        Nexthop: 10.0.0.21 via xe-1/1/0.0

tore at mx240> show route 195.18.241.97

inet.0: 274922 destinations, 548808 routes (274921 active, 0 holddown, 1 hidden) @ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both

195.18.128.0/17    *[BGP/170] 9w6d 00:37:47, localpref 100, from 10.0.0.1
                      AS path: 12552 3307 I
                    > to 10.0.0.21 via xe-1/1/0.0
                    [BGP/170] 2w6d 21:56:15, localpref 100, from 10.0.0.2
                      AS path: 12552 3307 I
                    > to 10.0.0.22 via xe-1/1/0.0

This behaviour appears to run counter to the documentation, which states only IGP routes is used for this:

> JUNOS software supports the concept of an indirect next hop for all 
> routing protocols that support indirectly connected next hops, also 
> known as third-party next hops.

> Because routing protocols such as internal BGP can send routing 
> information about indirectly connected routes, the JUNOS software 
> relies on routes from intra-AS routing protocols (OSPF, IS-IS, RIP, 
> and static) to resolve the best directly connected next hop. The 
> Routing Engine performs the task of route resolution to determine the 
> best directly connected next hop and install the route to the Packet 
> Forwarding Engine.

-- https://www.junipernetworks.com/techpubs/software/junos/junos93/swconfig-routing/swconfig-routing.pdf

I would have expected the MX to not install the route into the FIB at all due to the next-hop being unresolvable.  Does anyone know if the current behaviour is intentional or if it's a bug?  Is there any way to prevent BGP routes from being used for resolving indirect next-hops?

The JUNOS version is 9.3R1.7, by the way.

Regards,
--
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************


More information about the juniper-nsp mailing list