Ip prefix-list

kumarpmt83 · ‎02-22-2012

Hi,

i have cisco 2800 router with the following config:

we have two service provider.

Lan IP : 10.10.70.0/23

Bsnl wan : 192.168.24.56/30

Tata wan : 10.70.56.36/30

router bgp 95001

no synchronization

bgp log-neighbor-changes

network 10.10.70.0 mask 255.255.254.0

network 10.10.70.0 mask 255.255.255.0

network 172.16.0.3 mask 255.255.255.255

neighbor 10.70.56.35 remote-as 6855

neighbor 10.70.56.35 route-map EBGP-TATAWAN out

neighbor 192.168.24.57 remote-as 7839

neighbor 192.168.24.57 description ***EBGP Peer to BSNL***

neighbor 192.168.24.57 soft-reconfiguration inbound

neighbor 192.168.24.57 weight 100

neighbor 192.168.24.57 route-map EBGP-BSNLWAN out

ip prefix-list BSNL-LANROUTES seq 10 permit 10.10.70.0/24

ip prefix-list BSNL-LANROUTES seq 20 permit 10.10.70.0/23

!

ip prefix-list TATA-LANROUTES seq 10 permit 10.10.71.0/24

ip prefix-list TATA-LANROUTES seq 20 permit 10.10.70.0/23

route-map EBGP-TATAWAN permit 10

match ip address prefix-list TATA-LANROUTES

route-map EBGP-BSNLWAN permit 10

match ip address prefix-list BSNL-LANROUTES

what does mean the above configuration.

what is prefix-list??what is the purpose we use it??

i have confused with the configuration.

Can anyone tell me...

cadet alain · ‎02-22-2012

Hi,

here it does nothing because in your route-map statements you have no set clause.

prefix-list match on prefix and prefix-length:

so

ip prefix-list TATA-LANROUTES seq 20 permit 10.10.70.0/23

will match prefixes which have the 23 first bits corresponding to the address with a mask of 255.255.254

so in binary 10.10.70.0 is 00001010 00001010 01000110 00000000

which means that 10.10.71.0/23 and 10.10.70.0/23 will match this prefix-list

whereas 10.10.70.0/24 ge 23 le 23 will only match 10.10.70.0/23

Regards.

Alain

Don't forget to rate helpful posts.

Peter Paluch · ‎02-22-2012

Alain,

here it does nothing because in your route-map statements you have no set clause

Not entirely These prefix lists perform route filtering here. Only those prefixes which are permitted in the prefix-lists will be advertised to the neighbors. Prefixes which are not explicitly stated here will be removed from advertisements (by virtue of the invisible route-map deny statements at the end of both route-maps here).

Best regards,

Peter

cadet alain · ‎02-22-2012

Hi Peter,

so much for me, I had forgotten this fact( seems like I didn't digest everything completely since my last studies )

And it also appears my understanding of the prefix-list must also be reviewed.

So a lot of work to do yet to not post stupid answers like this one anymore and to succeed the Lab.

Regards.

Alain

Don't forget to rate helpful posts.

Peter Paluch · ‎02-22-2012

Alain,

Don't worry at all. The interaction between different objects in IOS is less than intuitive, and the combination of prefix-lists and route-maps is no different. For example, to this day, I do not remember the order of distribute-list/prefix-list, filter-list and route-map when all applied to a particular neighbor in BGP, and even when I look it up, I just don't find it intuitive enough to keep it in my memory

Take care.

Best regards,

Peter

milan.kulik · ‎02-22-2012

Hi Peter,

based on the order listed in my favourite book

http://www.ciscopress.com/title/1587051095

I beleive the mnemonic might be following:

Let's make the filtering most effective for a site connected to the Internet.

So inbound direction:

1. Fiter list - filtering by AS numbers will eliminate most prefixes if used

2. Route-map

3. Distribute list/prefix list - usually not used to filter Internet subnets

Outbound direction:

1. Distribute list/prefix list - you might want to advertise just some subnets from your site

2. Prefix list via ORF - just another rare form of the same filtering

3. Filter list

4. Route-map - should not be applied before filter list as might be modifying the as-path by prepending or removing private as-numbers, etc.

Does it make a sense?

BR,

Milan

Peter Paluch · ‎02-22-2012

Hi Milan,

Thanks! This one looks logical. I have to think it over a couple of times... but I like it!

And regarding the ORF - yeah, it's rare but I like its idea very much!

Best regards,

Peter

milan.kulik · ‎02-22-2012

Hi Alain,

no,

ip prefix-list TATA-LANROUTES seq 20 permit 10.10.70.0/23

will match only a single prefix: 10.10.70.0/23.

Nothing more.

That's the differentce between using prefix-lists and access-lists to filter BGP prefixes.

BR,

Milan

Peter Paluch · ‎02-22-2012

Hi Milan,

Yes, I agree. I did not want to go into gory details but perhaps they will be useful after all.

Assume the prefix-list as follows:

ip prefix-list P permit 10.10.10.0/24

This prefix-list matches (and permits) only the network 10.10.10.0/24 exactly. No subnets of this network are matched. In other words, if the prefix-list entry specifies only the network and mask without further operators, an exact match of the address and netmask is required.

Let's modify the prefix-list as follows:

ip prefix-list P permit 10.10.10.0/24 ge 25

This prefix-list matches those subnets of the 10.10.10.0/24 network whose netmask is greater or equal to /25. E.g., the subnet 10.10.10.64/25 would match, the subnet 10.10.10.128/25 would match, the subnet 10.10.10.0/25 would match but the network 10.10.10.0/24 itself would not match because its netmask is not greater or equal than /25

Let's modify the prefix-list again:

ip prefix-list P permit 10.10.10.0/24 le 29

This prefix-list matches those subnets of the 10.10.10.0/24 network whose netmask is less or equal to /29. E.g., network 10.10.10.0/24, 10.10.10.0/25, 10.10.10.128/25, 10.10.10.64/26, etc. would match. However, networks like 10.10.10.0/30 or 10.10.10.4/31 would not match because although they are subnets of the 10.10.10.0/24 range, their netmask is not less or equal than /29.

We can combine the ge and le operators together, in which case both these constraints must apply for the network/mask combination to produce a match.

In technical words, having the prefix-list as follows:

ip prefix-list P permit W.X.Y.Z/N ge G le L

matches all networks of the form A.B.C.D/M that fulfill all of the following criteria:

A.B.C.D && N == W.X.Y.Z
- The network A.B.C.D must be a subnet of the network W.X.Y.Z; the && operator signifies bitwise AND
G <= M <= L
- The netmask must be greater or equal than G but less or equal than L

In case either G or L is not specified, the corresponding test is not performed. If neither G nor L are specified, the network and mask must match exactly.

Best regards,

Peter

Peter Paluch · ‎02-22-2012

Hello Dhineshkumar,

A prefix-list is an optimized filter used to select which IP network addresses (also called prefixes) shall be advertised and which shall be removed in routing protocol advertisements. A prefix-list is similar to an ACL in that it permits or denies IP network addresses based on its criteria, but is more concise, better readable, more effectively evaluated and the preferred way of configuring route filter in routing protocols. It cannot be used to filter data traffic on interfaces.

You have two prefix-lists configured. The BSNL-LANROUTES prefix-list allows two networks to be advertised: 10.10.70.0/23 and 10.10.70.0/24. The TATA-LANROUTES allows another two networks to be advertised: 10.10.70.0/23 and 10.10.71.0/24. The BSNL prefix-list is used in a route-map towards your neighbor 192.168.24.57, the TATA prefix-list is used in a route-map towards your neighbor 10.70.56.35. Each of these prefix-lists therefore filters the networks that are announced in BGP to these respective neighbors.

I see you are using the soft-reconfiguration inbound for your neighbor 192.168.24.57. This feature is obsolete and should not be used anymore, as it is replaced with a more flexible and dynamic route refresh capability. I suggest you remove this command from your configuration (after obtaining an approval, of course). Regarding the soft-reconfiguration and route refresh, I suggest reading this thread:

https://supportforums.cisco.com/message/829228#829228

Best regards,

Peter

kumarpmt83 · ‎02-22-2012

Thank for ur valuable information.

i have one question in my configuration.

bsnl is our primary link and Tata is Secondary link.

In our office appox 330 users are available and we are given IP series for some users 10.10.70.0 and we give some users 10.10.71.0.

We want all users to be work with BSNL link and incase BSNL link down means it will take the Tata route.

If the BSNL came means we want all users back work with BSNL Link.

If any configuration changes required for my requirement.

If it is need kindly tell me.

milan.kulik · ‎02-23-2012

Hi,

is this the same problem you are discussing here:

https://supportforums.cisco.com/thread/2132481?tstart=30

?

And this si the client site?

As long as the BSNL peering is Up, all prefixes received from that would be preferred.

So you use the BSNL circuit to send the traffic out from this site.

Currently, you are advertising 10.10.70.0/24 to BSNL and 10.10.71.0/24 to TATA, plus 10.10.70.0/23 to both.

Due to "longest match wins" routing rule, incoming traffic for 10.10.70.0/24 should come from BSNL and for 10.10.71.0/24 should come from TATA (if the sending device has got both provider connections available).

In a case one provider circuit fails, the other provider takes all the traffic (due to 10.10.70.0/23 advertised to both).

So under normal conditions, you are probably using an asymmetric routing for 10.10.71.0/24 - traffic is sent out via BSNL but received via TATA.

Is this really what you want?

Shouldn't you simply advertise only 10.10.70.0/23 to both?

HTH,

Milan

kumarpmt83 · ‎02-23-2012

In my setup both ISP providers are available .

If i advertise the 10.10.70.0/23 only for both prefix means which provider route they take first.

I want BSNL as Primary route and Tata as secondary route.

In the configuration i give weight value to the BSNL Link.

If any problem to be happen due to the weight value.

milan.kulik · ‎02-23-2012

Hi,

ad "If i advertise the 10.10.70.0/23 only for both prefix means which provider route they take first")

Both providers will have the same prefix available in thier routing. It depends on the remote site routing policy which provider it will take to send the traffic to your site. If configured the same way as this site, it will prefer BSNL, see below.

ad "In the configuration i give weight value to the BSNL Link")

Yes, as weight attribute value comparing is the first step in the BGP best path decision algorithm, the prefixes received from BSNL will be chosen in your case - TATA prefixes having no wight assign means 0 calculated.

HTH,

Milan

If any problem to be happen due to the weight value.

kumarpmt83 · ‎02-23-2012

Yesterday in My client site Bsnl link is failed .

So all the traffic went to Secondary Tata link and the reverse traffic in headoffice also takes the Tata link because i given the static route in the Headoffice BSNL router like this.

ip route 10.10.70.0 255.255.254.0 10.10.30.161 250

After the Bsnl link came in the client end all forward routes are return taken to Bsnl link from Tata.

In the headoffice end reverse trafffic also take the Bsnl Link.

But my problem is in the reverse traffic 10.10.70.0/24 only takes the Bsnl link and the 10.10.71.0/24 takes the tata link.

The 10.10.71.0/24 does not take the Bsnl link.

where is the issue???