You can also filter on the extended community: ip extcommunity-list 1 permit rt 2:2 ip extcommunity-list 1 permit rt 3:3
route-map matchcomm deny 5 match extcommunity 1 route-map matchcomm permit 10 router bgp <as-num> address-family vpnv4 neighbor <ip of PE2> route-map matchcomm out But yeah it seems a moot, since you only get those routes on triggered BGP updates and the other side does not install it unless it has those route targets configured. HTH, On Wed, Jan 20, 2010 at 2:34 AM, Taqdir Singh <[email protected]>wrote: > Hi Joe: > > I tried ORF also, but ORF only seems to be working for eBGP not iBGP. > > when i use ORF for iBGP, it filters the route in BGP table but routes still > come and get denied by prefix list on local router. > > so now come back to our scenario again :-) > > PE1 and PE2 are in same AS, so I think ORF wont be helpfull here. > > > On Wed, Jan 20, 2010 at 12:43 PM, Joe Astorino <[email protected]>wrote: > >> That is just how BGP functions my friend : ) Now, you COULD configure >> something known as outbound route filtering (ORF) to take care of this >> problem. With ORF basically what happens is you configure an inbound >> prefix-list on a remote PE router that decides what routes you would >> like to get. Then you configure the same router to SEND that >> prefix-list to the other side. The other side is configured to >> receive this prefix-list. When this happens, the other side will only >> in turn send to you the prefixes you want to receive. So, you are >> essentially telling your upstream router what to send and not send to >> you. >> >> Check this out: >> >> http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/ft11borf.html#wp1048417 >> >> On Wed, Jan 20, 2010 at 2:03 AM, Taqdir Singh <[email protected]> >> wrote: >> > >> > >> >> Hi Bryan : >> >> >> >> Thanks for replly. >> >> >> >> But my question was different. >> > >> > You can assume P routers in between to all PE routers >> > >> > My question was why would PE1 send all the route updates of all >> customers >> > to PE2 at first place if through PE2 doesnt have those customers but >> only >> > have single customer ? >> > >> > why we are wasting the CPU and bandwidth resources for those routing >> updates >> > which even PE2 doesnt need them . >> >> >> >> On Wed, Jan 20, 2010 at 11:06 AM, Bryan Bartik <[email protected]> >> >> wrote: >> >>> >> >>> Taqdir, >> >>> >> >>> That is not a typical MPLS VPN topology. There is usually P routers >> >>> involved that connect the PE routers, and there is usually more than >> one >> >>> path between respective PE loopbacks. >> >>> >> >>> Also, MPBGP is just like normal BGP. You need some a full mesh among >> >>> peers, route reflection or confederations to satisfy the reachability >> issues >> >>> you mention. >> >>> >> >>> Even if PE1 link to PE3 failed, are their loopbacks not in OSPF? Can >> you >> >>> not set up an MP-BGP session between them? >> >>> >> >>> On Tue, Jan 19, 2010 at 10:03 PM, Taqdir Singh < >> [email protected]> >> >>> wrote: >> >>>> >> >>>> Hi Friends >> >>>> >> >>>> I have a scenario here for MPLS VPNS, please see attached diagram >> >>>> >> >>>> Suppose we have so many customers connected on PE1 with RT of 1:1, >> 2:2, >> >>>> 3:3 ..... each RT related to separated customer. >> >>>> >> >>>> Now on my PE2 router only one customer is connected with RT of 1:1., >> >>>> Remaining all other remote customer sites are connected on PE3 with >> RT 2:2, >> >>>> 3:3....etc >> >>>> >> >>>> So now when MPBGP on PE1 will send updates, it will send updates of >> all >> >>>> customers routes to PE2 and PE2 will ignore those routes not matching >> its >> >>>> RT. >> >>>> >> >>>> So question, here is why PE1 would send all updates to PE2 at first >> >>>> place, why would I waste my bandwidth ? >> >>>> >> >>>> 2nd Question >> >>>> >> >>>> If link between PE1 and PE3 fails, then I want all the updates that >> PE3 >> >>>> was getting to come via PE2' >> >>>> >> >>>> is this possible ? >> >>>> >> >>>> hope my question is a valid question >> >>>> >> >>>> -- >> >>>> TAQDIR SINGH >> >>>> Network Engineering Professional >> >>>> (+91) 991.170.9496 | (+91) 801.041.5988 >> >>>> >> >>>> One who asks is a fool for a moment, one who doesn't ask remains fool >> >>>> for ever >> >>>> >> >>>> _______________________________________________ >> >>>> For more information regarding industry leading CCIE Lab training, >> >>>> please visit www.ipexpert.com >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Bryan Bartik >> >>> CCIE #23707 (R&S, SP), CCNP >> >>> Sr. Support Engineer - IPexpert, Inc. >> >>> URL: http://www.IPexpert.com >> >> >> >> >> >> >> >> -- >> >> TAQDIR SINGH >> >> Network Engineering >> >> (+91) 991.170.9496 | (+91) 801.041.5988 >> >> >> >> One who asks is a fool for a moment, one who doesn't ask remains fool >> for >> >> ever >> > >> > >> > >> > -- >> > TAQDIR SINGH >> > Network Engineering >> > (+91) 991.170.9496 | (+91) 801.041.5988 >> > >> > One who asks is a fool for a moment, one who doesn't ask remains fool >> for >> > ever >> > >> > _______________________________________________ >> > For more information regarding industry leading CCIE Lab training, >> please >> > visit www.ipexpert.com >> > >> > >> >> >> >> -- >> Regards, >> >> Joe Astorino CCIE #24347 (R&S) >> Sr. Technical Instructor - IPexpert >> Mailto: [email protected] >> Telephone: +1.810.326.1444 >> Live Assistance, Please visit: www.ipexpert.com/chat >> eFax: +1.810.454.0130 >> >> IPexpert is a premier provider of Classroom and Self-Study Cisco CCNA >> (R&S, Voice & Security), CCNP, CCVP, CCSP and CCIE (R&S, Voice, >> Security & Service Provider) Certification Training with locations >> throughout the United States, Europe and Australia. Be sure to check >> out our online communities at www.ipexpert.com/communities and our >> public website at www.ipexpert.com >> > > > > -- > TAQDIR SINGH > Network Engineering > (+91) 991.170.9496 | (+91) 801.041.5988 > > One who asks is a fool for a moment, one who doesn't ask remains fool for > ever > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > -- Sergio Danelli JNCIE #170
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
