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 [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp Phil Bedard [EMAIL PROTECTED] _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
