Re: IP Prefix-list

http://ccienotes.blogspot.com/2007/08/ip-prefix-list.html

On Mon, May 18, 2009 at 9:35 PM, Mohit Garg <mohit.v.garg_at_gmail.com> wrote:

> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Salah
CCIE# 24207
Blogs and organic groups at http://www.ccie.net