Yup, match community accepts community-list as an argument, not the 'raw' value. So you need first define them
ip community-list 1 permit xx:1 ip community-list 2 permit xx:2 The whole config should be like that RTR1 router bgp 100 nei RTR2 remote-as 100 nei RTR2 send-community nei RTR2 route-map SET_COMM out route-map SET_COMM permit 10 match ip addr pref COMM_XX1 set community xx:1 route-map SET_COMM permit 20 match ip addr pref COMM_XX2 set community xx:2 route-map SET_COMM permit 30 ip prefix-list COMM_XX1 permit 1.1.1.0/24 le 32 ip prefix-list COMM_XX2 permit 2.2.2.0/24 le 32 RTR2 router bgp 100 nei RTR1 remote-as 100 nei RTR1 send-community nei ISP1 remote-as ISP1 nei ISP1 route-map ISP1_OUT out nei ISP2 remote-as ISP2 nei ISP2 route-map ISP2_OUT out route-map ISP1_OUT permit 10 match community ISP1 set as-path prepend 100 100 100 set community none route-map ISP1_OUT permit 20 route-map ISP2_OUT permit 10 match community ISP2 set as-path prepend 100 100 100 set community none route-map ISP2_OUT permit 20 ip community-list ISP1 permit xx:2 ip community-list ISP2 permit xx:1 And you need to reset the BGP sessions to both peers to propagate changed information clear ip bgp ISP[1-2] soft out On Wed, Aug 3, 2011 at 3:19 PM, Ziv Leyes <[email protected]> wrote: > Well, I tried to simplify the scenario to only concentrate on my problem, the > scenario is a little bit more complicated, but not relevant for the question > > The question is, given the fact I'm trying to manage the eBGP advertising > decisions based on what is happening on RTR1. > Let's suppose I need to give operators access only to RTR1 but I want them to > decide which prefixes will be advertised to which ISP, but they can't get > access to RTR2 to do it there, so I want to setup RTR2 to do the advertising > matching the decisions that were made on RTR1. > > I just spoke with a friend and he told me that maybe I need to rewrite the > communities, for example RTR1 advertises prefix 1.1.1.1/24 with community > xx:1 and 2.2.2.2/24 with xx:2 > RTR2 has an incoming route-map towards RTR1 that allows filters routes > according to matching communities. > Now I have two prefixes that are seen with their communities, what I simply > tried to do was a route-map outgoing towards the ISPs that match the > community (that came from the RTR1) and then advertise them over the ISPs > with or without prepending, according to my previously chosen decision. > My friend thinks I need to match the community on the route-map in from RTR1 > and then set a new community, e.g > > route-map RTR1-IN permit 10 > match community xx:1 > set community yy:1 > route-map RTR1-IN permit 20 > match community xx:2 > set community yy:2 > ! > route-map ISP1 permit 10 > match community yy:1 > route-map ISP1 permit 20 > match community yy:2 > set as-path prepend ........ > > and viceversa for ISP2 > > What I tried was matching community xx:1 and xx:2 as they came from RTR1, > perhaps here's the problem? > > Ziv > > > -----Original Message----- > From: Harold 'Buz' Dale [mailto:[email protected]] > Sent: Wednesday, August 03, 2011 4:00 PM > To: Ziv Leyes; [email protected] > Subject: RE: Dumb question > > It seems to me that RTR 2 is the one advertising the routes to ISP1 and ISP2 > and the path from RTR2 to both of these nets is RTR1 via the same link. Would > be much easier to do this from RTR2. > > Buz > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Ziv Leyes > Sent: Wednesday, August 03, 2011 8:54 AM > To: [email protected] > Subject: [c-nsp] Dumb question > > Hi all, > I have the following scenario (excuse my lousy ascii art...) > > > > ISP1 > / > / > / > RTR1 -----iBGP----- RTR2 > \ > \ > \ > ISP2 > > For the simplicity of the case, I have two prefixes, 1.1.1.1/24 and > 2.2.2.2/24, > I want to advertise prefix 1.1.1.1/24 to ISP1 as best, and 2.2.2.2/24 to ISP1 > with prepends, and the opposite too, prefix 2.2.2.2/24 to ISP2 as best and > prefix 1.1.1.1/24 to ISP1 with prepends. > > What I'm trying to do is to set up all in a way that the only place I set up > my decision is on RTR1 only, and that will be reflected via the iBGP to RTR2 > about how I want the prefixes to be advertised to my eBGP neighbors ISP1 and > ISP2 > I tried setting communities, but all I got is RTR2 to see and match the > communities, but based on this, I couldn't get the prefixes advertised to the > ISPs at all. > > What kind of manipulation I need to do in order for the RTR2 after matching > the communities coming from RTR1, to advertise it to the ISPs according to > the priorities I've mentioned before? > > This sounds very basic and not so complicated to do, but I guess I'm missing > something here! > > Please help, and if possible, don't send me links to cisco web site case > studies or to some 300 pages PDF about how BGP and communities work. A simple > straight forward example of how this can be set will be enough. > Thanks! > Ziv > > The information contained in this e-mail message and its attachments is > confidential information intended only for the use of the individual or > entity named above. If the reader of this message is not the intended > recipient, you are hereby notified that any dissemination, distribution or > copying of this communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by replying to the > sender, and then delete the message from your computer. Thank you! > > ******** This mail was sent via Mail-SeCure System.******** > > > > > > ************************************************************************************ > This footnote confirms that this email message has been scanned by > PineApp Mail-SeCure for the presence of malicious code, vandals & computer > viruses. > ************************************************************************************ > > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > ************************************************************************************ > This footnote confirms that this email message has been scanned by > PineApp Mail-SeCure for the presence of malicious code, vandals & computer > viruses. > ************************************************************************************ > > > > > The information contained in this e-mail message and its attachments is > confidential information intended only for the use of the individual or > entity named above. If the reader of this message is not the intended > recipient, you are hereby notified that any dissemination, distribution or > copying of this communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by replying to the > sender, and then delete the message from your computer. Thank you! > > ******** This mail was sent via Mail-SeCure System.******** > > > > > > ************************************************************************************ > This footnote confirms that this email message has been scanned by > PineApp Mail-SeCure for the presence of malicious code, vandals & computer > viruses. > ************************************************************************************ > > > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
