We are going to talk about how you can accept or reject prefixes into your BGP table. Cisco's tool for doing this is called a prefix list. And the way it works is you have incremental configuration, which means each line of the prefix list is evaluated one by one, and then the next line is evaluated against the prefix it's trying to match, until it reaches the bottom. You can apply it on the inbound or outbound direction, which means towards prefixes announced towards you, or prefixes that you are trying to announce. It's based on network numbers using the familiar IP address and netmask format (or CIDR). The prefix list in Cisco ends with an implicit default deny. A long time ago, Cisco IOS had access lists for filtering prefixes and they've deprecated it since then. We strongly discourage you from using access lists for two reasons. Firstly, they're inefficient in the way that the IOS does the matching, and secondly, they use wildcard masks which makes it very easy to make mistakes. So this slide shows you the syntax of a prefix list. You will notice that the syntax is the same for IPv4 or IPv6 the only difference being the first keyword is either "ip" or "ipv6". To create a prefix list line, you say: "ip prefix-list", and then you give it a name. You have an optional sequence and then either you're going to permit or deny this particular network. You specify the network and the subnet mask length. And then you have two optional modifiers there's "ge" and "le". "ge" specifies you want to have a match of greater than or equal to the network and length that you specified earlier. "le" means you want to match prefixes which are less than or equal to the network that you previously specified. And we shall see examples of this to make it slightly clearer. The sequence number is also optional and if you do not want Cisco IOS to display the sequence numbers inside the running configuration, you can say: "no ip prefix-list sequence-number" for IPv4 or "no ipv6 prefix-list sequence-number" to turn off that display. Juniper has something similar. In Juniper you have prefix lists which do something else, but the equivalent tool for doing prefix list filtering is called a route-list. This slide shows you the syntax of how you would construct a route-list. You'd say: "route-filter" and then the prefix that you want to match, and then a match-type, which we shall look at on the next slide, and then an optional action. So a prefix, like we've said, is a network and its length that you're trying to match. Match-type is a group of optional keywords and then we shall see how the actions work. This slide shows you the different match-types and the conditions under which they will match. So "match-type exact" means the advertised prefix including the subnet mask must match this entry exactly. This is similar to typing the Cisco IP prefix list without any "le" or "ge" entries. "longer" means the advertised prefix is a subnet that is part of the network number but the prefix length is longer. So this is a subnet that could be part of this larger subnet. "orlonger" means you have a prefix that matches the entry including the length plus any longer prefixes. So the difference between "orlonger" and "longer" is, the second one "orlonger" includes the aggregate in the matches and "longer" only includes the sub prefixes. You can also say "prefix-length-range" and you give it "X" and "Y", and that means the advertised route has to be a subset of the network but the prefix length is going to be anywhere between "X" and "Y", inclusive. Or you can say "upto Y", which is very similar to the previous one, and in this case the advertised route matches that particular network that you specified, or it's a sub prefix, but the prefix length has to be the network that you specified earlier all the way up to the length of "Y" inclusive. There's also a "through" match-type which is not used a lot as noted on the slides, so we shall not spend a lot of time on this one. These are some examples of prefix lists, the first one is how you deny the default route in IPv4. So you have: "ip prefix-list EG deny". To deny the default route in IPv6, you just have "ipv6 prefix-lists", the name is "EG-v6" and then you "deny ::/0". The next one is how you permit and the last one is how you'd permit 2001:DB8::/32. For Juniper the equivalent for the previous prefix lists are shown on this slide. So to deny the default route in IPv4 you'd say "route-filter exact" and then you'd have an action of "reject". To deny the default route in v6 you'd also have "route-filter ::/0 exact { reject; }". To permit the "/8" prefix you'd also say "route-filter { accept; }". And you can also permit the "DB8::/32" as shown in the last example. So back to Cisco, if you want to deny a "/12" we've already seen this, it's "ip prefix-list EG deny". In the second example you also want to deny the "/16" in IPv6. But the third example shows a more typical use case, you do not want to deny just that particular subnet, but you want to match more than the subnet that you have specified. So in this case we have "ip prefix-list EG", we are permitting " le 24". Which means this is going to match anything out of that "/28" which has a subnet mask of a "/8" all the way to a "/24". Addresses with a "/25, /26, /27" all the way to a "/32" will not be matched by this prefix list. In the condition that you don't have any other lines inside this prefix list, that means those longer prefixes will be denied. Same thing for IPv6 you have "2000::/3" and you want to permit everything up to a "/48" and this is how you'd specify it with a "le", less than or equal to. The Juniper equivalent is shown on this slide the "exact" ones we've already seen before, but to permit "192/8" any prefix that is up to a "/24" you say "route-filter", the match is "upto 24" and then the action is "accept". And same thing for IPv6, "route-filter 2000::/3 upto 48 { accept; }". Now we look at that "ge" modifier. If you want to deny, explicitly, a "/25" and above you'd say "ip prefix-list EG deny ge 25". So you're explicitly saying that anything that is a "/25" all the way up to a "/32" out of the block will be denied. It has a very similar effect as the previous example where we used"le 24", except that in this case you are explicitly denying the longer prefixes. Out of "193/8" you can permit prefixes between "/12" and "/20" using this line, you have a combination of the "ge" and "le" match conditions. So you have "ge 12" which means greater than or equal to a "/12" , and "le 20" which means less than or equal to a "/20". So this will permit the "/12", "/13", "/14", "/15", all the way to "/20", but it does not match "/8", "/9", "/10", "/11", as well as anything greater than "/20" out of the "/8" block. Lastly, is a common example of how to permit all IPv4 prefixes. So you're permitting which is the shortest prefix possible, "le 32" which means anything as long as it matches any possible IPv4 address. Juniper has equivalents to these same examples, in this slide as shown below. For "192/8" if you want to deny a "/25" and above, you say, you match the "route-filter prefix-length-range 25 32" and then you have the action of "reject". For "193/8" if you want to permit prefixes between a "/12" and a "/20", You say "route-filter prefix-length-range 12 20". If you want to permit all prefixes you say "route-filter orlonger" and that will match all possible addresses. This is a full example of how you apply prefix lists to Cisco configuration. You have "router bgp" as shown previously, you have your neighbor with address, and in the inbound direction you have applied the prefix list "AS110-IN" and in the outbound direction you applied the red "AS110-OUT" prefix list. So for the inbound direction you're denying, and then you're permitting everything else with "permit le 32". This is very common to make sure you filter out your own aggregate towards yourself. For the outbound you're permitting, and then you're denying everything else which means you want to announce only this particular aggregate. Juniper route lists cannot be applied individually to the neighbor the way Cisco ones can, and they have to be part of a big policy which we shall look at at the very last end, when we are looking at the policy languages for both Cisco and Juniper. Different vendors will either copy the way Cisco does it or the way Juniper does it.

© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.

Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.