[c-nsp] Dumb question

Wed Aug 3 10:43:37 EDT 2011

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 <zivl at gilat.net> 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:buz.dale at usg.edu]
> Sent: Wednesday, August 03, 2011 4:00 PM
> To: Ziv Leyes; cisco-nsp at puck.nether.net
> 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: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ziv Leyes
> Sent: Wednesday, August 03, 2011 8:54 AM
> To: cisco-nsp at puck.nether.net
> 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  cisco-nsp at puck.nether.net
> 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>