BGP peer groups

A peer-group is a set of BGP neighbors that shares the same outbound policy, where the inbound policies might be different.

In general iBGP peers receive the same updates all the time, making them ideal for arrangement for a peer group. The main advantage, besides ease of configuration, is the fact that updates are generated only once per peer group.

 

Figure1: Topology

 

 

The lab is structured as follows:

– Peer group policy planning.

– Configuration steps.

– Monitoring peer groups.

– Debugging and analysis the difference in behaviour with and without peer group

 

Planning

 

Let’s consider the following hypothetical autonomous system (figure1) policy:

Advertisement policy:

– The router R1 must block odd networks 11.11.11.0/24 and 33.33.33.0/24 from being advertised to its iBGP peers.

– Routers R2 and R4 are not authorized to advertise their inside networks out.

 

Deployment:

– Tag networks 11.11.11.0/24 and 33.33.33.0/24 with a special community tag 55555:666 and filter them from outbound advertisements at the router R1.

– Networks 20.0.0.0/16 and 40.0.0.0/8 will be filtered through a route-map and bind the route map to outbound advertisement with the neighbour R1.

 

Configuration steps

 

Without Peer-groups

Let’s take a closer look at the configuration at R1 without using peer-groups:

Notice that many commands are exactly the same and they are repeated for each iBGP neighbor

 

R1:

router bgp 55555    neighbor 1.1.2.2 remote-as 55555  neighbor 1.1.3.2 remote-as 55555  neighbor 1.1.4.2 remote-as 55555  neighbor 1.1.5.2 remote-as 55555    neighbor 1.1.2.2 next-hop-self  neighbor 1.1.3.2 next-hop-self  neighbor 1.1.4.2 next-hop-self  neighbor 1.1.5.2 next-hop-self    neighbor 1.1.2.2 route-reflector-client  neighbor 1.1.3.2 route-reflector-client  neighbor 1.1.4.2 route-reflector-client  neighbor 1.1.5.2 route-reflector-client    neighbor 172.16.0.6 remote-as 55556

This is a relevant case to use peer groups because it will save you from repetitive configuration of each peer and save the router itself from the effort of parsing the policy sequentially for each BGP peer and lessen necessary CPU and memory resources when inspecting routing table and generating updates.

 

With peer groups:

 

– Create a BGP peer-group:

neighbor ibgp-pgroup peer-group

 

 – Assign BGP neighbor into a peer group:

neighbor 1.1.2.2 peer-group ibgp-pgroup neighbor 1.1.3.2 peer-group ibgp-pgroup neighbor 1.1.4.2 peer-group ibgp-pgroup neighbor 1.1.5.2 peer-group ibgp-pgroup

 

– Configure needed commands for the peer-group

neighbor ibgp-pgroup remote-as 55555 neighbor ibgp-pgroup route-reflector-client neighbor ibgp-pgroup next-hop-self

 

R1:

R1#sh ip bgp peer-group ibgp-pgroup BGP peer-group is ibgp-pgroup   BGP version 4   Default minimum time between advertisement runs is 5 seconds    For address family: IPv4 Unicast   BGP neighbor is ibgp-pgroup, peer-group internal, members:   1.1.2.2 1.1.3.2 1.1.4.2 1.1.5.2   Index 0, Offset 0, Mask 0x0   Update messages formatted 0, replicated 0   Number of NLRIs in the update sent: max 0, min 0 R1#

“sh ip bgp peer-group ibgp-pgroup summary” is equivalent to  “sh ip bgp summary but just for peer-group members”

 

R1:

R1#sh ip bgp peer-group ibgp-pgroup summ BGP router identifier 1.1.1.1, local AS number 55555 BGP table version is 35, main routing table version 35 8 network entries using 936 bytes of memory 8 path entries using 416 bytes of memory 3/2 BGP path/bestpath attribute entries using 372 bytes of memory 1 BGP AS-PATH entries using 24 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 1748 total bytes of memory BGP activity 8/0 prefixes, 21/13 paths, scan interval 60 secs   Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd 1.1.2.2         4 55555     143     173       35    0    0 00:26:28        1 1.1.3.2         4 55555     140     167       35    0    0 00:26:16        1 1.1.4.2         4 55555     140     167       35    0    0 00:26:01        1 1.1.5.2         4 55555     139     165       35    0    0 00:25:49        1 R1#

 

At R6, let’s tag networks 11.11.11.0/24 and 33.33.33.0/24 with community 55556:666 and include in an outbound filter to R1:

 

R6:

access-list 10 permit 11.11.11.0 0.0.0.255 access-list 10 permit 33.33.33.0 0.0.0.255   route-map spec_community permit 10  match ip address 10  set community -654048614   router bgp 55556  neighbor 172.16.2.5 send-community  neighbor 172.16.2.5 route-map spec_community out

 

clear ip bgp 172.16.2.5 soft out

 

R1:

R1#sh ip bgp 11.11.11.0 BGP routing table entry for 11.11.11.0/24, version 37 Paths: (1 available, best #1, table Default-IP-Routing-Table)   Advertised to update-groups:      3   55556     172.16.2.6 from 172.16.2.6 (192.168.10.1)       Origin IGP, metric 0, localpref 100, valid, external, best       Community: 55556:666 R1#sh ip bgp 33.33.33.0 BGP routing table entry for 33.33.33.0/24, version 36 Paths: (1 available, best #1, table Default-IP-Routing-Table)   Advertised to update-groups:      3   55556     172.16.2.6 from 172.16.2.6 (192.168.10.1)       Origin IGP, metric 0, localpref 100, valid, external, best       Community: 55556:666 R1#

 

Only permitted networks in the access-list  10 will be tagged with 55556:666, the remaining networks are allowed to be advertised through the second route-map statement with sequence number 20.

 

Here is the route filtering at the router R1

ip bgp-community new-format ip community-list 10 permit 55556:666   route-map no_community_666 deny 10  match community 10   route-map no_community_666 permit 20   router bgp 55555  neighbor ibgp-pgroup route-map no_community_666 out

 

R1#clear ip bgp peer-group ibgp-pgroup soft out

 

The first route-map “deny” statement will block all networks with community that match the community access-list 10 (55555:666)

===>  The second route-map “permit” statement will allow advertisement of all remaining networks.

===> Do not forget to allow sending community attribute for the corresponding neighbour.

 

Let’s check the result from router R2 for instance:

R2#sh ip bgp BGP table version is 39, 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 *> 20.0.0.0/16      0.0.0.0                  0         32768 i *>i22.22.22.0/24    1.1.2.1                  0    100      0 55556 i *>i30.0.0.0/16      1.1.3.2                  0    100      0 i *>i40.0.0.0/16      1.1.4.2                  0    100      0 i *>i44.44.44.0/24    1.1.2.1                  0    100      0 55556 i *>i50.0.0.0/16      1.1.5.2                  0    100      0 i R2#

Networks 11.11.11.0/24 and 33.33.33.0/24 are no more present in all iBGP peers BGP routing table

 

To implement the second policy statement and demonstrate that peer group members can have different inbound policies,  we assigned an access-list that permit networks 20.0.0.0/16 and 40.0.0.0/8 and a new route-map with a first statement that deny the previously defined access-list and a second empty permit statement to allow all other networks, the route-map will be assigned separately to R2 and R4 inbound.

 

R1:

access-list 10 permit 20.0.0.0 0.0.255.255 access-list 10 permit 40.0.0.0 0.0.255.255   route-map diffrent_in_rmap deny 10  match ip address 10 route-map diffrent_in_rmap permit 20   router bgp 55555  neighbor 1.1.2.2 route-map diffrent_in_rmap in  neighbor 1.1.4.2 route-map diffrent_in_rmap in

 

BGP routing tables of both R1 and R6 confirm expectations:

R1:

R1#sh ip bgp BGP table version is 33, local router ID is 1.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal Origin codes: i – IGP, e – EGP, ? – incomplete      Network          Next Hop            Metric LocPrf Weight Path *> 11.11.11.0/24    172.16.0.6               0             0 55556 i *> 22.22.22.0/24    172.16.0.6               0             0 55556 i *>i30.0.0.0/16      1.1.3.2                  0    100      0 i *> 33.33.33.0/24    172.16.0.6               0             0 55556 i *> 44.44.44.0/24    172.16.0.6               0             0 55556 i *>i50.0.0.0         1.1.5.2                  0    100      0 i *> 192.168.10.0     172.16.0.6               0             0 55556 i *> 192.168.200.0    172.16.0.6               0             0 55556 i R1#

R6:

R6#sh ip bgp BGP table version is 21, local router ID is 6.6.6.6 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal Origin codes: i – IGP, e – EGP, ? – incomplete      Network          Next Hop          Metric LocPrf Weight Path *> 11.11.11.0/24    0.0.0.0                0         32768 i *> 22.22.22.0/24    0.0.0.0                0         32768 i *> 30.0.0.0/16      172.16.0.5                           0 55555 i *> 33.33.33.0/24    0.0.0.0                0         32768 i *> 44.44.44.0/24    0.0.0.0                0         32768 i *> 50.0.0.0         172.16.0.5                           0 55555 i *> 192.168.10.0     0.0.0.0                0         32768 i *> 192.168.200.0    0.0.0.0                0         32768 i R6#

Networks 20.0.0.0/16 and 40.0.0.0/8 disappeared from R1 and R6 BGP routing tables.

Next, we will inspect the difference in behavior between the configuration with and without peer-groups through “debug ip bgp update out” command.

 

Debug

 

Debug without peer-group:

 R1:

R1#debug ip bgp updates out BGP updates debugging is on (outbound) R1# R1#clear ip bgp 1.1.2.2 R1#clear ip bgp 1.1.3.2 R1#clear ip bgp 1.1.4.2 R1#clear ip bgp 1.1.5.2 R1# … *Mar  1 01:20:12.103: BGP(0): 1.1.2.2 send UPDATE (format) 44.44.44.0/24, next 1.1.2.1, metric 0, path 55556 *Mar  1 01:20:12.111: BGP(0): 1.1.2.2 send UPDATE (prepend, chgflags: 0x0) 22.22.22.0/24, next 1.1.2.1, metric 0, path 55556 *Mar  1 01:20:12.115: BGP(0): 1.1.2.2 send UPDATE (prepend, chgflags: 0x0) 33.33.33.0/24, next 1.1.2.1, metric 0, path 55556 *Mar  1 01:20:12.123: BGP(0): 1.1.2.2 send UPDATE (prepend, chgflags: 0x0) 11.11.11.0/24, next 1.1.2.1, metric 0, path 55556 *Mar  1 01:20:12.259: BGP(0): 1.1.2.2 send UPDATE (format) 20.0.0.0/16, next 1.1.2.2, metric 0, path *Mar  1 01:20:12.267: BGP(0): 1.1.2.2 send UPDATE (format) 30.0.0.0/16, next 1.1.3.2, metric 0, path *Mar  1 01:20:22.863: BGP(0): 1.1.2.2 send UPDATE (format) 50.0.0.0/16, next 1.1.5.2, metric 0, path *Mar  1 01:20:22.867: BGP(0): 1.1.2.2 send UPDATE (format) 40.0.0.0/16, next 1.1.4.2, metric 0, path …

 

*Mar  1 01:20:12.187: BGP(0): 1.1.4.2 send UPDATE (format) 44.44.44.0/24, next 1.1.4.1, metric 0, path 55556 *Mar  1 01:20:12.195: BGP(0): 1.1.4.2 send UPDATE (prepend, chgflags: 0x0) 22.22.22.0/24, next 1.1.4.1, metric 0, path 55556 *Mar  1 01:20:12.203: BGP(0): 1.1.4.2 send UPDATE (prepend, chgflags: 0x0) 33.33.33.0/24, next 1.1.4.1, metric 0, path 55556 *Mar  1 01:20:12.207: BGP(0): 1.1.4.2 send UPDATE (prepend, chgflags: 0x0) 11.11.11.0/24, next 1.1.4.1, metric 0, path 55556 *Mar  1 01:20:12.215: BGP(0): 1.1.4.2 send UPDATE (format) 30.0.0.0/16, next 1.1.3.2, metric 0, path *Mar  1 01:20:12.303: BGP(0): 1.1.4.2 send UPDATE (format) 40.0.0.0/16, next 1.1.4.2, metric 0, path *Mar  1 01:20:12.311: BGP(0): 1.1.4.2 send UPDATE (format) 20.0.0.0/16, next 1.1.2.2, metric 0, path *Mar  1 01:20:27.979: BGP(0): 1.1.4.2 send UPDATE (format) 50.0.0.0/16, next 1.1.5.2, metric 0, path …

 

*Mar  1 01:20:17.719: BGP(0): 1.1.5.2 send UPDATE (format) 44.44.44.0/24, next 1.1.5.1, metric 0, path 55556 *Mar  1 01:20:17.723: BGP(0): 1.1.5.2 send UPDATE (prepend, chgflags: 0x0) 22.22.22.0/24, next 1.1.5.1, metric 0, path 55556 *Mar  1 01:20:17.731: BGP(0): 1.1.5.2 send UPDATE (prepend, chgflags: 0x0) 33.33.33.0/24, next 1.1.5.1, metric 0, path 55556 *Mar  1 01:20:17.739: BGP(0): 1.1.5.2 send UPDATE (prepend, chgflags: 0x0) 11.11.11.0/24, next 1.1.5.1, metric 0, path 55556 *Mar  1 01:20:17.743: BGP(0): 1.1.5.2 send UPDATE (format) 50.0.0.0/16, next 1.1.5.2, metric 0, path *Mar  1 01:20:17.751: BGP(0): 1.1.5.2 send UPDATE (format) 40.0.0.0/16, next 1.1.4.2, metric 0, path *Mar  1 01:20:17.755: BGP(0): 1.1.5.2 send UPDATE (format) 20.0.0.0/16, next 1.1.2.2, metric 0, path *Mar  1 01:20:17.759: BGP(0): 1.1.5.2 send UPDATE (format) 30.0.0.0/16, next 1.1.3.2, metric 0, path … R1#

 Note that for each neighbor BGP inspect the routing table and advertise the same prefixes separately.

 

Debug with peer-groups:

 

R1:

R1# *Mar  1 04:00:08.019: BGP(0): 172.16.2.6 send UPDATE (format) 50.0.0.0/16, next 172.16.2.5, metric 0, path *Mar  1 04:00:08.027: BGP(0): 1.1.2.2 send UPDATE (format) 50.0.0.0/16, next 1.1.5.2, metric 0, path *Mar  1 04:00:08.031: BGP(0): 172.16.2.6 send UPDATE (prepend, chgflags: 0x0) 30.0.0.0/16, next 172.16.2.5, metric 0, path *Mar  1 04:00:08.039: BGP(0): 1.1.2.2 send UPDATE (format) 30.0.0.0/16, next 1.1.3.2, metric 0, path *Mar  1 04:00:08.039: BGP(0): 1.1.2.2 send UPDATE (format) 44.44.44.0/24, next 1.1.2.1, metric 0, path 55556 *Mar  1 04:00:08.039: BGP(0): 1.1.2.2 send UPDATE (prepend, chgflags: 0x0) 22.22.22.0/24, next 1.1.2.1, metric 0, path 55556 *Mar  1 04:00:08.139: BGP(0): updgrp 1 – 1.1.2.2 updates replicated for neighbors: 1.1.3.2 1.1.4.2 1.1.5.2 R1#

When advertising updates, the routing table is inspected ONLY ONE TIME, sent to one peer-group member and then duplicated to all other members 

Tags: BGP, peer-group