cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
413
Views
5
Helpful
6
Replies

access-list for community attribute.

amms68958
Level 1
Level 1

Hi all,

While going thru the RFC for BGP community attribute,I came across a sample conf.

"Note: The community can also be configured based on IP prefixes

instead of AS numbers. For example,

!

access-list 101 permit ip 192.160.154.0 0.0.0.0 255.255.255.0 0.0.0.0

!

route-map config-community permit 10

match ip address 101

set community 0x0DE90046

route-map config-community permit 20

match as-path 1 "

I have 3 questions

1) Whether source and destination addresses given in the access list is valid? The source address is 192.160.154.0 and wild card mask is 0.0.0.0 .Means 192.160.154.0 is the valid address after masking...But it is not a host address ,but a network address..So whether the author intended to say that any traffic from 192.160.154.0 network..?

2) The destination address and mask is given as 255.255.255.0 and 0.0.0.0. Can you pls tell me what is the destination address in this case..?

3) And most important,the community value of 0x0DE90046 will be assigned to which all prefixes or traffic..?

Thanks in advance..

Thomas.

2 Accepted Solutions

Accepted Solutions

Harold Ritter
Cisco Employee
Cisco Employee

1) The ACL entry used in this context as a totally different meaning. The source becomes related to the prefix itself and the the destination to the prefix lenght. So in this specific example, the prefix is 192.160.154.0 with the source mask indicating a perfect match and the prefix lenght is 24 (or 255.255.255.0) with a destination mask also indicating a perfect match. This is equivalent to configuring the following prefix-list:

ip prefix-list 101 permit 192.160.154.0/24

2) As explained in one, the destination refers to the prefix lenght, which in this case is 24.

3) In this case, only to prefix 192.160.154.0/24

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

View solution in original post

ruwhite
Level 7
Level 7

I don't know that it's document anyplace, but when you're using an extended access list to filter BGP routes, the destination ipaddress in the access list is actually matched against the subnet mask. In this case, the filter wll match 192.160.154.0/24, since the destination address in the exteneded access list is 255.255.255.0.

The community indicated will be assigned to the prefix 192.160.154.0/24. This example could be clarified with the use of a prefix list, if you send me the url you found this on, I can ask the documentation folks to clean this up a bit, or include multiple examples, with a note about how the extended access list is used here.

:-)

Russ.W

View solution in original post

6 Replies 6

Harold Ritter
Cisco Employee
Cisco Employee

1) The ACL entry used in this context as a totally different meaning. The source becomes related to the prefix itself and the the destination to the prefix lenght. So in this specific example, the prefix is 192.160.154.0 with the source mask indicating a perfect match and the prefix lenght is 24 (or 255.255.255.0) with a destination mask also indicating a perfect match. This is equivalent to configuring the following prefix-list:

ip prefix-list 101 permit 192.160.154.0/24

2) As explained in one, the destination refers to the prefix lenght, which in this case is 24.

3) In this case, only to prefix 192.160.154.0/24

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

ruwhite
Level 7
Level 7

I don't know that it's document anyplace, but when you're using an extended access list to filter BGP routes, the destination ipaddress in the access list is actually matched against the subnet mask. In this case, the filter wll match 192.160.154.0/24, since the destination address in the exteneded access list is 255.255.255.0.

The community indicated will be assigned to the prefix 192.160.154.0/24. This example could be clarified with the use of a prefix list, if you send me the url you found this on, I can ask the documentation folks to clean this up a bit, or include multiple examples, with a note about how the extended access list is used here.

:-)

Russ.W

Hi Harold and Russel,

Thanks for your replies..It really helps in clarifying my doubts..

Russel,

I found this sample configuration in RFC 1998.(Appendix A.Community configuration.).

.I went through this just to get more info abt one of your previous posts.

Pls refer to one of your previous answers to the question "BGP Route announcement".

It would be great if any of you could point me some urls,which are covering the better use of community attributes in ISP environment..

Thanks again,

Thomas.

Interesting.... I don't think I'll be rewriting RFC1998 to replace the examples any time soon, though I could ask the authors about doing that. :-)

As for good links on using communities, I don't know of any off the top of my head.

I would recommend _Pratical BGP_ on Addison Wesley as a good starting point--there's an entire chapter by Danny McPherson on policy in ISP environments.

:-)

Russ.W

Thanks for your reply...

I have 2 more questions.

1)Just curious regarding the use of the access -list..

Say,If I want the same community value to be assigned to 192.160.154.0/24 and 192.160.154.0/26 prefixes.

so I will configure the access-list as

access-list 101 permit ip 192.160.154.0 0.0.0.0 255.255.255.192 0.0.0.63..So,instead of using prefix lists,I can use extended access list for matching prefix lenths..Pls correct me if I am wrong..

2) My second question is regding community attribute.I have read that we can assign community to IP prefix,As numbers..But my question is whether we can assign a specific community to a particular session,so that I can manipulate the traffic for that session..

Just take a note of an imaginary scenario below..

I am a Tier 3 ISP in India,having uplinking with 2 Tier 2 ISPs.I have an EBGP customer having his own Ip address range say,200.200.100.0/24.The customers servers are hosted in a Tier 1 ISP in U.S,using the ISPs Ip address,say 20.20.10.0/24.So my question is whether I can assign a specific community to this session,and manipulate the session traffic (both incoming and outgoing) based on the community atribute,by something like this,

access-list 101 permit ip 200.20.100.0 0.0.0.255 20.20.10.0 0.0.0.255

route-map community permit 10

match ip address (session) 101

set community 100

I would appreciate if anyone of you could give some valuable inputs regarding this so that I can continue my learning and make my fundamentals clear..

Thanks,

Thomas.

You can use either extended access lists or prefix lists for this, yes.... I generally prefer prefix lists, I think they're easier to read and understand quickly and correctly.

For you second question, you can set a single community on all the routes being learned from a specific SP by just leaving out the match clause in the route map. You can set more than one community on a route, of course, so you could set one commmunity indicating where the route was learned, and another based on some other local policy, etc.

:-)

Russ.W