BGP_PrefixList_TopBGP 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!