Prefix-list length value when specifying as source in RIP distribute-list

Hi,

Hope you can help, I am studying INE's RIP Adv. Technology videos at the moment. I am on the last RIP video regarding filters. My understanding of prefix-list "ge" & "le" values are they are referencing the subnet/length field of the RIP advertisement. See example:

R5(config-router)# distribute-list prefix ALL gateway NO_R3 in tunnel0

 

R5(config)# ip prefix-list NO_R3 deny 155.1.0.3/32

R5(config)# ip prefix-list NO_R3 permit 0.0.0.0/0 le 32 -> "le 32" why do we need this & what does it reference?

 

R5(config)# ip prefix-list ALL permit 0.0.0.0/32 le 32 -> "le 32" references the subnet/length field of RIP advertisement

If am configuring this example as per INE video, I am using two prefix-lists one for RIP routes we want to receive & another to specify the source of RIP advertisements. Obviously the second prefix-list to specify the source of advertisements will reference the source address field of the IP header, there is no subnet mask field in an IP header so why do we need to use "le" at the end of the syntax?

Any help is much appreciated.

Ken

 

Comments

  • R5(config)# ip prefix-list NO_R3 deny 155.1.0.3/32

    R5(config)# ip prefix-list NO_R3 permit 0.0.0.0/0 le 32 -> "le 32" why do we need this & what does it reference?

     

    Hi Ken,

    the gateway prefix-list is supposed to include all possible sources for that particular prefix except R3.

    So in practice it works like this:

    you exclude R3 with the first line (deny 155.1.0.3/32); with this line you are telling to the router to don't consider that particular host as a gateway.

    The second line permit anything else, where /0 match 0 bit in the block and le 32 tells you that the subnet mask length may vary from a maximum of 32 to whatever lower value than that one.

    So in practice you are saying admit any possible gateway except R3 address.

  • Hi,

    Thanks for your reply, but I do understand the syntax except "le 32" as mentioned below.

     

    R5(config)# ip prefix-list ALL permit 0.0.0.0/32 le 32

    Here 0.0.0.0/0 references the incoming RIP advertisement address field. "le 32" references the incoming RIP advertisements "subnet" field.

     

    R5(config)# ip prefix-list NO_R3 permit 0.0.0.0/0 le 32

    Here "0.0.0.0/0" references the L3 header source address field, there is no subnet field in an IP header, so what is the reason for "le 32"? what does it reference?

    Hope you can clarify :-)

     

  • Hi,

     

    i understand your observation and i believe you did a very good remark but i do see it in the following way:

    Prefix-list 0.0.0.0/0 without le 32 match 0 bit of a route of a length of 0 so since there's no length it means that match the exact route 0.0.0.0 which is a default route.

    So if i may ask you, how you would specify into this context that you do not want to match just that specific route (the default in our example) but you want include any other source address for gateway options in distribute-list? i don't think is possible to do without ge or le.

    Since the prefix-length is comprised between the 0 and 32 with the use of le 32, you are practically saying to the router do not check the subnet mask because any address of whatever length will match with the prefix length.

     

     

     

     

     

  • ciocangciocang

    Hi,

    Thanks for your reply, but I do understand the syntax except "le 32" as mentioned below.

     

    R5(config)# ip prefix-list ALL permit 0.0.0.0/32 le 32

    Here 0.0.0.0/0 references the incoming RIP advertisement address field. "le 32" references the incoming RIP advertisements "subnet" field.

     

    R5(config)# ip prefix-list NO_R3 permit 0.0.0.0/0 le 32

    Here "0.0.0.0/0" references the L3 header source address field, there is no subnet field in an IP header, so what is the reason for "le 32"? what does it reference?

    Hope you can clarify :-)

     

     

    Hi,

     

    These prefix lists are used to filter the routes which RIP will install in the routing table - filter the content of RIP update messages if you want - and not to filter the IP packet coming from another RIP router. They are not use to analyse the IPv4 header of incoming packet.

    In your example here, the ALL prefix list will be used to match any host routes, altough the "le 32" here is not required. while the NO_R3 prefix list is an equivalent of any in an ACL. But as I said, they will not match the source IP field in the IPv4 packet coming in on an interface but the content of the RIP update message contained in that packet.

     

    Gabriel

  • Thanks for your comment Gabriel, but I disagree with you. Prefix-list can be used to filter source of RIP advertisement (prefix-list references L3 IP header source address). Also a prefix-list can be used to filter RIP routes within the RIP advertisement.

    The reason a distribute-list can call two prefix-list with one distribute-list command, is so it can filter both source of advertisement (prefix-list 1), & advertised routes within the RIP advertisement (prefix-list 2)

    But my original question:

    R5(config)# ip prefix-list ALL permit 0.0.0.0/32 le 32

    Here 0.0.0.0/0 references the incoming RIP advertisement address field. "le 32" references the incoming RIP advertisements "subnet" field.

     

    R5(config)# ip prefix-list NO_R3 permit 0.0.0.0/0 le 32

    Here "0.0.0.0/0" references the L3 header source address field, there is no subnet field in an IP header, so what is the reason for "le 32"? what does it reference?

  • Hi Pgallo,

    Thanks for your reply. I agree with you to a point, except:

    R5(config)# ip prefix-list NO_R3 deny 155.1.0.3/32

    Here we are specifying an exact match for this source, however we could also specify for example:

    R5(config)# ip prefix-list NO_R3 deny 155.1.0.3/24

    Here we are specifying any source that must match the first 3 octets. We don't need to specify the length of the address, IOS assumes all IPv4 addresses are 32bits in length

     

    R5(config)# ip prefix-list NO_R3 permit 0.0.0.0/0 le 32

    Your previous comment "Since the prefix-length is comprised between the 0 and 32 with the use of le 32, you are practically saying to the router do not check the subnet mask because any address of whatever length will match with the prefix length." RIP routers source address is in the L3 IP header, but they do not advertise their subnet mask, so why use the "le 32"?

    I'm in the middle off CCIE at the moment, so I still have much to learn, but so far when I see "le or ge" it references a subnet mask field. The exception is as mentioned above. I guess with this chat, I won't forget to use "le 32" on exam day [:)]

    Thanks again for your comments, Ken

     

     

  • ciocangciocang

    R5(config)# ip prefix-list NO_R3 permit 0.0.0.0/0 le 32

    Here "0.0.0.0/0" references the L3 header source address field, there is no subnet field in an IP header, so what is the reason for "le 32"? what does it reference?

    So you asking about the case when using a distribute list with the gteway option? Then in this case, the prefix list can be used to identify one or many gateways (routers). It defines a range where the source IP can fit.

    For example, a bunch of routers on a multi access network are running RIP and all having the IP address ont the RIP enabled interface with a mask of /24. Then if a say router is willing to filter updates coming from the first half of the network then it can use a prefix list like ip prefix-list NO_UPDATE permit X.X.X.128/25 le 32. Now, as for the logic, any advertising router will be identified as a host so you have to have a 32 bit mask specified otherwise will not match any advertising router. So in another words, you need to match all hosts (le 32) in a  certain subnet (maximum X.X.X.128/25).

     

    I don't know if I could explained it that well so if it's still unclear, I can post a sample config of 3 routers to clear this out.

     

    Gabriel

  • Hi Gabriel,

    Thanks for your reply, I tried out your example on my lab today. My understanding now is that when using a distribute-list with the gateway option, the router is referencing the L3 IP header source address field, obviously there is no subnet field in an IP header. For example:

     

    ip prefix-list source permit 10.1.1.5/24 le 32

    /24 indicates the length of the address that must match, in this case the first 24 bits of the source address.

    le 32 indicates this is any host

     

    After quite a bit of labbing today, I believe when using the gateway option I must always use "le 32", if I use any other value there will be no match for that prefix-list. It seems strange to me that we need to specify "le 32" when obviously a source address in an IP header is a host address. Having said all that, Gabriel do you think I have the logic ok as described in the above syntax?

    Many thanks again Gabriel for your help, Ken

     

     

  • JoeMJoeM ✭✭✭ ✭✭✭

    R5(config)# ip prefix-list NO_R3 deny 155.1.0.3/32


    Here we are specifying an exact match for this source, however we could also specify for example:


    R5(config)# ip prefix-list NO_R3 deny 155.1.0.3/24


    Here we are specifying any source that must match the first 3 octets. We don't need to specify the length of the address, IOS assumes all IPv4 addresses are 32bits in length

    Not exactly.
    I was curious about how the IOS would treat the 2nd example, because it does not make sense. There is no such network as a x.x.x.3/24

    So I tested the IOS logic, and and this was the result:

    R1(config)#    ip prefix TEST permit 150.1.0.2/24
    R1(config)#do sh run | s prefix
    ip prefix-list TEST seq 5 permit 150.1.0.0/24
    <--IOS intreprets

    This would not match any device. It would only match an exact network 150.1.0.x/24 (nothing more). Great for filtering a network update, but useless for identifying any individual devices (or group of devices).

     

    I think this confusion about prefixes is normal at first, because we are accustom to using ACL's.  If we were to use an ACL, the logic would identify everything below /24 (everything),because the ACL behaves more like a catch-all basket (no need to specify the exact range /32  or  le 32).

    This understanding of prefix-list will become very valuable later on, because it allows us to be much more specific about what we filter/allow. ACL's do not do this.

  • ciocangciocang

    ip prefix-list source permit 10.1.1.5/24 le 32

    /24 indicates the length of the address that must match, in this case the first 24 bits of the source address.

    le 32 indicates this is any host

    Hi Ken,

    It is true that is a bit confusing and to get it better I would suggest to stop thinking at the IP packet itself. That is used just to transport data from one place to another. The gateway here is not necessarily the originator of the UDP packet (although in most normal cases is). The gateway here, is the value of Next Hop field in the RIP update message. Usually that is 0.0.0.0 and that means that the Next Hop is the originator of the update message. So when you want to filter based on gateway using a prefix list, you write one like this:

    ip preifix-list FILTER seq 5 permit 192.168.1.1/32

    ip preifix-list FILTER seq 10 permit 192.168.1.64/32

    ip preifix-list FILTER seq 15 permit 192.168.1.100/32

    ip preifix-list FILTER seq 20 permit 192.168.1.126/32

    And that will match the 4 routers in the subnet. If these are the only routers in that subnet, or you want any new RIP speaker in a /25 space to be filtered, for example, then you can "summarize" and it will give you a prefix list:

    ip preifix-list FILTER seq 5 permit 192.168.1.0/25 le 32

    You always need to match hosts in a certain subnet to be able to identify a gateway (Next Hop)

    Same logic applies to EIGRP as well this is not RIP specific at the end of the day.

     

    Gabriel

  • JoeMJoeM ✭✭✭ ✭✭✭

    PREFIX-LIST fun and practice. Conquer prefix-lists and the options for filtering will become much more precise.

    ip prefix- TEST permit 150.1.0.0/24 le 32 
         matches  150.1.0.0 - 150.1.0.255 <-- result

    ip prefix- TEST permit 150.1.0.0/24 ge 30 le 32 <-IOS removes le 32 not needed
         matches 150.1.0.0 - 150.1.0.3   (think /30)


    ip prefix- TEST permit 150.1.0.0/24 le 28
      RESULT?  what addresses would be included?

    ip prefix- TEST permit 150.1.0.0/24 ge 28 le 30
      RESULT?

    ip prefix- TEST permit 150.1.0.0/24 le 25
      RESULT?

    Have fun with it. Try to make this automatic. Prefix-lists make ACL's look too permissive (be careful with ACLs).

    Go back to what señor pgallo was saying about bits.  ;-)

  • Hi Gabriel,

    Thanks, it makes a lot more sense to me when you suggested "I would suggest to stop thinking at the IP packet itself. That is used just to transport data from one place to another". As you mentioned the "next-hop" (gateway) field is referenced by the gateway option & "le 32" indicates a host.

    Thanks for your help, Ken

  • JoeMJoeM ✭✭✭ ✭✭✭

    Remember this conversation when you get to the BGP section. [6]

  • ciocangciocang

    Thanks for your help, Ken


    You are welcome Ken.

    Remember this conversation when you get to the BGP section. Devil

     

     

    I have to agree with JoeM here. The advisable thing to do on your way there is to try to understand as well as possible how matching works for access lists, prefix lists and most importan route maps.

     

    Gabriel

  • Thanks Gabriel,

    I appreciate both you & JoeM advice, the next week will be spent on acl's prefix-list etc, until I'm completely comfortable with it.

    Many thanks JoeM for your examples, Ken.

  • JoeMJoeM ✭✭✭ ✭✭✭

    No problem. I just created those on the fly. Create your own too.  If you get this down, then all of the different uses will be easy.  

    The reason that I am being a stickler on this, is because of one of your comments that I highlighted (about the thinking that two prefix-lists being the same).

    Ciocang is correct about adding route-maps into the mix.  It sometimes becomes a reverse logic type thing when building a route-map.      PERMIT prefix-list but DENY route-map   or DENY prefix|acl etc etc.

    Also there is the thing about efficiency.  How many prefix lines do we need to do a job?   That is where the benefit comes with using the BIT length of a prefix-list (that pgallo explained) or just throwing a blanket subnet of an ACL at the problem.

    Good luck. In a short while, it will all make sense.  ;-)

Sign In or Register to comment.