BGP Prefix lists are important for their high flexibility, support for incremental updates, and that writing BGP Prefix lists are much more efficient than writing ACL’s that filter BGP updates as BGP tables can have much more content (thousands of entries) in them as compared to IGP’s route tables.
They have some similarities to ACL’s that will make them a bit easier to digest if you have not worked with them or even heard of them before:
- Both require a route to explicitly permitted, or it is denied
- At the bottom of the prefix list is an Implicit deny
- Explicit deny statements don’t override the implicit deny
- Prefix lists work from top to bottom until a match is found, and the process stops, so it is important to keep the lines in correct order for the Prefix list to work properly
- Prefix list lines are numbered, default increment if a number value is not specified, is to increment by 5 (giving the admin wiggle room to insert lines later as needed)
With that, onto configuration, which I have already configured the above non-full mesh topology above, but I also added and advertised network 5.5.5.5/32 in addition to 100.1.0.0 – 100.7.0.0 /16 as can be seen here on R5:
R5#sh ip bgp
BGP table version is 6, local router ID is 172.16.11.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
*> 5.5.5.5/32 0.0.0.0 0 32768 i
*> 172.16.8.0/24 0.0.0.0 0 32768 i
*> 172.16.9.0/24 0.0.0.0 0 32768 i
*> 172.16.10.0/24 0.0.0.0 0 32768 i
*> 172.16.11.0/24 0.0.0.0 0 32768 i
R5#
Which as you may notice has all the hallmarks of being the originating router for these routes, like the 0.0.0.0 Next Hop and Local Pref of 32768, and that I am feeling lazy after Easter dinner so I am just recycling the routes to be summarized from a recent post.
So let’s take a look at our NBMA neighbors, and see how their BGP tables are looking:
R1#sh ip bgp
BGP table version is 6, 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
*> 5.5.5.5/32 172.12.15.5 0 0 5 i
*> 172.16.8.0/24 172.12.15.5 0 0 5 i
*> 172.16.9.0/24 172.12.15.5 0 0 5 i
*> 172.16.10.0/24 172.12.15.5 0 0 5 i
*> 172.16.11.0/24 172.12.15.5 0 0 5 i
R1#
So of course R1 being the directly connected Peer has Best Paths to it’s next hop of R5, lets look at the spokes:
R2#sh ip bgp
BGP table version is 1, local router ID is 2.2.2.2
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
* i5.5.5.5/32 172.12.15.5 0 100 0 5 i
* i172.16.8.0/24 172.12.15.5 0 100 0 5 i
* i172.16.9.0/24 172.12.15.5 0 100 0 5 i
* i172.16.10.0/24 172.12.15.5 0 100 0 5 i
* i172.16.11.0/24 172.12.15.5 0 100 0 5 i
Which I’ll skip R3’s output, because R1 is not configured with neighbor x.x.x.x next-hop-self or as a Route Reflector, so the rule that iBGP Peers not changing the interface address of the remote Peers interface is in effect.
Since we’ve beat Route Reflectors to death in the last post, lets go with next-hop-self:
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router bgp 123
R1(config-router)#neighbor 172.12.123.2 next-hop-self
R1(config-router)#neighbor 172.12.123.3 next-hop-self
R1(config-router)#
R1(config-router)#^Z
R1#
Issuing the next-hop-self does trigger a routing update with BGP, so there is no need to use the clear command here, but if you run into issues getting those routes to update that is the first command I would try to get things moving in the right direction.
So R2 and R3 are now on board:
R2#sh ip bgp
BGP table version is 6, local router ID is 2.2.2.2
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
*>i5.5.5.5/32 172.12.123.1 0 100 0 5 i
*>i172.16.8.0/24 172.12.123.1 0 100 0 5 i
*>i172.16.9.0/24 172.12.123.1 0 100 0 5 i
*>i172.16.10.0/24 172.12.123.1 0 100 0 5 i
*>i172.16.11.0/24 172.12.123.1 0 100 0 5 i
R2#
ASR#3
[Resuming connection 3 to r3 … ]
R3#sh ip bgp
BGP table version is 6, local router ID is 3.3.3.3
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
*>i5.5.5.5/32 172.12.123.1 0 100 0 5 i
*>i172.16.8.0/24 172.12.123.1 0 100 0 5 i
*>i172.16.9.0/24 172.12.123.1 0 100 0 5 i
*>i172.16.10.0/24 172.12.123.1 0 100 0 5 i
*>i172.16.11.0/24 172.12.123.1 0 100 0 5 i
R3#
Now that everything is looking good, it’s time to throw the wrench into the engine with a Prefix list that does not all R2 and R3 to see any of the 172.16.x.x /24 routes, while allowing them to still see the 5.5.5.5/32 route AND any future routes added to R5.
Deciding where to configure this Prefix list can be a little tricky, as it could be configured on R5, but that would (especially in an exam question) not meet the requirements listed as R1 would also be impacted – So it seems like R1 will probably be our candidate for Prefix list configuration!
R1(config)#ip prefix-list ?
WORD Name of a prefix list
sequence-number Include/exclude sequence numbers in NVGEN
R1(config)#ip prefix-list BlockNets ?
deny Specify packets to reject
description Prefix-list specific description
permit Specify packets to forward
seq sequence number of an entry
R1(config)#ip prefix-list BlockNets deny 172.16.8.0 /24
^
% Invalid input detected at ‘^’ marker.
R1(config)#ip prefix-list BlockNets deny 172.16.8.0/24
R1(config)#ip prefix-list BlockNets deny 172.16.9.0/24
R1(config)#ip prefix-list BlockNets deny 172.16.10.0/24
R1(config)#ip prefix-list BlockNets deny 172.16.11.0/24
R1(config)#^Z
R1#wr
Building configuration…
*Mar 31 12:59:48.465: %SYS-5-CONFIG_I: Configured from console by console[OK]
R1#
So a couple of things here to note, first that when making a prefix-list line in global configuration of the router, you use a CIDR mask instead of a dotted decimal mask and if you put a space between the network address and the CIDR mask it is NOT a valid command.
I tried to format the carrot to be in the right place, but it might end up somewhere screwy, just trust me that it appeared between the 0 and /24 here.
Another thing to note is that there is an implicit deny that needs to be taken care of, as right now the prefix list will block all traffic, which is why I put at the top bulletin points that because you explicitly deny traffic does not mean it won’t still hit the implicit deny, as there are no free passes in Prefix Lists as with ACL’s!
Now you can’t just put permit any with Prefix Lists, so you will need to commit the following command to memory (as CCNP candidates are good at doing):
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ip prefix-list BlockNets ?
deny Specify packets to reject
description Prefix-list specific description
permit Specify packets to forward
seq sequence number of an entry
R1(config)#ip prefix-list BlockNets perm ?
A.B.C.D IP prefix <network>/<length>, e.g., 35.0.0.0/8
R1(config)#ip prefix-list BlockNets perm 0.0.0.0/0 ?
ge Minimum prefix length to be matched
le Maximum prefix length to be matched
<cr>
R1(config)#ip prefix-list BlockNets perm 0.0.0.0/0 le ?
<1-32> Maximum prefix length
R1(config)#ip prefix-list BlockNets perm 0.0.0.0/0 le 32
R1(config)#
So I highlighted the modifiers I used, which is saying “permit any prefix matching anything to a maximum length of 32 bits”, which as we know 0.0.0.0 0.0.0.0 is a default all-traffic route (or if you didn’t know that I hope you understand that now) 🙂
So, that is the Prefix Lists equivalent to adding a permit ip any any at the end of an ACL to allow all other traffic to flow except the explicitly denied traffic. So if that were the first line in sequence, it would permit everything before those explicit denies caught the advertisements, because we are matching all 32 bits to 0.0.0.0 0.0.0.0.
Now that we have a Prefix List configured and ready to rock, time to configure this within BGP, and we are going to do that with of course the “neighbor …” command:
R1(config)#router bgp 123
R1(config-router)#neighbor 172.12.123.2 ?
activate Enable the Address Family for this Neighbor
advertise-map specify route-map for conditional advertisement
advertisement-interval Minimum interval between sending BGP routing updates
allowas-in Accept as-path with my AS present in it
capability Advertise capability to the peer
default-originate Originate default route to this neighbor
description Neighbor specific description
disable-connected-check One-hop away EBGP peer using loopback address
distribute-list Filter updates to/from this neighbor
dmzlink-bw Propagate the DMZ link bandwidth
ebgp-multihop Allow EBGP neighbors not on directly connected
networks
fall-over session fall on peer route lost
filter-list Establish BGP filters
inherit Inherit a template
local-as Specify a local-as number
maximum-prefix Maximum number of prefixes accepted from this peer
next-hop-self Disable the next hop calculation for this neighbor
next-hop-unchanged Propagate the iBGP paths’s next hop unchanged for
this neighbor
password Set a password
peer-group Member of the peer-group
prefix-list Filter updates to/from this neighbor
remote-as Specify a BGP neighbor
remove-private-as Remove private AS number from outbound updates
route-map Apply route map to neighbor
route-reflector-client Configure a neighbor as Route Reflector client
send-community Send Community attribute to this neighbor
shutdown Administratively shut down this neighbor
soft-reconfiguration Per neighbor soft reconfiguration
timers BGP per neighbor timers
translate-update Translate Update to MBGP format
transport Transport options
ttl-security BGP ttl security check
unsuppress-map Route-map to selectively unsuppress suppressed
routes
update-source Source of routing updates
version Set the BGP version to match a neighbor
weight Set default weight for routes from this neighbor
R1(config-router)#neighbor 172.12.123.2 prefix-list ?
WORD Name of a prefix list
R1(config-router)#neighbor 172.12.123.2 prefix-list BlockNets ?
in Filter incoming updates
out Filter outgoing updates
R1(config-router)#neighbor 172.12.123.2 prefix-list BlockNets out ?
<cr>
R1(config-router)#neighbor 172.12.123.2 prefix-list BlockNets out
R1(config-router)#neighbor 172.12.123.3 prefix-list BlockNets out
R1(config-router)#^Z
R1#clear i
*Mar 31 13:18:54.324: %SYS-5-CONFIG_I: Configured from console by console
R1#clear ip bgp * soft out
R1#wr
Building configuration…
At this point I’m not really sure what constitutes triggering a routing update, so I’ve just gotten used to issuing the clear ip bgp * soft in/out command after making changes.
Notice that we could have also gone to R2 and R3 and done this same thing, as the neighbor command does have a “Filter incoming updates” option, however configuring just on R1 is obviously a more effective way of applying the Prefix List.
So lets check out R2 and R3 to see if this was done correctly:
R2#sh ip bgp
BGP table version is 10, local router ID is 2.2.2.2
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
*>i5.5.5.5/32 172.12.123.1 0 100 0 5 i
R2#
ASR#3
[Resuming connection 3 to r3 … ]
R3#sh ip bgp
BGP table version is 10, local router ID is 3.3.3.3
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
*>i5.5.5.5/32 172.12.123.1 0 100 0 5 i
R3#
And to verify Prefix Lists, here is a show command from R1 to show all Prefix Lists configured on the router:
R1#sh ip prefix-list
ip prefix-list BlockNets: 5 entries
seq 5 deny 172.16.8.0/24
seq 10 deny 172.16.9.0/24
seq 15 deny 172.16.10.0/24
seq 20 deny 172.16.11.0/24
seq 25 permit 0.0.0.0/0 le 32
R1#sh ip prefix-list ?
WORD Name of a prefix list
detail Detail of prefix lists
summary Summary of prefix lists
| Output modifiers
<cr>
So there is our prefix list just from “sh ip prefix-list” however I wanted to include the modifiers, as if your working with 50 prefix lists you can call it out by name or use a pipe (|) to narrow down your search a bit, and notice the default sequential order of 5, 10, 15, etc.
So to throw another wrench into the mix, I will add 55.5.5.5 on R5 to see if that makes it around the network, and if I need to adjust the prefix list at all to allow or to block it:
R5(config-if)#ip add 55.5.5.5 255.255.255.255
R5(config-if)#router bgp 5
R5(config-router)#network 55.5.5.5 mask 255.255.255.255
R5(config-router)#^Z
R5#wr
Building configuration…
[OK]
R5#
ASR#2
[Resuming connection 2 to r2 … ]
R2#sh ip bgp
BGP table version is 11, local router ID is 2.2.2.2
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
*>i5.5.5.5/32 172.12.123.1 0 100 0 5 i
*>i55.5.5.5/32 172.12.123.1 0 100 0 5 i
R2#
Sure enough it is working exactly as designed and allowing any traffic not explicitly denied by the Prefix List through to the spoke, but what if we want to add a sequence number in there to block the 55.5.5.5 network for both routers?
Firstly, by default with Prefix Lists it will automatically put new statements at the bottom of the list, so the deny would be below the allow all traffic statement which in turn would make it useless, so we need to put it somewhere in the sequence bleow the number 25 (higher in the Prefix list):
R1(config)#ip prefix-list BlockNets ?
deny Specify packets to reject
description Prefix-list specific description
permit Specify packets to forward
seq sequence number of an entry
R1(config)#ip prefix-list BlockNets seq ?
<1-4294967294> Sequence number
R1(config)#ip prefix-list BlockNets seq 24 ?
deny Specify packets to reject
permit Specify packets to forward
R1(config)#ip prefix-list BlockNets seq 24 deny ?
A.B.C.D IP prefix <network>/<length>, e.g., 35.0.0.0/8
R1(config)#ip prefix-list BlockNets seq 24 deny 55.5.5.5/32 ?
ge Minimum prefix length to be matched
le Maximum prefix length to be matched
<cr>
R1(config)#ip prefix-list BlockNets seq 24 deny 55.5.5.5/32 le ?
<1-32> Maximum prefix length
R1(config)#ip prefix-list BlockNets seq 24 deny 55.5.5.5/32
R1(config)#
So lets see what happens on R2:
R2#sh ip bgp
BGP table version is 11, local router ID is 2.2.2.2
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
*>i5.5.5.5/32 172.12.123.1 0 100 0 5 i
*>i55.5.5.5/32 172.12.123.1 0 100 0 5 i
R2#
And this is why I just clear ip bgp * soft in/out regularly because the commands that trigger updates are starting to blur together in my head.
R1(config)#do clear ip bgp * soft out
R1(config)#
ASR#2
[Resuming connection 2 to r2 … ]
R2#sh ip bgp
BGP table version is 12, local router ID is 2.2.2.2
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
*>i5.5.5.5/32 172.12.123.1 0 100 0 5 i
R2#
Now after the clear command we see it is now in effect, and I’d like to point out from the journey through learning Route-Maps that we generally want to put our permit/deny statements spaced out more toward the middle to give us room to work around them, but in this case my only goal was to clarify that so I went with sequence #24 to accomplish the task at hand.
That is it for Prefix Lists, I believe I have one more post coming to hit some topics quick that I didn’t get to in the main concepts, and then it will be onto new pastures!
The DEVNET GRIND! 