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 : [email protected] 
[mailto:[email protected]] De la part de Tore Anderson
Envoyé : mercredi 4 février 2009 14:23
À : [email protected]
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:

t...@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

t...@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 [email protected] 
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.
********************************
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp

Reply via email to