Re: IP Prefix-list

From: Mohit Garg <mohit.v.garg_at_gmail.com>
Date: Tue, 19 May 2009 00:05:13 +0530

hello,

Please go thorugh this doc ...its guud

Mohit

On Mon, May 18, 2009 at 11:50 PM, Wouter Prins <wp_at_null0.nl> wrote:

> Hello Mike/Arnold, ;)
>
> This should help:
> http://blog.internetworkexpert.com/2007/12/26/how-do-prefix-lists-work/
>
> 2009/5/18 mike arnold <haynessmith70_at_gmail.com>
>
> > Hi,
> >
> > Am not perfect in prefix-lists can anybody send me a link of tutorials
> and
> > questions so that i can solve by my own.
> >
> > Thanks
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Wouter Prins
> wp_at_null0.nl
> 0x301FA912
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Mohit .V. Garg
~A prefix-list matches on prefix lengths and ACL's matches on subnets.  With a standard ACL the wildcard mask says nothing about the prefix the route must have to match.
ACL permit 10.0.0.0 0.255.255.255 matches all routes with 10.0.0.0 but the prefix could be /8 /16 /32 etc.  ACL permit 10.0.0.0 255.255.255.255 matches the same as above , same as host 10.0.0.0 With a standard ACL you have no control in matching prefix lengths. With an extended ACL with (in believe only BGP) you have more control, but a
prefixlist is easier.
To match routes with a certain prefix , a prefixlist is the best option.  It not only matches on subnet but you also have control on the prefix of that subnet.
So you can permit a 10.0.0.0/8 but not a 10.0.0.0/16 route.
Prefix list permit 10.0.0.0/8 only matches 10.0.0.0/8 and not /16 etc.
In the simplest form a prefix-list simply matches an EXACT prefix.  Forget about masks for now.  For example:
Ip prefix-list pants permit 192.168.1.0/24   <------- This will permit ONLY the specific network 192.168.1.0/24 , nothing more , nothing less.  Ip prefix-list foo permit 10.2.34.0/17 <------ This will permit ONLY the specific network 10.2.34.0/17, nothing more, nothing less
There is also an option in prefix-lists to match subnet mask length using the keywords le / ge .  Do not let this confuse you, it is a totally separate thing than what we just discussed.  Here is an example:
Lets take the RFC1918 private address blocks for an example.  Here is a prefix-list that will deny all of them
ip prefix-list No-RFC1918 deny 10.0.0.0/8 le 32
ip prefix-list No-RFC1918 deny 172.16.0.0/12 le 32
ip prefix-list No-RFC1918 deny 192.168.0.0/16 le 32
Now, the explanation.  In a prefix-list the / specifies how many bits you "care" about, and the le or ge option specifies the bits in your mask.  So for instance with 10.0.0.0/8 le 32 we are saying the first 8 bits of the prefix MUST be equal to the first 8 bits of 10.0.0.0 AND the mask of those routes must be less than or equal to 32.  With 192.168.0.0/16 we are saying the first 16 bits MUST be equal to 192.168 AND the mask of those routes must be less than or equal to 32. So again anything starting with 192.168 will match.
Here is something a little trickier:
Ip prefix-list pants permit 192.168.0.0/16 le 24   <--------  So this says the first 16 bits MUST be 192.168 , AND the mask must be LE 24.  So what routes match this?
192.168.0.0/24
192.168.0.0/23
192.168.0.0/22
192.168.0.0/21
192.168.0.0/20
...
192.168.1.0/24
192.168.1.0/23
192.168.1.0/22
192.168.1.0/21
192.168.1.0/20
...
192.168.2.0/24
192.168.2.0/23
192.168.2.0/22
192.168.2.0/21
192.168.2.0/20
...
And so on and so forth... So 192.168.x.x with any mask 24 and less!
ip prefix-list provides the most powerful prefix based filtering mechanism
Here is a quick little tutorial on Prefix-lists for you.
A normal access-list CANNOT check the subnet mask of a network. It can only check bits to make sure they match, nothing more. A prefix-list has an advantage over an access-list in that it CAN check BOTH bits and subnet mask - both would have to match for the network to be either permitted or denied.
For checking bits a prefix list ALWAYS goes from left to right and CANNOT skip any bits. A basic example would be this:
172.16.8.0/24
If there is only a / after the network (no le or ge) then the number after the / is BOTH bits checked and subnet mask. So in this case it will check the 24 bits from left to right (won't care about the last 8
bits) AND it will make sure that it has a 24 bit mask. BOTH the 24 bits checked and the 24 bit subnet mask must match for the network to be permitted or denied.
No we can do a range of subnet masks also that could be permitted or
denyed:
172.16.8.0/24 ge 25
If we use either the le or ge (or both le and ge) after the /, then the number directly after the / becomes ONLY bits checked and the number after the ge or le (or both) is the subnet mask. So in this case we are still going to check the first 24 bits of the network from left to right. If those match we are then going to check the subnet mask, which in this case can be GREATER THAN OR EQUAL TO 25 bits - meaning that as long as the first 24 bits of the network match the subnet mask could be 25,26,27,28,29,30,31,or 32 bits. They would all match.
We can also do:
172.16.8.0/24 le 28
Again this will check the first 24 bits of the network to make sure that they match. Then it will check to make sure that the subnet mask is LESS THAN OR EQUAL TO 28 bits. Now this isn't going to be 28 bits down to 0 bits, the subnet mask can't be any lower than the bits we are checking. So the valid range of subnet masks for this one would be 28 bits down to 24 bits (24,25,26,27,and 28). All of those would match.
We can also do both ge and le:
172.16.8.0/24 ge 25 le 27
Here again we are checking the first 24 bits to make sure they match.
Then our subnet mask must be GREATER THAN OR EQUAL TO 25 bits LESS THAN OR EQUAL TO 27 bits. Meaning that 25,26,and 27 bit subnet masks would match.
Now for a couple of examples:
If we have the following networks:
172.16.8.0/28
172.16.8.16/28
172.16.8.32/28
172.16.8.48/28
172.16.8.64/28
We could permit all of these networks with on prefix-list statement:
172.16.8.0/24 ge 28 le 28
This will check the first 24 bits to make sure they match. All of these networks have 172.16.8 as the first 24 bits, and it won't care what is in the last 8 bits. Then it will check to make sure that the subnet mask is GREATER THAN OR EQUAL TO 28 bits LESS THAN OR EQUAL TO 28 bits - the only number that works for this is 28 bits. So the first 24 bits in the network must match and it has to have a 28 bit subnet mask. All 5 of our networks would match for this.
We could be even more precise with this and use:
172.16.8.0/25 ge 28 le 28
If we take a look at our 4th octects we will see that for all of them the 128 bit is off so we can check that bit also (25 bits total we are checking).
0 -- 0 0 0 0 0 0 0 0
16 - 0 0 0 1 0 0 0 0
32 - 0 0 1 0 0 0 0 0
48 - 0 0 1 1 0 0 0 0
64 - 0 1 0 0 0 0 0 0
This would be closer to permitting the 5 networks that we have.
We could also permit only the classful networks. The first thing that we need to do is figure out exactly what a classful network is.
For a class A network we know that it has to have an 8 bit mask and must be between 0 and 127 in the first octect. If we break down 0 and 127 we
get:
0 --- 0 0 0 0 0 0 0 0
127 - 0 1 1 1 1 1 1 1
For the first octect of a class A network the first bit has to be a 0, it must be off. So we can do a prefix-list like this:
0.0.0.0/1 ge 8 le 8
In our first octet the first bit is a 0 (which is what it would need to be to be class A), with the /1 we have we are ONLY checking the first bit to make sure it's a 0 (meaning it would be a class A network 0 - 127). We are then making sure that this class A network actually has a class A subnet mask of 8 bits, and only 8 bits would match.
For the class B's we need to make sure that they have a 16 bit subnet mask and that they are in the range of 128 - 191 in the first octet. If we break down 128 and 191 we get:
128 - 1 0 0 0 0 0 0 0
191 - 1 0 1 1 1 1 1 1
The first two bits are what we are going to care about. We need to make sure that the first two bits in the first octet are 1 0 . The first number that we can use as our standard we are checking against is 128 -
128 has a 1 0 as the first two bits in its first octet.
128.0.0.0/2 ge 16 le 16
So we are checking the first two bits to make sure the network has a 1 0, meaning that it must be in the range of 128 - 191. We are then going to check to make sure that it has the classful 16 bit mask, and ONLY a
16 bit mask.
Finally we have the class C networks. Class C networks are in the range of 192 - 223 and they must have a 24 bit mask. If we break down 192 and
223 we get:
192 - 1 1 0 0 0 0 0 0
223 - 1 1 0 1 1 1 1 1
The first 3 bits in the first octet are what we care about. 192 would be the first number we can put in that first octect that will have 1 1 0 as its first 3 bits.
192.0.0.0/3 ge 24 le 24
We are going to check the first 3 bits of the octet and make sure that its 1 1 0 meaning that it has to be in the range of 192 - 223 being class C, then we are going to check to make sure it has a class C classful subnet of 24 bits.
Finally how to permit or deny any could be very helpful since a Prefix-list just like an Access-list has an implicit deny at the end:
0.0.0.0/0 le 32
This is 'any' for a prefix-list. It says check 0 bits; I don't care what any of the bits are. It also says that the subnet mask can be 32 bits or less (down to the number of bits we are checking) down to 0. So we aren't going to check any bits and the network can have a subnet mask of anything between 0 and 32 bits. This would be 'any'.
Now for your Prefix-list:
In the 3rd Octet we have 1, 4, and 5. We'll break these down to binary to see if we can summarize these into one line:
1 - 0 0 0 0 0 0 0 1
4 - 0 0 0 0 0 1 0 0
5 - 0 0 0 0 0 1 0 1
For a Prefix-list we need to go from the left to the right and we can't skip bits. So for these three networks we would need to stop at the 8 bit since it is the last bit from left to right that is the same. This would give us 3 bits that are different, or 8 possible networks. We only have 3 of the 8 possible networks and we should not permit or deny more than we actually have. We should be as specific as possible.
If we leave the 91.86.1.0/24 alone by itself it will give us a Prefix-list of:
91.86.1.0/24
This will check the first 24 bits from left to right to make sure that they match, and it will also check to make sure that it has a 24-bit subnet mask.
For the 4 and 5 networks we can permit or deny both of those with one line. If we take a look at 4 and 5 again we can see that all of the bit's match down to the 2 bit. This would leave 1 bit that doesn't match, which would give us 2 possible networks, both of which we have.
The Prefix-list to permit or deny both 4 and 5 would be:
91.86.4.0/23 ge 24 le 24
This will check the first 23 bits from left to right. The 24th bit could either be off, which would give us 4, or it could be on which would give us 5. Since we have the ge and le involved the /23 is only bits checked. The ge and le specify that our subnet mask must be greater than or equal to 24-bits and less than or equal to 24-bits which means that the subnet mask must be 24-bits for both possible networks.
Quite a good explanation of how prefix lists work, but I have to disagree with the statement that ACLs can not be used to filter the mask component of prefixes. Extended ACLs can be used to serve the same purpose as prefix lists - in the context of prefix filtering the first two 32 bit sections are used to filter the network portion of the prefix, the last two 32 bit sections are used to filter the subnet mask portion of the prefix. The concept and syntax is not easy to use, which is why the prefix list syntax was implemented, but BGP filtering policies were expressed by extended ACLs before IP prefix lists were available.
Question:
I have recently read one very good posting on prefix-list in the groupstudy and thought I now understand it very well but look like I still have some confusions. Can someone help me out here.
For the prefix list "ip prefix-list permit 10.10.0.0/16 ge 30 le 30" I think it will match the first 16 bits and will use a mask of 255.255.255.252. If this is correct, will this permit 10.10.0.0 and 10.10.0.4 or only 10.10.0.4as the mask seems to limit to match the 30th bit.
Answer:
My test results show that a prefix list of "ip prefix-list permit 10.10.0.0/16 ge 30 le 30" will match ONLY on /30 subnets where the first 16 bits are 10.10
/16 means match the first 16 bits left to right without skipping must match. ge 30 le 30 means that the subnet must be equal to /30 or 255.255.255.252.
R1#sh run | b router bgp
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 131.108.50.2 remote-as 2
 neighbor 131.108.50.2 prefix-list Filter in
 no auto-summary
!
ip classless
no ip http server
!
!
!
ip prefix-list Filter seq 5 permit 10.10.0.0/16 ge 30 le 30
 
R2#sh run | B router bgp
router bgp 2
 no synchronization
 bgp log-neighbor-changes
 network 10.10.0.0 mask 255.255.255.252
 network 10.10.0.4 mask 255.255.255.252
 network 10.10.13.0 mask 255.255.255.252 -----> also makes it through filter
on R1
 network 12.12.0.0 mask 255.255.255.252   -----> /24 does not make it
through filter on R1
 neighbor 131.108.50.1 remote-as 1
 no auto-summary
R1#sh ip bgp            
BGP table version is 10, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
 
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.10.0.0/30     131.108.50.2             0             0 2 i
*> 10.10.0.4/30     131.108.50.2             0             0 2 i
*> 10.10.13.0/30    131.108.50.2             0             0 2 i
Question:
Can I use access-list to produce the same effect as prefix-list ? Any thoughts on which is a better way to use in redistribution over other. I am just trying to find which one I should stick with.
 ip prefix-list test seq 5 deny 199.172.4.0/24
 ip prefix-list test seq 10 deny 199.172.6.0/24
 ip prefix-list test seq 15 deny 199.172.8.0/24
 ip prefix-list test 20 permit 0.0.0.0/0 le 32
Answer:
Prefix lists can permit annoucements in a range of netmasks. For example, the following prefix-list entry will permit announcements of 192.168.1.0/24, or any prefix within that.
ip prefix-list example seq 5 permit 192.168.1.0/24 le 32
I don't believe there's a way to do that using access-lists.
The other major advantage is you can pull entries out of a sequence, and insert them without re-writing the entire prefix-list again. For example,'no ip prefix-list example seq 10' will remove only sequence 10, rather
than the entire prefix list.
These two features however need to ba taken with a grain of salt. Firstly you may want explicit routing control rather than a blanket cover, and secondly configurations like this are usually built out of databases so
you're not going to be manually inserting entries.
=================
The way prefix lists work are you can specify a network and mask or a network and a range of masks. Specifying a network and mask is fairly simple:
ip prefix-list mylist seq 10 permit 172.16.25.0/24
This will allow (match) the exact network 172.16.25.0/24 to pass the list. However prefix lists can also specify a network with a range of masks. For example:
ip prefix-list mylist seq 10 permit 172.16.0.0/16 ge 24 le 26
This will take the entire class B network 172.16.0.0 (172.16.0.0/16) and pass only subnets with a /24, /25 or /26 mask (ge 24 le 26). So the exact network 172.16.0.0/16 would actually fail the list because it does not have
a mask of /24, /25 or /26.
By default if you only specify "ge" then any subnet with a mask greater than or equal to the ge value will pass. That is, ge all the way up to /32. For example:
ip prefix-list mylist seq 10 permit 10.10.10.0/24 ge 28
This list specifies any subnet within the 10.10.10.0/24 range that has a mask of /28 or greater (255.255.255.240 to 255.255.255.255). Again, the exact subnet 10.10.10.0/24 would fail because it does not have a mask of /28
or greater.
By default if you only specify "le" then any subnet with a mask less than or equal to the le value but greater than or equal to the mask specified will pass. That is, le all the way down to the mask listed. For example:
ip prefix-list mylist seq 10 permit 10.64.0.0/16 le 23
This list specifies any subnet within the 10.64.0.0/16  range that has a mask between /16 and /23, inclusive (255.255.0.0 to 255.255.254.0). In this case the exact subnet 10.64.0.0/16 would pass because it has a mask in the
range /16 to /23.
The "permit any any" in a prefix list is:
ip prefix-list mylist seq 200 permit 0.0.0.0/0 le 32
================
Question:
I was watching this thread very good one with good examples. I have a small question. Assume now you have 5 routes(192.54.1.0/24, 192.54.2.0/24, 192.54.3.0/24, 192.54.4.0/24 and 192.54.5.0/24), now if the question asks to
use minimum number fo commands to allow these 5 prefixes what will be the solution be:
====================================
ip prefix-list cisco permit 192.54.0.0/22 ge 24 le 24==>A[will this line cover 0,1,2, and 3]
ip prefix-list cisco permit 192.54.4.0/23 ge 24 le 24
=====================================
or
=====================================
ip prefix-list cisco permit 192.54.1.0/24 ==========>B
ip prefix-list cisco permit 192.54.2.0/23 ge 24 le 24--covers 2 and 3
ip prefix-list cisco permit 192.54.4.0/23 ge 24 le 24--covers 4 and 5
====================================
Answer:
The solution I used Mani was 192.54.0.0/21 le 24 ge 24 Which excluded 192.54.21.0/24 and 192.54.22.0/24 and fulfilled the
requirements of the question. The Deny would have worked, but I think it is always better to permit exact
networks rather than deny and then let in everything else.  
192.54.16.0/21 le 24 ge 24 is the correct statement.
I am not well aquainted with the IP prefix command.  It s pretty straight-forward and I understand the basics, but the operators (ge(greater than) and le(less than)) always throw me off.  Not any longer, thanks to this post:
It s all about the number of bits! 
If you want /20 to /32, that would be a number greater than or equal to 20 (ge 20)
If you want /0 to /20, that would be a number less than or equal to 20 (le 20)
If you want /20 to /24, that would be a number greater than or equal to 20 AND less than or equal to 24 (ge 20 le 24)
If you want ONLY /24 s, that would be a number both greater than or equal to 24 AND less than or equal to 24, which essentially cancels out the greater than/less than part and leaves you equal to 24 (ge 24 le 24).
I d been meaning to play with prefix-lists to find the best way to replicate a  permit any  ACE. That appears to be  ip prefix-list name seq 10 permit 0.0.0.0/0 le 32 , and that makes sense. I had been using  ip prefix-list name seq 10 permit 0.0.0.0/0 ge 13  which I knew wasn t right, but for whatever reason I hadn t yet taken the cycles needed to figure it out. 
Prefix lists are, for me, the big-boy way to make lists of routes. While they don t give you the granular ability of an ACL when it comes to layer 4 matching (port numbers), prefix lists are easier to read and offer greater flexibility than access-lists if all you re trying to do is generate a list of routes to match or deny. I don t know about you, but no matter how many wildcard masks I ve looked at in my life, it still takes a few seconds to figure out what nets that wildcard entry is referring to. Prefix-lists, for the way my brain is wired, immediately register with the ol  gray matter.
There are 2 elements that make up a prefix list:
The route prefix itself - in other words, the subnet.  Prefix  in the sense that it s the first part of the network address. 
The prefix length - in other words, the subnet mask.  Length  in the sense that you know how much of that network address belongs to the prefix. 
So let s take an example prefix list and pick it apart. Consider this:
ip prefix-list myPrefixList seq 10 permit 192.168.100.0/24
ip prefix-list myPrefixList seq 20 permit 172.16.0.0/16 le 24
ip prefix-list myPrefixList seq 30 permit 10.0.0.0/8 ge 16 le 24
Here we ve created a prefix-list called  myPrefixList . It is sequenced by 10 s. We could insert a new sequence number of 15 later, or delete entry 20, just like in an access list. (Although, I don t know of a way that you can resequence a prefix-list, which is UNLIKE an access list.) In this list, the following networks would match the prefix list:
An exact match of 192.168.100.0/24 
Any networks falling in the range of 172.16.0.0/16 that have a /24 or shorter mask. Ergo, 172.16.2.0/23 would match. 172.16.128.0/17 would match. 172.16.99.128/25 would NOT match. 
Any network falling in the range of 10.0.0.0/8 with a mask length between and included 16 and 24 would match. But /9 s would not match; /27 s would not match either. 
Blogs and organic groups at http://www.ccie.net
Received on Tue May 19 2009 - 00:05:13 ART

This archive was generated by hypermail 2.2.0 : Mon Jun 01 2009 - 07:04:43 ART