[j-nsp] Juniper BGP Route Metrics

Phil Bedard philxor at gmail.com
Wed May 16 13:57:36 EDT 2007


There is a command "traffic-engineering mpls-forwarding" that restricts
the use of LDP and RSVP paths for route-selection, by lowering the  
metric of
those paths in the inet.0 table.  It will use the paths for  
forwarding via inet.3 but not
in the route-selection process.   This is only an issue if you have the
"traffic-engineering bgp-igp" enabled, do you?

What Sergio wanted was a show extensive on the _next-hop_, not the  
BGP route
itself, because that may be where your issues lie.

Phil



On May 16, 2007, at 12:39 PM, Dan Benson wrote:

> Correct, I am currently using inet.3 for my IBGP next-hop loop  
> addresses
> and therein lies my issue.  Let me take one second and try and
> re-explain my network and what I see my issue as.  I have a national
> network all based on junipers running OSPF, LDP, MPLS and BGP (I and E
> as one would assume). Here is the long and short of my issue.
>
> I learn the same prefix paths from neighboring AS's where I peer  
> and or
> buy connectivity across the country.  I would like to send my  
> traffic to
> the most local interconnect point when sending outbound traffic  
> from my
> AS.   In my network currently  I show on certain prefixes the same AS
> hop count, Metric and Metric2 for my path choices unless I receive  
> a MED
> from a peer.  This leaves my routers to fall to the router-id for the
> path selection which causes my traffic to flow to the wrong  
> interconnect
> for my outbound traffic adding time to my traffic.
>
> I am running LDP on every core router currently tracking IGP and I  
> have
> no issue with this.  I do in my eyes have issue with not being able to
> have my BGP path selection use some form of metric toggle that comes
> from my IGP. At this point the only thing I have been able to do to
> achieve my desired traffic flow is to manually set the neighbor
> preference with a hierarchy based on physical distance from core  
> router
> to core router.  This will be impossible to maintain in a full mesh  
> and
> I think it is a band aid that I do not want to implement. I hope this
> helps with your in-site and I cannot thank you all enough for the  
> help..
>
> The same Prefix paths as before but with more explanation:
>
>> From my LAX-2 Non-Edge router:
>
> show route protocol bgp 155.212.0.0 detail (Random subnet learned  
> from a
> peer AS):
>
> inet.0: 217037 destinations, 706742 routes (217035 active, 2  
> holddown, 0
> hidden)
> 155.212.0.0/16 (3 entries, 1 announced)
>        *BGP    Preference: 170/-91
>                Next-hop reference count: 35478
>                Source: 10.0.0.16
>                Next hop: via at-0/0/0.0, selected
>                Label operation: Push 198480
>                Protocol next hop: 198.32.118.12
>                Indirect next hop: 93403a8 262226
>                State: <Active Int Ext>
>                Local AS:  1784 Peer AS:  1784
>                Age: 4d 14:15:14        Metric: 0       Metric2: 0
>                Task: BGP_1784.10.0.0.16+2131
>                Announcement bits (3): 0-KRT 5-RT 6-Resolve tree 2
>                AS path: 174 14751 14751 14751 I ()
>                Communities: 1784:1001
>                Localpref: 90
>                Router ID: 10.0.0.16
> This source address is the loop of my edge router in NYC.
>
>         BGP    Preference: 170/-91
>                Next-hop reference count: 11931
>                Source: 10.0.0.80
>                Next hop: via at-0/0/0.0, selected
>                Label operation: Push 198576
>                Protocol next hop: 198.32.124.103
>                Indirect next hop: 12734750 262165
>                State: <Int Ext>
>                Inactive reason: Router ID
>                Local AS:  1784 Peer AS:  1784
>                Age: 4d 14:15:31        Metric: 0       Metric2: 0
>                Task: BGP_1784.10.0.0.80+179
>                AS path: 174 14751 14751 14751 I ()
>                Communities: 1784:1001
>                Localpref: 90
>                Router ID: 10.0.0.80
> This source address is the loop of my edge router in Miami.
>
>
>         BGP    Preference: 170/-91
>                Next-hop reference count: 11682
>                Source: 10.0.0.113
>                Next hop: via at-0/0/0.0, selected
>                Protocol next hop: 198.32.176.131
>                Indirect next hop: 9340444 262289
>                State: <Int Ext>
>                Inactive reason: Router ID
>                Local AS:  1784 Peer AS:  1784
>                Age: 4d 14:14:59        Metric: 0       Metric2: 0
>                Task: BGP_1784.10.0.0.113+3209
>                AS path: 174 14751 14751 14751 I ()
>                Communities: 1784:1001
>                Localpref: 90
>                Router ID: 10.0.0113
>
> This source address is the loop of my edge router in LAX, about  
> half a MilliSec from this router itself.  This is the path that  
> would have been preferred before I implemented MPLS as the packet  
> would traverse this edge router itself and be forwarded toward the  
> peer. Thanks again.. //db
>
>
> Sergio D. wrote:
>> Krasi,
>> protocol next-hop uses inet.3 by default.
>>
>> Dan,
>> Can you give us a show route extensive for each protocol next-hop?
>>
>> Thanks,
>> -- 
>> Sergio Danellli
>> JNCIE #170
>> --------------------------------------------------------------------- 
>> ---
>>
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.5.467 / Virus Database: 269.7.1/805 - Release Date:  
>> 5/15/2007 10:47 AM
>>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

Phil Bedard
philxor at gmail.com





More information about the juniper-nsp mailing list