Got it I would change that message to : ALWAYS USE SEND-LABEL on IBGP, DO NOT LOOSE POINTS! :)
Thanks 2009/10/31 Rick Mur <[email protected]> > That message is quite dangerous to assume. > Like you saw when the EBGP prefix (where labels are exchanged on the > ASBR's) is NOT known in your IGP topology. LDP only assigns labels to IGP > prefixes. Therefore the labels that are exchanged on the AS border, are NOT > known within that network, like Bryan said, on the RR's. > > You definitely NEED to add send-label on your IBGP neighbors as well so the > traffic is label switched within your AS as well. It will definitely won't > work if you have a couple routers within your AS (when they are NOT ASBR's). > So it's not always when you have 2 connections, it depends on the situation, > check your LFIB and see how the traffic is label switched (or not) > > -- > > Regards, > > Rick Mur > CCIE2 #21946 (R&S / Service Provider) > Sr. Support Engineer – IPexpert, Inc. > URL: http://www.IPexpert.com > > On 30 okt 2009, at 20:34, André Luiz Bernardes wrote: > > Hey Brian and Shai > > I believe some things are for the better !!! Since this morning I believed > that sending labels other than to EBGP was just cosmetic as all the labs I'd > done worked fine without that. What I didn't took in account was what > happened when we have dual IPV4 eBGP between the ASs and for some reason > traffic is asymmetrical or just preferring the IBGP path to reach the > next-hop. > > I am working on INE workbook right now and could reproduce this issue. What > happened was that the VPN PE router was also the ASBR and instead of > preferring the ASBR interface to get to the next AS, it was doing so via > IBGP than taking the second ASBR. > > Sorry to post outputs from another vendor workbook but I can wait to share > that :) > > > I am sitting on the PE router on AS 100, which is also de ASBR. The PE > router on AS 200 is 20.1.1.1 > > > Rack1R7#ping 119.0.0.1 sou lo0 > Sending 5, 100-byte ICMP Echos to 119.0.0.1, timeout is 2 seconds: > Packet sent with a source address of 10.1.7.7 > ..... > Success rate is 0 percent (0/5) > > > Rack1R6#sh ip cef 20.1.1.1 detail > 20.1.1.1/32, version 185, epoch 0, cached adjacency 20.1.46.4 > 0 packets, 0 bytes > tag information set, shared > local tag: BGP route head > via 20.1.4.4, 4 dependencies, recursive > next hop 20.1.46.4, Ethernet0/0 via 20.1.4.4/32 > valid cached adjacency > tag rewrite with Et0/0, 20.1.46.4, tags imposed: {} <<<<< NO LABEL > HUMMMMMMMM > > > > Rack1R6#sh ip bgp labels > Network Next Hop In Label/Out Label > 20.1.1.1/32 20.1.4.4 nolabel/nolabel <<<<< No label from > iBGP path > 20.1.1.1/32 20.1.26.2 nolabel/20 <<<<< There is a > label here learned via eBGP > > > > **** I CONFIGURED SEND-LABEL BETWEEN MY IBGP NEIGHBORS WITHIN AS 100 > ***** > > > Rack1R6#sh ip cef 20.1.1.1 detail > 20.1.1.1/32, version 193, epoch 0, cached adjacency 20.1.46.4 > 0 packets, 0 bytes > tag information set > local tag: 29 > fast tag rewrite with Et0/0, 20.1.46.4, tags imposed: {31} > via 20.1.4.4, 4 dependencies, recursive > next hop 20.1.46.4, Ethernet0/0 via 20.1.4.4/32 > valid cached adjacency > tag rewrite with Et0/0, 20.1.46.4, tags imposed: {31} <<<<< HERE IS > MY LABEL GUYS!!!!!!!!!! > > > Rack1R6#sh ip bgp labels > Network Next Hop In Label/Out Label > 20.1.1.1/32 20.1.4.4 29/31 <<<<< Label from > IBGP > 20.1.1.1/32 20.1.26.2 29/20 <<<<< Label from > EBGP > > > NOW MY TRAFFIC GETS THRU!!!!!!!!!!!!!!!!!!!! > > Rack1R7#ping 119.0.0.1 sou lo0 > > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 119.0.0.1, timeout is 2 seconds: > Packet sent with a source address of 10.1.7.7 > !!!!! > Success rate is 100 percent (5/5), round-trip min/avg/max = 92/94/100 ms > > > > Message is... USE SEND-LABELS between IBGP when doing Inter-AS VPNs with > dual interconnections!!! > > Best > > Andre > > > > On Fri, Oct 30, 2009 at 3:26 PM, Bryan Bartik <[email protected]>wrote: > >> Hey guys, >> >> I think it depends on what the scenario is, and what the next-hop is of >> the VPN route. For example, if you are doing MP-EBGP between >> route-reflectors in inter-AS scenario, the PE routers may need labels for >> the PE routers in the other AS. If you do not have send-label between the >> RRs and the PEs (IBGP) then the PE routers cannot properly tag the packets. >> >> On Fri, Oct 30, 2009 at 9:36 AM, Shai Loufton <[email protected]> wrote: >> >>> I am now actually on a proctor labs' 7200/ATM Rack now doing the second >>> VOL II lab and I see exactly what you describe – it works with just enabling >>> "send-label" on the ASBRs (and "set mpls-label" if there is a route-map in >>> between). >>> >>> >>> I cannot think of a reason of doing the LSP as a BGP LSP from end to end >>> – can anyone else comment here about this also? >>> >>> >>> BTW – thanks André Luiz Bernardes for helping me before …. – I will do >>> the 1st lab tomorrow again – hopefully will understand it all and all >>> will work eventually after I am done with it …. >>> >>> >>> >>> Shai L >>> >>> >>> *From:* [email protected] [mailto: >>> [email protected]] *On Behalf Of *Andr? Luiz Bernardes >>> *Sent:* Friday, October 30, 2009 4:17 PM >>> *To:* [email protected] >>> *Subject:* [OSL | CCIE_SP] BGP Labels, send or not to send.... >>> >>> >>> Hello guys >>> >>> I have this doubt here.. when configuring Inter-AS VPN we have to build >>> an e2e label path to get VPN traffic flow between ISPs. Most of the times we >>> are required to exchange loopbacks labels via IPv4 eBGP sessions between ASs >>> since LDP is not allowed. >>> >>> Well... I have done this several times already on different vendor's >>> wookbooks and that works fine just by configuring BGP send-label feature >>> (and mpls set-label on route-maps) only on EBGP sessions. My questions is >>> why worbook solutions always require configuring BGP label distribuition >>> also for IBGP session? Is this just a best practice or is there any >>> underlying issue that does not come up on workbook scenarios due to reduced >>> topology... >>> >>> Thanks >>> >>> Andr'e >>> >>> _______________________________________________ >>> For more information regarding industry leading CCIE Lab training, please >>> visit www.ipexpert.com >>> >>> >> >> >> -- >> Bryan Bartik >> CCIE #23707 (R&S), CCNP >> Sr. Support Engineer - IPexpert, Inc. >> URL: http://www.IPexpert.com >> > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
