Category Archives: CCNP – BGP

Important BGP Address-Family notes, IPv4 and IPv6 behaviors for exam day! Last post before my exam 5/26, see you on the other side!!

No Topology again, I know the lack of pictures is boring.

A few things I wanted to note about configuring address-family’s in BGP:

You can either do it as a single IPv4 or IPv6 Peering, which would look something like:

router bgp 100
  neighbor 172.12.15.5 remote-as 500
  neighbor 2005::5/64 remote-as 500
address-family ipv4
   neighbor 172.12.15.5 activate
   network (ipv4 Prefix) mask (mask)
address-family ipv6
    neighbor 2005::5/64 active
    network (ipv6 prefix) mask (ipv6 mask)

By configuring it this way, you have set at the process level that you have two neighbor Peerings, one ipv4 and one ipv6, you can then go into those address families to add the “utility” commands as mentioned in EIGRP named mode where you need to create address-family configurations (such as next-hop-self, etc) in neighbor statements.

Again – These “Utility” or “Fine Tuning” commands will no longer show at the process level for neighbor statements once address-family’s are configured, you must go into the address-family to configure fine tuning!

A second way is to use a single Peering / IP Protocol for the peering, and share routes over that one peering as such:

router bgp 100
  neighbor 172.12.15.5 remote-as 500   <—- IPv4 Peering
address-family ipv4
  neighbor 172.12.15.5 remote-as 500 activate
  network (ipv4) mask (ipv4)
address-family ipv6
   neighbor 172.12.15.5 remote-as 500 activate   <— Must specify IPv4 Peering
   network (ipv6) mask (ipv6) <—- Advertise IPv6 networks
   neighbor 172.12.15.5 route-map (word) out <– (Assign IPv6 next-hop for networks)
route-map (word) permit 10
   match ipv6 next-hop (Prefix / ACL)

Now before I get into WHY we need route-maps, I wanted to point out the criteria you have to match in when creating an IPv6 route route-map to work with BGP:

R1(config-route-map)#match ipv6 next-hop ?
  WORD         IPv6 access-list name
  prefix-list  IPv6 prefix-list
R1(config-route-map)#match ipv6 next-hop

So you will need a Prefix-List or an Access-List to input here, you cannot just enter your own IPv6 address here (as far as I can see without fully configuring it).

Why would we need a Route-Map in the address-family in the first place? Because when you are sending networks to a Peer, it must contain the following 3 things:

  • AS_PATH
  • NEXT_HOP
  • ORIGIN CODE

Those 3 things must be present in its updates, but IPv6 cannot use the IPv4 formed Peering as a next-hop, so we need to add our own IPv6 IP address for this (local) side of the peer and input that into the Address-Family to send with network updates to our peer.

The way you can tell if it is Dual Ipv4 and Ipv6 Peerings, is they will both be configured at the Process (Top level) in BGP as neighbors, whereas if you ONLY see 1 IPv4 or 1 IPv6 neighbor configured before address families, that means you are Peering with that protocol only.

So if it was IPv6 doing the single Peering, the roles would be reversed, and our neighbor statements would still go into the IPv4 family as IPv6 addresses (as our neighbors are IPv6) however the “network” statements will still advertise IPv4 IP’s – However the Route-Map will still be needed to tell our IPv6.

To quickly demonstrate the difference:

router bgp 100
neighbor 2005::5 remote-as 500
address-family ipv4

    neighbor 2005::5 remote-as 500 activate  <– Must use IPv6 Peering for neigbor
    network (ip4) mask (ipv4) <— Advertise Ipv4 networks
    neighbor 2005::5 route-map (anotherword) out <– Gives Next-Hop for IPv4 Ad’s
address-family ipv6
    neighbor 2005::5 remote 500 activate
     network (ipv6) mask (ipv6)

That is all I got in me tonight on that subject, one more entire day to review BGP then a night off from studying before exam day except maybe lightly reviewing stuff like subnetting charts and Keith B’s excellent Distribute-List comparison chart.

So you probably will not hear from me again until I am on the other side of Pass / Fail.

So hopefully next time I post I will be celebrating going into SWITCH material, or healing my wounds with a couple shots of tequila and a sober cab home 🙂

See you on the other side!!

BGP Filtering / Authentication / BGP Peer group notes for exam day!

No topology for this particular post, just some quick notes on BGP filtering which probably won’t be a huge topic on ROUTE as it’s more a Service Provider

So here we go.

BGP Filtering can be done on any router, there are no limitations like in OSPF where filtering is done on specific router types or points in the network.

Filtering can be done for inbound and outbound updates.

After filtering is enabled via filter-list / distribute-list / route-map, neighbor relationships must be reset or cleared to take effect which is done with “clear ip bg * soft [in/out]”

Now any type of filtering must be configured on a router per neighbor via the neighbor statement, whereas in IGP’s you could often just use a single command or two within the protocol itself.

Peer groups is beyond the scope of CCNP just a bit, but in case it does come up on the exam, it is a way to logically group together routers with exact the exact same BGP filtering where it will apply a light of commands across all neighbors in the Peer Group.

To Filter in BGP, you have 4 options:

  • Distribute-list
  • Prefix-list
  • Filter-list
  • Route-map

To show what they require as a next step in the command, I ran them on R1:

R1(config-router)#neighbor 172.12.15.5 distribute-list ?
  <1-199>      IP access list number
  <1300-2699>  IP access list number (expanded range)
  WORD         IP Access-list name

R1(config-router)#neighbor 172.12.15.5 prefix-list ?
  WORD  Name of a prefix list

R1(config-router)#neighbor 172.12.15.5 filter-list ?
  <1-500>  AS path access list

R1(config-router)#neighbor 172.12.15.5 route-map ?
  WORD  Name of route map

R1(config-router)#neighbor 172.12.15.5 route-map (Word)

Now with Route-Maps you can match on ACL’s, Prefix-Lists, AS Path Access-Lists, so these give you the most flexibility.

With BGP, the filter-list does not work as it did with OSPF, where it requires a prefix-list to reference – Instead it wants something called an AS path access list.

The AS Path access-list is configured with the following:

R1(config)#ip as-path access-list ?
  <1-500>  AS path access list number

R1(config)#ip as-path access-list 1 ?
  deny    Specify packets to reject
  permit  Specify packets to forward

R1(config)#ip as-path access-list 1 permit ?
  LINE  A regular-expression to match BGP AS paths. Use “ctrl-v ?” to enter “?”

R1(config)#ip as-path access-list 1 permit 200 ?
LINE    <cr>

R1(config)#ip as-path access-list 1 permit 200 500 ?
LINE    <cr>

R1(config)#ip as-path access-list 1 permit 200 500 300 ?
LINE    <cr>

R1(config)#ip as-path access-list 1 permit 200 500 300

As you can see, this is meant to filter routes based on their AS_PATH, rather than any sort of network or prefix information.

I’m going to move on here, as the ROUTE exam I believe (hope) only really requires you to know of but not need to configure these different filtering types.

My next post I have a great screen snip of Distribute-List’s differences between protocols, then I have a lot of note reviewing for BGP to get to 🙂

 

BGP Private AS’s, RID, Redistribution, and some other quick but important information for success on exam day!

Private AS Numbers:

When you look at router bgp ? you see (1-65535), which the range of 64496-65535 are actually reserved or Private AS’s, which should not be advertised Externally as Private IP’s on your LAN should not be advertised to External networks.

Also to note, you cannot use AS 0, and will get an “Invalid input” error if you try to issue “router bgp 0” on a router.

***Also some Cisco docs use the acronym ASN to indicate AS Number and some not, so be prepared if you see ASN on your exam and understand it is referring to AS Number.***

BGP RID:

As it wasn’t specifically covered (aside from demonstrating manually setting it), the RID has not come into play much, except as a tie-breaker for Best Path selection quite a few times in labs with all things equal – “bgp router-id x.x.x.x” is the command once more.

One thing to note with manual RID configuration, if you do it with live Adjacencies, it will drop those Adjacencies but they will quickly reform using the new RID configured.

Now without manually setting it, it derives its RID the same way OSPF or EIGRP does, which is first the highest logical interface IPv4 address, follow by the highest Physical interface IPv4 address.

To see the rid you can either do “sh ip bgp” / “sh ip bgp x.x.x.x”, however if you have no advertised routes you can also use “sh ip bgp summ” :

R5#sh ip bgp summ
BGP router identifier 172.16.11.1, local AS number 5
BGP table version is 7, main routing table version 7
6 network entries using 720 bytes of memory
6 path entries using 312 bytes of memory
1/1 BGP path/bestpath attribute entries using 124 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1156 total bytes of memory
BGP activity 6/0 prefixes, 6/0 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.12.15.1     4          123      97     107        7    0    0 01:33:03        0
R5#

R5’s highest logical interface, so remember there is a couple ways to get that RID if commands are disabled on exam day, in a squeeze you could go to a neighbor if you have access to its console and do “sh ip bgp nei” to get the RID of the remote Neighbor.

Another important note – If two BGP neighbors are configured with the same RID will not form an Adjacency, and the console will continuously spit out an error saying “(BGP identifer wrong)” – So be sure to note that as well!

Route Redistribution between IGP and EGP:

Although with IGP’s route redistribution generally goes both ways (but doesn’t have to), you may need to occasionally redistribute IGP routes into BGP, and there are three ways to get that to happen:

  • The network command
  • Static route redistribution
  • Redistribution of routes discovered by an IGP

The third of this list is strongly recommended by Cisco to avoid when possible as it can lead to routing loops fairly easily. Using the ‘network’ command is almost always the best way to go about doing it.

Redistributing route from BGP into an IGP is almost never a good idea, or going to be required for a task, and doing such can cause a lot of issues (considering BGP can have thousands of routes).

Bottom line, NEVER redistribute BGP into an IGP unless you have a very good reason!

AND THAT IS IT FOR BGP! Whew. Up next is a look at CEF, but definitely not tonight! 🙂

Prefix-Lists and BGP, fundamentals and configuration explained, important behaviors and more to know for exam day!

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!

BGP Route Reflector configuration, explanation / need for them, and important behaviors / verification commands!

BGP_Reflector_Top2

A router configure to be a BGP Route Reflector can take a route learned from one iBGP Peer and advertise it to another iBGP Peer, which basically is the equivalent of “no ip split-horizon” only BGP style!

iBGP Peers that send routes to the route reflector are called “clients”, and when the Reflector receives routes from clients, it reflects the routes to other clients all the while the clients have no idea they are getting their routes from a Route Reflector.

Now as seen in the Topology I’ve changed it so the Spoke routers Peer to the Hub to avoid creating a full mesh network, and the Hub will reflect routes advertised from R2 to R3 and vice versa. Also note that R2 does not have an interface in the Ethernet segment to R4 in this lab.

A BGP Speaker with a Peering does not HAVE to be a client, these are known as “nonclients”, however they do require a TCP connection to every other router in the AS (which we are trying to avoid in the first place with the reflector).

So let’s get into the configuration, all the Peerings are already configured, so I’ll start by configuring 4.4.4.4/32 to be advertised by R4, verify its in the ip bgp table, and move along to configuring R1 as the Route Reflector:

R4

R4(config-router)#network 4.4.4.4 mask 255.255.255.255
R4(config-router)#^Z
R4#
*Apr 16 08:22:56.783: %SYS-5-CONFIG_I: Configured from console by console
R4#sh ip bgp
BGP table version is 2, local router ID is 44.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       0.0.0.0                        0                        32768 i
R4#

R3

R3#sh ip bgp
BGP table version is 2, 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
*> 4.4.4.4/32       172.12.23.4              0                                 0 4 i
R3#

R1

R1#sh ip bgp
BGP table version is 1, 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
* i4.4.4.4/32       172.12.23.4              0           100                 0 4 i
R1#sh ip bgp 4.4.4.4
BGP routing table entry for 4.4.4.4/32, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  4
    172.12.23.4 (inaccessible) from 172.12.123.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal
R1#

So there are a few things going on here. First we note the route is valid, but does not have it’s fellow >, and we need to see both of those for a route in the ip bgp table. Also it shows “Not advertied to any peer router” which indicates BGP Split-Horizon in effect for that route, and finally (inaccessible) meaning it does not have a route to the destination network.

Also we have the expected BGP behavior of an iBGP Peer not advertising its interface as the Next Hop due to the route coming from a non-local AS, which we would either do some static routing, or the easier option issuing “neighbor 172.12.123.1 next-hop-self” on R3 so routes from remote AS’s are reachable.

So lets fix that issue:

R3(config)#router bgp 123
R3(config-router)#neighbor 172.12.123.1 next-hop-self
R3(config-router)#
ASR#1
[Resuming connection 1 to r1 … ]

R1#clear ip bgp * soft in
R1#sh ip bgp
BGP table version is 2, 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
*>i4.4.4.4/32       172.12.123.3             0    100      0 4 i
R1#

Now we are on the right track here, however:

R1#sh ip bgp 4.4.4.4
BGP routing table entry for 4.4.4.4/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  4
    172.12.123.3 from 172.12.123.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best
R1#

Split Horizon is still blocking the route from propagating to iBGP Peers, so I won’t bother with R2’s output, because there is nothing to show as indicated. However, lets advertise it’s loopback as well here and verify it on R1 so we can see if we can get it both routes advertising both ways:

R2#
R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router bgp 123
R2(config-router)#network 2.2.2.2 mask 255.255.255.255
R2(config-router)#^Z
R2#wr
Building configuration…

ASR#1
[Resuming connection 1 to r1 … ]

R1#sh ip bgp
BGP table version is 3, 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
*>i2.2.2.2/32       172.12.123.2             0    100      0 i
*>i4.4.4.4/32       172.12.123.3             0    100      0 4 i
R1#sh ip bgp 2.2.2.2

BGP routing table entry for 2.2.2.2/32, version 3
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Not advertised to any peer
  Local
    172.12.123.2 from 172.12.123.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best
R1#

To solve this we could Peer R2 and R3 to make a full mesh, but we want to stay away from that, because of the scalability issues if we add 20 or 30 more routers into the mix in a real world or CCIE Lab environment.

So for that very reason, we will choose option 2, configuring R1 as a Route Reflector, and I’ll have to include some ? output to point out the most obvious command in IOS help:

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 ?
  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 route-reflector-client
R1(config-router)#
*Mar 31 13:47:18.106: %BGP-5-ADJCHANGE: neighbor 172.12.123.2 Down RR client config change
R1(config-router)#
*Mar 31 13:47:20.330: %BGP-5-ADJCHANGE: neighbor 172.12.123.2 Up
R1(config-router)#neighbor 172.12.123.3 route-reflector-client
R1(config-router)#
*Mar 31 13:47:42.627: %BGP-5-ADJCHANGE: neighbor 172.12.123.3 Down RR client config change
R1(config-router)#
*Mar 31 13:47:44.850: %BGP-5-ADJCHANGE: neighbor 172.12.123.3 Up
R1(config-router)#

As usual, we see the neighbor command come into play here, and the captain obvious of commands to configure this to be a reflector to that neighbor “route-reflector-client” which is pretty self explanatory.

As can be seen, it needs to be configured for each “client” in the network, and does drop the Adjacency to that Neighbor very briefly, as seen in the time stamps it was down for about 2 seconds before the neighbor was back up.

So with that being configured, lets take a look around at our clients, and over at R4:

R2#sh ip bgp
BGP table version is 5, 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
*> 2.2.2.2/32       0.0.0.0                  0         32768 i
*>i4.4.4.4/32       172.12.123.3             0    100      0 4 i
R2#
ASR#3
[Resuming connection 3 to r3 … ]

*Mar  2 18:24:30.291: %SYS-5-CONFIG_I: Configured from console by console[OK]
R3#sh ip bgp
BGP table version is 5, 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
*>i2.2.2.2/32       172.12.123.2             0          100               0 i
*> 4.4.4.4/32       172.12.23.4                0                               0 4 i
R3#
ASR#4
[Resuming connection 4 to r4 … ]

R4#sh ip bgp
BGP table version is 3, local router ID is 44.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 2.2.2.2/32       172.12.23.3                            0 123 i
*> 4.4.4.4/32       0.0.0.0                  0         32768 i
R4#

Looks good all around!

Now the verification command for this is “sh ip bgp neighbor” which I will spare the output, but it will be found under each neighbors individual segments as “Route-Reflector Client”, as and you can also see “Last reset due to RR client config change” – So remember to view this information use “sh ip bgp nei” !

So one more topic to cover before moving onto the next topic, is that Route Reflectors do not reflect routes to everyone, and how the Route Reflectors handles a route update depending on the type of BGP router that sent it.

Here is a list to memorize to save time troubleshooting issues caused be these behaviors:

  • Updates from Route Reflector clients are sent to all clients and nonclient Peers
  • Updates sent from eBGP Peers are sent to all client and nonclient Peers
  • Updates from nonclient Peers are sent to all clients but not all nonclient Peers

So if you have nonclient peers in a Route Reflector topology, it is a red flag to watch out for that behavior of the Route reflector, eBGP and clients are good to go but nonclients will cause some chaos in the network.

That is all for that, onto Prefix lists as I believe the final BGP Topic outside of maybe some miscellaneous / helpful information 🙂 Almost there!

iBGP: Full Mesh vs Non-Full Mesh, Synchronization / Transit Rule, BGP Split horizon and other important details!

iBGP_125

Full-Mesh vs No Full-Mesh iBGP AS

The only time iBGP Speakers will advertise routes is if it meets one of the following criteria:

  • If the route was created on the local router and added via the network command
  • If you configure static route or IGP route redistribution
  • If the route is a directly connected route

However, one odd behavior of iBGP Neighbors:

  • When a BGP neighbors gets a route update from another iBGP Neighbor, it cannot advertise that route to other iBGP neighbors in their common AS

As illustrated in the Topology at the top, the advertisement would not make it through R1 to R2. To demonstrate this I will actually whip that up on the lab quick for an actual example:

R5(config)#router bgp 125
R5(config-router)#neighbor 172.12.15.1 remote-as 125
R5(config-router)#neighbor 172.12.123.2 remote-as 125
R5(config-router)#
*Apr 15 13:11:48.411: %BGP-5-ADJCHANGE: neighbor 172.12.15.1 Up
R5(config-router)#exit
R5(config)#ip route 172.12.123.0 255.255.255.0 172.12.15.1
R5(config)#

ASR#3
[Resuming connection 3 to r2 … ]

*Mar 30 16:28:33.971: %BGP-5-ADJCHANGE: neighbor 172.12.123.1 Up
R2(config-router)#
R2(config-router)#exit
R2(config)#ip route 172.12.15.0 255.255.255.0 172.12.123.1
R2(config)#
*Mar 30 16:31:12.010: %BGP-5-ADJCHANGE: neighbor 172.12.15.5 Up
R2(config)#

The Adjacency came up immediately between R1-R5, but I forgot R5 and R2 have no routes to each others networks, so as soon as I slapped a static route on both Adjacency came right up.

So lets see if this rule in action here:

R5(config)#router bgp 125
R5(config-router)#network 5.5.5.5 mask 255.255.255.255
R5(config-router)#
ASR#1
[Resuming connection 1 to r1 … ]

R1#sh ip bgp
BGP table version is 2, 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
*>i5.5.5.5/32       172.12.15.5              0    100      0 i
R1#
ASR#3
[Resuming connection 3 to r2 … ]

R2#sh ip bgp
BGP table version is 2, 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 i
R2#

Hmm. So my routers are not agreeing with the the theory, and I am guessing it is because I made R2 and R5 Neighbors, lets me make it so its R5-R1 and R1 to R2 to see if we can get that theory working here:

R2(config)#router bgp 125
R2(config-router)#no neighbor 172.12.15.5 remote-as 125
R2(config-router)#
ASR#2
[Resuming connection 2 to r5 … ]

*Apr 15 13:21:18.539: %BGP-5-ADJCHANGE: neighbor 172.12.123.2 Down Peer closed the session
*Apr 15 13:21:18.539: %BGP_SESSION-5-ADJCHANGE: neighbor 172.12.123.2 IPv4 Unicast topology base removed from session  Peer closed the session
R5(config-router)#
R5(config-router)#no neigh 172.12.123.2 remote-as 125
R5(config-router)#
ASR#1
[Resuming connection 1 to r1 … ]

R1#sh ip bgp
BGP table version is 2, 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
*>i5.5.5.5/32       172.12.15.5              0    100      0 i
R1#
ASR#3
[Resuming connection 3 to r2 … ]

*Mar 30 16:38:39.063: %BGP-5-ADJCHANGE: neighbor 172.12.15.5 Down Neighbor deleted
R2#sh ip bgp

R2#
ASR#1
[Resuming connection 1 to r1 … ]

R1#sh ip bgp 5.5.5.5
BGP routing table entry for 5.5.5.5/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  Local
    172.12.15.5 from 172.12.15.5 (5.5.5.5)
      Origin IGP, metric 0, localpref 100, valid, internal, best
R1#

There it is, this is a behavior of a non full-mesh network, whereas when it was a full mesh it had no problem advertising the route to R2. So keep that rule in mind for iBGP Peers if they are not full-mesh networks in the AS, which can be verified with “sh ip bgp summ” to see if the neighbor is in the two routers neighbor adjacency table.

So full mesh means all routers being configured with neighbor statements to eachother which may get cumbersome with the amount of iBGP neighbors in the AS, however there is an answer to this behavior which is revealed at the very end of this post!

Time to talk BGP Synchronization and The almighty “Transit Rule”

To begin this discussion let’s take a look at a different topology:

BGP_Transit_Top

Now this Topology demonstrates an important concept, but it should be apparent pretty quickly that communication between AS 5 and AS 4 will not work using AS 123 as a Transit Area.

That is because both are off spokes in an NBMA which need to communicate through the Hub, and in this Topology the hub is not Peered to any other routers so any incoming BGP packets like updates would be dropped by R1 upon receiving them.

However, there is a “Transit Rule” for BGP that allows updates from R5 to get updates of routes to R4, and here is that rule in it’s entirety as it took me a couple times hearing it to sink in:

  • BGP Rule of Synchronization: A transit AS will not advertise a route until every router in the transit AS has that same route in its IGP routing table

*** A quick off-topic snippet, while trying to set this up quick to test across my lab, I got the following output getting my AS’s mixed up:

R5(config)#no router bgp 15
R5(config)#router bgp 5
BGP is already running; AS is 125

So you cannot run more than one instance of BGP on a router, seemed like a very important detail that I previously overlooked!***

So getting back to the matter at hand, Synchronization has the benefit that if packets cannot reach their destination, it discards them which is less utilization impacting router resources as why even send packets if it cannot reach it’s destination.

BGP Synchronization is turned of by default as of IOS code 12.2(8), so if you want to turn it off in older IOS versions you would issue command “no synch” in BGP router config mode or oppositely “sync” to make sure it is on.

It is safe to turn off sync in the following scenarios:

  • All routers in the AS are running BGP
  • There’s a full mesh
  • If the AS in question (the NBMA) is not meant to be a Transit Area

That is as far as I will go into that, and get onto the next topic, but burn that rule into your brain for exam day!

BGP Split Horizon and Full Mesh Deployments

BGP Split Horizon rule states that a BGP Speaking router cannot learn a route from an iBGP, then advertise it to another iBGP peer (covered in the top of this post).

One of the ways around this is to make a full mesh network, which really is not practical, due to all the configuration (and chances to mess up the configuration) are greatly increased / the amount of TCP connections and updates would hammer all routers resources / and just generally a LOT of overhead.

There is actually a formula to find out how many TCP connections you would need for X amount of routers:

  • TCP connection formula = X (X-1) / 2, where X is the number of routers

So if you had 10 routers it would be 10 x 9 = 90, then 90 / 2 = 45, so 45 TCP connections. Remember, this is for iBGP.

Again the 3 solid reasons not to use full-mesh are the following reasons:

  • Unnecessary large amount of active TCP connections needed
  • The TCP sessions consume a lot of Bandwidth
  • Creating and maintaining them is time-intensive, will be a huge configuration to troubleshoot, and just generally will make the network admins life a pain

The work around for this issue (and possibly all of them) is Route Reflectors, which will I will be covering in extensive detail, coming up in my next post as my brain is officially shot for the morning!

 

BGP Route Aggregation / Summarization explained, configured, and some important details for exam day!

iBGP_15

I’d like to start off with a quick example of the output from when I was adjusting routers from the previous lab for this lab, by doing “no router bgp 123” on it and creating AS 15 on it, with a neigbor statement point at 172.12.15.5 and went to R5 to do the same:

*Apr 15 10:58:01.535: %BGP-3-NOTIFICATION: received from neighbor 172.12.15.1 active 2/2 (peer in wrong AS) 2 bytes 0005
R5(config)#
*Apr 15 10:58:01.535: %BGP_SESSION-5-ADJCHANGE: neighbor 172.12.15.1 IPv4 Unicast topology base removed from session  BGP Notification received
R5(config)#
*Apr 15 10:58:11.775: %BGP-3-NOTIFICATION: received from neighbor 172.12.15.1 active 2/2 (peer in wrong AS) 2 bytes 0005
R5(config)#
*Apr 15 10:58:11.775: %BGP_SESSION-5-ADJCHANGE: neighbor 172.12.15.1 IPv4 Unicast topology base removed from session  BGP Notification received
R5(config)#

This is because R5 is configured for its neighbor to be in AS 123 still, as soon as I hit “no router bgp 5” the message immediately stopped.

So just to note if this is seen in the exam, you will need to verify that the neighbor statements and AS numbers they are configured in are consistent on both sides, in this scenario it is because R5 is still running AS 5 so removing it entirely worked to stop the messages.

Anyways, enough about that output, just wanted to share the information for the sake of more knowledge.

Now I am not going to give examples of the process of breaking multiple routes down to binary, however there is a good lesson here on how to do it, but at its easiest you break all routes down to binary and find the last matching bits common to all masks and that will give you the network number while the remaining bits will give you the mask.

So to start off, I configure 4 loopback networks on R1 to summarize and confirm that BGP is seeing them on R5 as individual networks to start:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int lo8
R1(config-if)#ip add 172.16.8.1 255.255.255.0
R1(config-if)#int lo9
R1(config-if)#ip add 172.16.9.1 255.255.255.0
R1(config-if)#int lo10
R1(config-if)#ip add 172.16.10.1 255.255.255.0
R1(config-if)#int lo11
R1(config-if)#ip add 172.16.11.1 255.255.255.0
R1(config-if)#
R1(config-if)#
*Mar 31 13:14:19.667: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback8, changed state to up
*Mar 31 13:14:19.815: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback9, changed state to up
*Mar 31 13:14:19.855: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback10, changed state to up
*Mar 31 13:14:19.891: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback11, changed state to up
R1(config-if)#router bgp 15
R1(config-router)#network 172.16.8.0 mask 255.255.255.0
R1(config-router)#network 172.16.9.0 mask 255.255.255.0
R1(config-router)#network 172.16.10.0 mask 255.255.255.0
R1(config-router)#network 172.16.11.0 mask 255.255.255.0
R1(config-router)#
ASR#2
[Resuming connection 2 to r5 … ]

R5#sh ip bgp
BGP table version is 5, local router ID is 5.5.5.5
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
*>i172.16.8.0/24    172.12.15.1              0    100      0 i
*>i172.16.9.0/24    172.12.15.1              0    100      0 i
*>i172.16.10.0/24   172.12.15.1              0    100      0 i
*>i172.16.11.0/24   172.12.15.1              0    100      0 i
R5#

So when summarizing this down to a single route, you can immediately eliminate the octets that match, and write out the non-matching octet  (third) to get your summary route:

00001000 = 8
00001001 = 9
00001010 = 10
00001011 = 11

The bits stop matching on the 6th bit of the third octet, so the network is 172.16.8.0 /22, so I guess I did give sort of an example here. However it’s important to learn it ends at the last matching bit, and if the last common bit is a 0, you need to find the last matching 1’s and the will be the network number however the mask will extend out as far as the 0’s match.

That is a very important concept to pay close attention to while summarizing routes, so if your not 100% clear on that, I highly recommend visiting the above link.

Once again as this is important, you can skip over matching octets when making summary routes to save time, as all those octets bits will all match if they are the same number.

Now, onto BGP getting involved with Route Aggregation:

R1(config)#router bgp 15
R1(config-router)#?
Router configuration commands:
  address-family       Enter Address Family command mode
  aggregate-address    Configure BGP aggregate entries
  auto-summary         Enable automatic network number summarization
  bgp                  BGP specific commands
  default              Set a command to its defaults
  default-information  Control distribution of default information

I’ll spare the entire modifier list, but as can be seen, the command is right at the top highlighted in red for clarity sake in BGP router configuration mode with no preamble command like “neighbor” or “bgp” for it.

So I’ll step through the configuration of this with a ? after each step to see the options:

R1(config-router)#aggregate-address ?
  A.B.C.D  Aggregate address

R1(config-router)#aggregate-address 172.16.8.0 ?
  A.B.C.D  Aggregate mask

R1(config-router)#aggregate-address 172.16.8.0 255.255.252.0 ?
  advertise-map  Set condition to advertise attribute
  as-set         Generate AS set path information
  attribute-map  Set attributes of aggregate
  nlri           Nlri aggregate applies to
  route-map      Set parameters of aggregate
  summary-only   Filter more specific routes from updates
  suppress-map   Conditionally filter more specific routes from updates
  <cr>

R1(config-router)#aggregate-address 172.16.8.0 255.255.252.0
R1(config-router)#

I believe most of the the modifiers after the mask are beyond the scope of the CCNP course, so I’ll take the <cr> here, and see if we do need any of those modifiers.

So lets see if R5 looks any different now:

R5#sh ip bgp
BGP table version is 6, local router ID is 5.5.5.5
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
*>i172.16.8.0/24    172.12.15.1              0    100      0 i
*>i172.16.8.0/22    172.12.15.1              0    100      0 i
*>i172.16.9.0/24    172.12.15.1              0    100      0 i
*>i172.16.10.0/24   172.12.15.1              0    100      0 i
*>i172.16.11.0/24   172.12.15.1              0    100      0 i
R5#

Hmm. So we still have all our individual networks listed with the addition of the aggregate route as well now, which I don’t believe should be the behavior so I will try a clear here:

R5#clear ip bgp * soft in
R5#sh ip bgp
BGP table version is 6, local router ID is 5.5.5.5
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
*>i172.16.8.0/24    172.12.15.1              0    100      0 i
*>i172.16.8.0/22    172.12.15.1              0    100      0 i
*>i172.16.9.0/24    172.12.15.1              0    100      0 i
*>i172.16.10.0/24   172.12.15.1              0    100      0 i
*>i172.16.11.0/24   172.12.15.1              0    100      0 i
R5#

So I consulted the training material, and this is actually a default behavior of BGP when using the aggregate command with no options, you will advertise the aggregate route in addition to all the individual routes.

So to only advertise the aggregate route, we are going to need one of those modifiers in the after the aggregate address / mask in the aggregate-address command:

R1(config-router)#exit
R1(config)#router bgp 15
R1(config-router)#no aggregate-address 172.16.8.0 255.255.252.0
R1(config-router)#aggregate-address 172.16.8.0 255.255.252.0 ?
  advertise-map  Set condition to advertise attribute
  as-set         Generate AS set path information
  attribute-map  Set attributes of aggregate
  nlri           Nlri aggregate applies to
  route-map      Set parameters of aggregate
  summary-only   Filter more specific routes from updates
  suppress-map   Conditionally filter more specific routes from updates
  <cr>

R1(config-router)#aggregate-address 172.16.8.0 255.255.252.0 summary-only
R1(config-router)#

We are using summary-only here, as this will filter ALL ROUTES that are part of an aggregate route, however if you want to filter specific routes rather than all of them in the aggregate address then you could use suppress-map.

I won’t be going over suppress-map, but worth mentioning that is used to filter some routes, summary-only will filter all routes that fit into the summary network.

Now to verify on R5:

R5#sh ip bgp
BGP table version is 12, local router ID is 5.5.5.5
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
*>i172.16.8.0/22    172.12.15.1              0    100      0 i
R5#

Didn’t need to clear ip bgp for this to turn into an aggregate route only, so it does get advertised with an update to the neighbor, whereas we saw that changing routing behaviors like “next-hop-self” didn’t trigger an update so the “clear ip bgp * soft in/out” command needed to be used to change the tables up.

And that is it for summary routes in BGP, next up I don’t believe I will need a lab for, but it will be a LOT of Theory / Fundamentals of Synchornization / Route Reflectors / Full Meshes / Lack of Full Meshes.