BGP link-bw & multipath Load Balancing

 

An autonomous system can be connected to another through multiple links and according to the company business and redundancy requirements different schemes can be used:

-          Primary/secondary: where the second link is used only when the first link fails.

-           Symmetric load-sharing: where the traffic is equally distributed among multiple links in the same time, which provides a high level of redundancy for the enterprise.

But, it’s not always possible to provide equal bandwidth links because of either financial limits or availability of such solution. So the need to engineer traffic through these links according to their  bandwidth  capacity.

Here comes the solution of BGP link bandwidth.

With the deployment of BGP multipath, generally the decision of using multiple path to deliver the traffic is performed inside the autonomous system by an iBGP according to multiple criteria excluding the eBGP link bandwidth.

BGP link-bw advertise bandwidth of an autonomous system exit link as extended community to iBGP.

Some requirements are to be considered:

-          Only between directly connected eBGP peers.

-          BGP extended community should be enabled between iBGP.

-          CEF should be enabled everywhere.

Figure 1 illustrates the lab topology used to implement BGP link-bw

Figure1: Topology

Inside AS 64540, R1, R2 and R3 establish full mesh iBGP sessions, the same for AS 64550: R4, R5, R6 and R7 establish full mesh iBGP sessions.

Links R2-R4, R5-R3, R6-R3 are direct eBGP sessions using interfaces ip addresses as sources and destinations.

 

Network default behavior

The network default configuration is as follow:

AS 64540:

R1:

R1(config-router)#do sh ip bgp BGP table version is 3, local router ID is 10.10.10.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 *> 10.10.10.0/24    0.0.0.0                  0         32768 i * i70.70.70.0/24    3.3.3.3                  0    100      0 64550 i *>i                 2.2.2.2                  0    100      0 64550 i R1(config-router)#

 

R1(config-router)#do sh ip bgp 70.70.70.0 BGP routing table entry for 70.70.70.0/24, version 3 Paths: (2 available, best #2, table Default-IP-Routing-Table)   Not advertised to any peer   64550     3.3.3.3 (metric 2297856) from 3.3.3.3 (3.3.3.3)       Origin IGP, metric 0, localpref 100, valid, internal   64550     2.2.2.2 (metric 2297856) from 2.2.2.2 (2.2.2.2)       Origin IGP, metric 0, localpref 100, valid, internal, best R1(config-router)#

the default path chosen is through R2-R4:

R1(config-router)#do traceroute 70.70.70.1 source 10.10.10.1   Type escape sequence to abort. Tracing the route to 70.70.70.1     1 192.168.12.2 24 msec 320 msec 452 msec   2 192.168.24.2 1004 msec 716 msec 484 msec   3 192.168.47.2 292 msec *  556 msec R1(config-router)#

So the traffic from R1 to R7 takes the path R1-R2-R7

 Table1: best path selection for 70.70.70.1/24 from R1

	Attribute	Path1	Path2
1	weight	0	0
2	local preference	100	100
3	originated locally	No	No
4	AS_PATH	64550	64550
5	ORIGIN	i	i
6	MED	0	0
7	eBGP<>iBGP	iBGP	iBGP
8	Best IGP metric to NEXT-HOP	2297856	2297856
9	Multipath	No	No
10	oldest path	No	No
11	Lowest neighbor router-ID	3.3.3.3	2.2.2.2  <<<

 

AS 64550:

R7:

R7(config-router)#do sh ip bgp BGP table version is 3, local router ID is 70.70.70.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 * i10.10.10.0/24    5.5.5.5                  0    100      0 64540 i *>i                 4.4.4.4                  0    100      0 64540 i * i                 6.6.6.6                  0    100      0 64540 i *> 70.70.70.0/24    0.0.0.0                  0         32768 i R7(config-router)#

 

R7(config-router)#do traceroute 10.10.10.1 source 70.70.70.1   Type escape sequence to abort. Tracing the route to 10.10.10.1     1 192.168.47.1 8 msec 268 msec 104 msec   2 192.168.24.1 164 msec 348 msec 136 msec   3 192.168.12.1 276 msec *  260 msec R7(config-router)#

So the traffic from R7 to R1 takes the path R7-R4-R2-R1

R7(config-router)#do sh ip bgp 10.10.10.0 BGP routing table entry for 10.10.10.0/24, version 3 Paths: (3 available, best #2, table Default-IP-Routing-Table)   Not advertised to any peer   64540     5.5.5.5 (metric 2297856) from 5.5.5.5 (5.5.5.5)       Origin IGP, metric 0, localpref 100, valid, internal   64540     4.4.4.4 (metric 2297856) from 4.4.4.4 (4.4.4.4)       Origin IGP, metric 0, localpref 100, valid, internal, best   64540     6.6.6.6 (metric 2297856) from 6.6.6.6 (6.6.6.6)       Origin IGP, metric 0, localpref 100, valid, internal R7(config-router)#

 

R4-R2 link is chosen as the best path to reach the prefix 10.10.10.1/24:

Table2: best path selection for 10.10.10.1/24 from R7

	Attribute	Path1	Path2	Path3
1	weight	0	0	0
2	local preference	100	100	100
3	originated locally	No	No	No
4	AS_PATH	64540	64540	64540
5	ORIGIN	i	i	i
6	MED	0	0	0
7	eBGP<>iBGP	iBGP	iBGP	iBGP
8	Best IGP metric to NEXT-HOP	2297856	2297856	2297856
9	Multipath	No	No	No
10	oldest path	No	No	No
11	Lowest neighbor router-ID	5.5.5.5	4.4.4.4  <<<	6.6.6.6

 

BGP Link-BW deployment

The best way to utilize BW resources is to load-share the traffic among the three eBGP link according to their BW:

let’s recall the requirements for using BGP link BW:

- Requires BGP multipath configured.

- Enable BGP ext. community between iBGP.

- Enable CEF everywhere.

General configuration:

On each iBGP speaker with multilink ramification, enable iBGP multipath

router bgp <ASnbr>  maximum-paths <n>  maximum-paths ibgp <n>

 

router bgp <ASnbr>  address-family ipv4  neighbor <iBGP_peer> activate  neighbor <iBGP_peer> send-community extended !iBGP peer to which extended community is to be send.    neighbor <eBGP_peer> activate  neighbor <eBGP_peer> dmzlink-bw !Allow eBGP bandwidth to be propagated through link-bw extended community    bgp dmzlink-bw !“bgp dmzlink-bw” is configured on any router whose eBGP link bandwidth !will be used for load-balancing.  exit-address-family

 

As 65540:

R1(iBGP):

router bgp 64540  address-family ipv4  neighbor 2.2.2.2 activate  neighbor 3.3.3.3 activate    maximum-paths 3  maximum-paths ibgp 3    exit-address-family

eBGP speaker R2:

router bgp 64540  address-family ipv4  neighbor 1.1.1.1 activate  neighbor 1.1.1.1 send-community extended  neighbor 1.1.1.1 next-hop-self    neighbor 3.3.3.3 activate  neighbor 3.3.3.3 next-hop-self    neighbor 192.168.24.2 activate  neighbor 192.168.24.2 dmzlink-bw  bgp dmzlink-bw  exit-address-family

eBGP speaker R3:

router bgp 64540    address-family ipv4  neighbor 1.1.1.1 activate  neighbor 1.1.1.1 send-community extended  neighbor 1.1.1.1 next-hop-self    neighbor 2.2.2.2 activate  neighbor 2.2.2.2 next-hop-self    neighbor 192.168.35.2 activate  neighbor 192.168.35.2 dmzlink-bw    neighbor 192.168.36.2 activate  neighbor 192.168.36.2 dmzlink-bw    maximum-paths 2  maximum-paths ibgp 2    bgp dmzlink-bw    exit-address-family

 

Verification:

R1#sh ip route Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP        D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area        N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2        E1 – OSPF external type 1, E2 – OSPF external type 2        i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2        ia – IS-IS inter area, * – candidate default, U – per-user static route        o – ODR, P – periodic downloaded static route   Gateway of last resort is not set        192.168.12.0/30 is subnetted, 1 subnets C       192.168.12.0 is directly connected, Serial1/0      1.0.0.0/32 is subnetted, 1 subnets C       1.1.1.1 is directly connected, Loopback0      192.168.13.0/30 is subnetted, 1 subnets C       192.168.13.0 is directly connected, Serial1/1      2.0.0.0/32 is subnetted, 1 subnets D       2.2.2.2 [90/2297856] via 192.168.12.2, 03:20:35, Serial1/0      70.0.0.0/24 is subnetted, 1 subnets B       70.70.70.0 [200/0] via 3.3.3.3, 01:11:12                    [200/0] via 2.2.2.2, 01:11:12      3.0.0.0/32 is subnetted, 1 subnets D       3.3.3.3 [90/2297856] via 192.168.13.2, 03:20:29, Serial1/1      10.0.0.0/24 is subnetted, 1 subnets C       10.10.10.0 is directly connected, Loopback1 R1#

 

R1#sh ip route 70.70.70.1 Routing entry for 70.70.70.0/24   Known via “bgp 64540″, distance 200, metric 0   Tag 64550, type internal   Last update from 2.2.2.2 01:08:48 ago   Routing Descriptor Blocks:     3.3.3.3, from 3.3.3.3, 01:08:48 ago       Route metric is 0, traffic share count is 1       AS Hops 1       Route tag 64550   * 2.2.2.2, from 2.2.2.2, 01:08:48 ago       Route metric is 0, traffic share count is 1       AS Hops 1       Route tag 64550   R1#

R1:

R1#sh ip bgp 70.70.70.1 BGP routing table entry for 70.70.70.0/24, version 7 Paths: (2 available, best #2, table Default-IP-Routing-Table) Multipath: eBGP iBGP   Not advertised to any peer   64550     3.3.3.3 (metric 2297856) from 3.3.3.3 (3.3.3.3)       Origin IGP, metric 0, localpref 100, valid, internal, multipath       DMZ-Link Bw 1443 kbytes   64550     2.2.2.2 (metric 2297856) from 2.2.2.2 (2.2.2.2)       Origin IGP, metric 0, localpref 100, valid, internal, multipath, best       DMZ-Link Bw 12500 kbytes R1#

Note the proportion of the link BW of path 2 (through 2.2.2.2) against link BW of path 1 (through 3.3.3.3).

 Table3: best path selection for 70.70.70.1/24 from R1 after BGP Link-bw

	Attribute	Path1	Path2
1	weight	0	0
2	local preference	100	100
3	originated locally	No	No
4	AS_PATH	64550	64550
5	ORIGIN	i	i
6	MED	0	0
7	eBGP<>iBGP	iBGP	iBGP
8	Best IGP metric to NEXT-HOP	2297856	2297856
9	Multipath	2 <<<<	2 <<<<
10	oldest path	No	No
11	Lowest neighbor router-ID	3.3.3.3	2.2.2.2

 

R3:

R3#sh ip route Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP        D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area        N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2        E1 – OSPF external type 1, E2 – OSPF external type 2        i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2        ia – IS-IS inter area, * – candidate default, U – per-user static route        o – ODR, P – periodic downloaded static route   Gateway of last resort is not set        192.168.12.0/30 is subnetted, 1 subnets D       192.168.12.0 [90/2681856] via 192.168.13.1, 03:21:04, Serial1/0      1.0.0.0/32 is subnetted, 1 subnets D       1.1.1.1 [90/2297856] via 192.168.13.1, 03:21:04, Serial1/0      192.168.13.0/30 is subnetted, 1 subnets C       192.168.13.0 is directly connected, Serial1/0      2.0.0.0/32 is subnetted, 1 subnets D       2.2.2.2 [90/2809856] via 192.168.13.1, 03:21:04, Serial1/0      70.0.0.0/24 is subnetted, 1 subnets B       70.70.70.0 [20/0] via 192.168.35.2, 01:11:47                    [20/0] via 192.168.36.2, 01:11:47      3.0.0.0/32 is subnetted, 1 subnets C       3.3.3.3 is directly connected, Loopback0      10.0.0.0/24 is subnetted, 1 subnets B       10.10.10.0 [200/0] via 1.1.1.1, 01:18:16      192.168.36.0/30 is subnetted, 1 subnets C       192.168.36.0 is directly connected, Serial1/1      192.168.35.0/30 is subnetted, 1 subnets C       192.168.35.0 is directly connected, Ethernet0/0 R3#

 

R3#sh ip route 70.70.70.1 Routing entry for 70.70.70.0/24   Known via “bgp 64540″, distance 20, metric 0   Tag 64550, type external   Last update from 192.168.36.2 01:09:28 ago   Routing Descriptor Blocks:   * 192.168.35.2, from 192.168.35.2, 01:09:28 ago       Route metric is 0, traffic share count is 1       AS Hops 1       Route tag 64550     192.168.36.2, from 192.168.36.2, 01:09:28 ago       Route metric is 0, traffic share count is 1       AS Hops 1       Route tag 64550   R3#

 

R3#sh ip bgp 70.70.70.1 BGP routing table entry for 70.70.70.0/24, version 6 Paths: (3 available, best #1, table Default-IP-Routing-Table) Multipath: eBGP iBGP   Advertised to update-groups:      1          2          3   64550     192.168.35.2 from 192.168.35.2 (5.5.5.5)       Origin IGP, localpref 100, valid, external, multipath, best       DMZ-Link Bw 1250 kbytes   64550     2.2.2.2 (metric 2809856) from 2.2.2.2 (2.2.2.2)       Origin IGP, metric 0, localpref 100, valid, internal   64550     192.168.36.2 from 192.168.36.2 (6.6.6.6)       Origin IGP, localpref 100, valid, external, multipath       DMZ-Link Bw 193 kbytes R3#

Note the proportion of the link BW of path 1 (through 192.168.35.2) against link BW of path 1 (through 192.168.36.2).

AS 64550:

The same configuration can be done for AS 64550 to have a symmetric traffic flow between the two ASs:

R4:

R4#bgpcf router bgp 64550  address-family ipv4  neighbor 5.5.5.5 activate    neighbor 6.6.6.6 activate    neighbor 7.7.7.7 activate    neighbor 7.7.7.7 send-community extended    neighbor 192.168.24.1 activate    neighbor 192.168.24.1 dmzlink-bw    bgp dmzlink-bw  exit-address-family

R5:

bgp 64550  address-family ipv4  neighbor 4.4.4.4 activate    neighbor 6.6.6.6 activate     neighbor 7.7.7.7 activate    neighbor 7.7.7.7 send-community extended    neighbor 192.168.35.1 activate    neighbor 192.168.35.1 dmzlink-bw    bgp dmzlink-bw    exit-address-family

R6:

router bgp 64550  address-family ipv4  neighbor 4.4.4.4 activate     neighbor 5.5.5.5 activate    neighbor 7.7.7.7 activate  neighbor 7.7.7.7 send-community extended     neighbor 192.168.36.1 activate    neighbor 192.168.36.1 dmzlink-bw    bgp dmzlink-bw    exit-address-family

R7:

router bgp 64550  address-family ipv4  neighbor 4.4.4.4 activate  neighbor 5.5.5.5 activate  neighbor 6.6.6.6 activate     maximum-paths 3  maximum-paths ibgp 3    exit-address-family

 

R7#sh ip bgp 10.10.10.1 BGP routing table entry for 10.10.10.0/24, version 9 Paths: (3 available, best #3, table Default-IP-Routing-Table) Multipath: eBGP iBGP Flag: 0×800   Not advertised to any peer   64540     5.5.5.5 (metric 2297856) from 5.5.5.5 (5.5.5.5)       Origin IGP, metric 0, localpref 100, valid, internal, multipath       DMZ-Link Bw 1250 kbytes   64540     6.6.6.6 (metric 2297856) from 6.6.6.6 (6.6.6.6)       Origin IGP, metric 0, localpref 100, valid, internal, multipath       DMZ-Link Bw 193 kbytes   64540     4.4.4.4 (metric 2297856) from 4.4.4.4 (4.4.4.4)       Origin IGP, metric 0, localpref 100, valid, internal, multipath, best       DMZ-Link Bw 12500 kbytes R7#

 

Table4: best path selection for 10.10.10.1/24 from R7 after configuring BGP link-bw

	Attribute	Path1	Path2	Path3
1	weight	0	0	0
2	local preference	100	100	100
3	originated locally	No	No	No
4	AS_PATH	64540	64540	64540
5	ORIGIN	i	i	i
6	MED	0	0	0
7	eBGP<>iBGP	iBGP	iBGP	iBGP
8	Best IGP metric to NEXT-HOP	2297856	2297856	2297856
9	Multipath	3 <<<<	3 <<<<	3 <<<<
10	oldest path	No	No	No
11	Lowest neighbor router-ID	5.5.5.5	4.4.4.4	6.6.6.6

 

CONCLUSION

BGP link-bw provides an optimal way to use link bandwidth resources between autonomous systems, make sure CEF is enabled (enabled by default), iBGP multipath is already configured and enable the propagation of the extended community to iBGP neighbors.

Tags: BGP, Load+Balancing

BGP peer-session and peer-policy templates

A Peer template is a pattern, a model that can be used to facilitate the management of  BGP peer configuration. Templates are much more flexible than Peer-group because of the concept of inheritance, in which a common template can be inherited by more specific templates according to a hierarchical scheme.

Two types of templates are available: peer-session templates for session establishment and peer-policy templates for prefix advertisement policies.

Without a prior good planning, peer-templates can turn into a mess,  the key is to organize commands by groups from the most common (at the root and nodes of the tree) to the most specific (towards leaves).

Each template in the tree can be applied directly as a configuration pattern for a BGP peer or inherited by an more specific template for more granularity(Figure1).

Figure1: Tree of inheritance

Figure 2 illustrates the topology used to deploy peer-templates: ISPA (AS 56000) connects five customers (AS 56501, 56502, 56503, 56504 and 56505), ISPA is connected in its turn to an upstream ISPB (AS 55000).

Figure2: Topology

The hypothetical policy requirements are as follows:

*  One inbound policy is common to all clients, so the root template in the hierarchy of inheritance will contain common policy commands to all categories:

- Receive only Customer prefixes.

- ISPA accept maximum 2 prefixes from each client.

 * Outbound policies on ISPA to clients are organized in three categories:

1- Policy1 – Advertise only the default route: “Default_Only” template.

2- Policy2 – Advertise the default route and only ISPA (direct upstream) routes: “Default_n_Local” template.

3- Policy3 – Advertise full BGP (ISPA, ISPB and other clients prefixes): “Full_BGP” template.

The following table resumes the policies and common configurations between ISPA and its downstream customers :

Table 1: configuration and policies

			R1-ISPA	R2-ISPA	R3-ISPA	R4-ISPA	R5-ISPA
Session	BGP version & timers		x
	Direct interface eBGP				x		x
	eBGP between loopback interfaces : - set eBGP TTL to 2 - specify loopback as source of updates			x		x
Policy	Outbound policy	Policy 1 (Only default route)	x	x
		Policy 2 (default route + ISPA local networks)			x	x
		Policy 3 (Full BGP)					x
	Inbound policy	Policy 4 Accept only customer prefixes  (max 2).	x
	description		own	own	own	own	own

 

Configuring Peer-Session Template

Let’s start by configuring BGP sessions with customers.

Under BGP configuration mode ,templates are designed according to table1:

ISPA:

template peer-session Common_Session_Config   version 4   timers 30 90  exit-peer-session

This template is common to all sessions and considered as the root peer-session template.

template peer-session Indirect_eBGP   ebgp-multihop 2   update-source Loopback0   inherit peer-session Common_Session_Config  exit-peer-session

This one inherit commands from the “Common_Session_Config” template in addition to its own commands.

ISPA#sh ip bgp template peer-session Template:Common_Session_Config, index:1 Local policies:0×22, Inherited polices:0×0  *Inherited by Template Indirect_eBGP, index= 2 Locally configured session commands:  version 4  timers 30 90 Inherited session commands:   Template:Indirect_eBGP, index:2 Local policies:0×88, Inherited polices:0×22 This template inherits:   Common_Session_Config index:1 flags:0×0 Locally configured session commands:  ebgp-multihop 2  update-source Loopback0 Inherited session commands:  version 4  timers 30 90   ISPA#

Now each neighbor will just inherit the template and apply included commands:

router bgp 56000  neighbor 1.1.1.1 remote-as 56501  neighbor 1.1.1.1 inherit peer-session Indirect_eBGP    neighbor 2.2.2.2 remote-as 56502  neighbor 2.2.2.2 inherit peer-session Indirect_eBGP    neighbor 4.4.4.4 remote-as 56504  neighbor 4.4.4.4 inherit peer-session Indirect_eBGP    neighbor 10.1.12.2 remote-as 56503  neighbor 10.1.12.2 inherit peer-session Common_Session_Config    neighbor 10.1.20.2 remote-as 56505  neighbor 10.1.20.2 inherit peer-session Common_Session_Config

BGP sessions are built according to applied templates:

ISPA#sh ip bgp summ BGP router identifier 100.1.1.1, local AS number 56000 BGP table version is 7, main routing table version 7 6 network entries using 702 bytes of memory 6 path entries using 312 bytes of memory 7/6 BGP path/bestpath attribute entries using 868 bytes of memory 5 BGP AS-PATH entries using 120 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 2002 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 1.1.1.1         4 56501      26      31        7    0    0 00:10:39        1 2.2.2.2         4 56502      12      18        7    0    0 00:04:11        0 4.4.4.4         4 56504       7      12        7    0    0 00:01:15        1 10.1.12.2       4 56503       7      12        7    0    0 00:02:48        1 10.1.20.2       4 56505       5      10        7    0    0 00:00:29        1 200.2.2.2       4 55000      34      39        7    0    0 00:30:36        1 ISPA#

 

ISPA(config-router)#do sh ip bgp BGP table version is 11, local router ID is 100.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 *> 10.0.0.0/24      1.1.1.1                  0             0 56501 i *> 11.0.0.0/24      1.1.1.1                  0             0 56501 i *> 12.0.0.0/24      1.1.1.1                  0             0 56501 i *> 13.0.0.0/24      1.1.1.1                  0             0 56501 i *> 20.0.0.0/24      2.2.2.2                  0             0 56502 i *> 30.0.0.0/24      10.1.12.2                0             0 56503 i *> 40.0.0.0/24      4.4.4.4                  0             0 56504 i *> 50.0.0.0/24      10.1.20.2                0             0 56505 i *> 55.55.0.0/16     200.2.2.2                0             0 55000 i *> 56.56.0.0/16     0.0.0.0                  0         32768 i ISPA(config-router)#

Without any policy applied client routers R1, R2, R3, R4 and R5 receive all prefixes (equivalent of full BGP) as shown in the following routing table of R1:

R1#sh ip bgp BGP table version is 11, local router ID is 10.0.0.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 *> 10.0.0.0/24      0.0.0.0                  0         32768 i *> 11.0.0.0/24      0.0.0.0                  0         32768 i *> 12.0.0.0/24      0.0.0.0                  0         32768 i *> 13.0.0.0/24      0.0.0.0                  0         32768 i *> 20.0.0.0/24      100.1.1.1                              0 56000 56502 i *> 30.0.0.0/24      100.1.1.1                              0 56000 56503 i *> 40.0.0.0/24      100.1.1.1                              0 56000 56504 i *> 50.0.0.0/24      100.1.1.1                              0 56000 56505 i *> 55.55.0.0/16     100.1.1.1                              0 56000 55000 i *> 56.56.0.0/16     100.1.1.1                0             0 56000 i R1#

 

Peer-policy Template configuration

ISPA:

ip as-path access-list 10 permit ^([0-9]+)$   router bgp 56000  template peer-policy Common_Policy_Config   filter-list 10 in   maximum-prefix 2  exit-peer-policy

 

ip prefix-list NOTHING_plist seq 5 deny 0.0.0.0/0 le 32   router bgp 56000 template peer-policy Default_Only   prefix-list NOTHING_plist out   default-originate  exit-peer-policy

 

ip as-path access-list 20 permit ^$   router bgp 56000 template peer-policy Default_n_Local   filter-list 20 out   default-originate   inherit peer-policy Common_Policy_Config 10  exit-peer-policy

 

access-list 11 permit any   route-map Full_BGP_rmap permit 10  match ip address 11   router bgp 56000  template peer-policy Full_BGP   route-map Full_BGP_rmap out   inherit peer-policy Common_Policy_Config 10  exit-peer-policy

 

ISPA#sh ip bgp template peer-policy Template:Default_Only, index:2. Local policies:0×480, Inherited polices:0×0 Locally configured policies:   prefix-list NOTHING_plist out   default-originate route-map none Inherited policies:   Template:Common_Policy_Config, index:1. Local policies:0×80004, Inherited polices:0×0  *Inherited by Template Default_n_Local, index:3  *Inherited by Template Full_BGP, index:4 Locally configured policies:   filter-list 10 in   maximum-prefix 2 Inherited policies:   Template:Default_n_Local, index:3. Local policies:0×408, Inherited polices:0×80004 This template inherits:   Common_Policy_Config, index:1, seq_no:10, flags:0×408 Locally configured policies:   filter-list 20 out   default-originate route-map none Inherited policies:   filter-list 10 in   maximum-prefix 2   Template:Full_BGP, index:4. Local policies:0×2, Inherited polices:0×80004 This template inherits:   Common_Policy_Config, index:1, seq_no:10, flags:0×2 Locally configured policies:   route-map Full_BGP_rmap out Inherited policies:   filter-list 10 in   maximum-prefix 2   ISPA#

 

Apply peer-policy-template

ISPA:

router bgp 56000  neighbor 1.1.1.1 inherit peer-policy Default_Only  neighbor 2.2.2.2 inherit peer-policy Default_Only  neighbor 4.4.4.4 inherit peer-policy Default_n_Local  neighbor 10.1.12.2 inherit peer-policy Default_n_Local  neighbor 10.1.20.2 inherit peer-policy Full_BGP

R1 (1.1.1.1) and R2 (2.2.2.2) will receive only default route from ISPA.

R3 (10.1.12.2) and R4 (4.4.4.4) will receive default route and ISPA prefixes.

R5 will receive all routes (full BGP).

ISPA#clear ip bgp *

 

R1: (After applying peer-policy template on ISPA)

R1#sh ip bgp BGP table version is 48, local router ID is 10.0.0.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 *> 0.0.0.0          100.1.1.1                0             0 56000 i *> 10.0.0.0/24      0.0.0.0                  0         32768 i *> 11.0.0.0/24      0.0.0.0                  0         32768 i R1#

 

R2: (After applying peer-policy template on ISPA)

R2#sh ip bgp BGP table version is 55, local router ID is 20.0.0.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 *> 0.0.0.0          100.1.1.1                0             0 56000 i *> 20.0.0.0/24      0.0.0.0                  0         32768 i R2#

 

R3: (After applying peer-policy template on ISPA)

R3#sh ip bgp BGP table version is 20, local router ID is 30.0.0.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 *> 0.0.0.0          10.1.12.1                0             0 56000 i *> 30.0.0.0/24      0.0.0.0                  0         32768 i *> 56.56.0.0/16     10.1.12.1                0             0 56000 i R3#

 

R4: (After applying peer-policy template on ISPA)

R4#sh ip bgp BGP table version is 4, local router ID is 40.0.0.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 *> 0.0.0.0          100.1.1.1                0             0 56000 i *> 40.0.0.0/24      0.0.0.0                  0         32768 i *> 56.56.0.0/16     100.1.1.1                0             0 56000 i R4#

 

R5: (After applying peer-policy template on ISPA)

R5#sh ip bgp BGP table version is 8, local router ID is 50.0.0.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 *> 10.0.0.0/24      10.1.20.1                              0 56000 56501 i *> 20.0.0.0/24      10.1.20.1                              0 56000 56502 i *> 30.0.0.0/24      10.1.20.1                              0 56000 56503 i *> 40.0.0.0/24      10.1.20.1                              0 56000 56504 i *> 50.0.0.0/24      0.0.0.0                  0         32768 i *> 55.55.0.0/16     10.1.20.1                              0 56000 55000 i *> 56.56.0.0/16     10.1.20.1                0             0 56000 i R5#

And R5 has received the full BGP routing table.

Tags: BGP, Template

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 0×0   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: 0×0) 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: 0×0) 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: 0×0) 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: 0×0) 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: 0×0) 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: 0×0) 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: 0×0) 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: 0×0) 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: 0×0) 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: 0×0) 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: 0×0) 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

ORF (Outbound Route Filtering)

Generally eBGP speakers filter advertisement separately, the sender applies its outbound filter and the receiver applies its inbound filters to received updates.

The obvious goal of filtering at the receiver is to deny certain prefixes, sent by eBGP peer, according to its own policy… So why send them at all?

ORF (Outbound Route Filtering) is a step further in the cooperation between the two autonomous systems, where the receiver send  its inbound filter to the sender to be used as outbound filter, thus avoiding unnecessary updates in the link and CPU resources related to update generation and inbound filtering.

The goal of this LAB is to show the benefit of ORF comparing to the traditional method.

Let’s consider the eBGP connection between R1 and R2 (figure1) , with a an R1 inbound policy allowing only prefix 20.20.10.0/24

Figure1: topology

1) Before Applying ORF:

R1 and R2 configurations look as follows:

R1:

ip prefix-list only_202010 seq 5 permit 20.20.10.0/24   router bgp 65500  neighbor 2.2.2.2 remote-as 65501  neighbor 2.2.2.2 ebgp-multihop 2  neighbor 2.2.2.2 update-source Loopback0  neighbor 2.2.2.2 prefix-list only_202010 in

R2:

router bgp 65501  network 20.20.10.0 mask 255.255.255.0  network 20.20.20.0 mask 255.255.255.0  neighbor 1.1.1.1 remote-as 65500  neighbor 1.1.1.1 ebgp-multihop 2  neighbor 1.1.1.1 update-source Loopback0

1-a) Debug R2 outbound

R2:

R2#debug ip bgp updates out BGP updates debugging is on (outbound) for address family: IPv4 Unicast R2#clear ip bgp 1.1.1.1 soft out R2# *Mar  1 00:40:43.155: BGP(0): 1.1.1.1 send UPDATE (format) 20.20.20.0/24, next 2.2.2.2, metric 0, path Local *Mar  1 00:40:43.155: BGP(0): 1.1.1.1 send UPDATE (prepend, chgflags: 0×0) 20.20.10.0/24, next 2.2.2.2, metric 0, path Local *Mar  1 00:40:43.159: BGP(0): 1.1.1.1 send UPDATE (format) 10.10.10.0/24, next 2.2.2.2, metric 0, path 65500 *Mar  1 00:40:43.159: BGP(0): 1.1.1.1 send UPDATE (prepend, chgflags: 0×820) 10.10.20.0/24, next 2.2.2.2, metric 0, path 65500 *Mar  1 00:40:43.263: BGP(0): updgrp 1 – 1.1.1.1 updates replicated for neighbors: R2#

1-b) Debug R1 inbound

R1:

R1#debug ip bgp updates in BGP updates debugging is on (inbound) for address family: IPv4 Unicast R1# R1#clear ip bgp 2.2.2.2 soft in R1# R1# *Mar  1 00:40:43.487: BGP(0): 2.2.2.2 rcvd UPDATE w/ attr: nexthop 2.2.2.2, origin i, metric 0, path 65501 *Mar  1 00:40:43.487: BGP(0): 2.2.2.2 rcvd 20.20.20.0/24 — DENIED due to: distribute/prefix-list; *Mar  1 00:40:43.491: BGP(0): 2.2.2.2 rcvd 20.20.10.0/24…duplicate ignored *Mar  1 00:40:43.491: BGP(0): 2.2.2.2 rcv UPDATE w/ attr: nexthop 2.2.2.2, origin i, originator 0.0.0.0, path 65501 65500, community , extended community *Mar  1 00:40:43.495: BGP(0): 2.2.2.2 rcv UPDATE about 10.10.10.0/24 — DENIED due to: AS-PATH contains our own AS; *Mar  1 00:40:43.495: BGP(0): 2.2.2.2 rcv UPDATE about 10.10.20.0/24 — DENIED due to: AS-PATH contains our own AS; R1#

 

R1#sh ip bgp BGP table version is 16, local router ID is 10.10.20.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 *> 10.10.10.0/24    0.0.0.0                  0         32768 i *> 10.10.20.0/24    0.0.0.0                  0         32768 i *> 20.20.10.0/24    2.2.2.2                  0             0 65501 i R1#

 

2) With ORF feature

2-a) ORF configuration:

R1:

ip prefix-list only_202010 seq 5 permit 20.20.10.0/24   router bgp 65500  neighbor 2.2.2.2 prefix-list only_202010 in  neighbor 2.2.2.2 capability orf prefix-list both

R2:

router bgp 65501  network 20.20.10.0 mask 255.255.255.0  network 20.20.20.0 mask 255.255.255.0  neighbor 1.1.1.1 remote-as 65500  neighbor 1.1.1.1 ebgp-multihop 2  neighbor 1.1.1.1 update-source Loopback0  neighbor 1.1.1.1 capability orf prefix-list both

2-b) debug R2 outbound

R2:

R2# *Mar  1 00:48:47.367: BGP(0): 1.1.1.1 send UPDATE (format) 20.20.10.0/24, next 2.2.2.2, metric 0, path Local

Note that R2 sent only prefixes allowed in the filter received from R1.

2-c) debug R1 outbound

R1:

R1# *Mar  1 00:48:47.755: BGP(0): 2.2.2.2 rcvd UPDATE w/ attr: nexthop 2.2.2.2, origin i, metric 0, path 65501 *Mar  1 00:48:47.755: BGP(0): 2.2.2.2 rcvd 20.20.10.0/24 *Mar  1 00:48:47.363: BGP(0): Revise route installing 1 of 1 routes for 20.20.10.0/24 -> 2.2.2.2(main) to main IP table

Note that R1 did not received 20.20.20.0/24 at all.

 

Tags: BGP

MED attribute and “hot potato” routing

The purpose of this post is to demonstrates how to use the BGP Best path selection algorithm and manipulate BGP attribute MED (Multi-Exit Discriminator) in the outgoing advertisement traffic to influence the inbound traffic.

Let’s consider the topology depicted in Figure1 under the following conditions:

 -Router R7 is the route reflector and R6 and R5 route reflector clients.

- A full mesh iBGP is deployed inside AS65500 between BGP routers R1, R2, R3 and R4.

- Default EIGRP links costs are considered between routers.

- For internal connectivity EIGRP 1234 is the IGP for 65500 and EIGRP 567 is the IGP for 65501.

Figure 1: Lab topology

 

the network 192.168.10.0/24 is reachable from R7 through 2 paths:

R7:

R7#sh ip bgp 192.168.10.0 BGP routing table entry for 192.168.10.0/24, version 4 Paths: (2 available, best #2, table Default-IP-Routing-Table) Flag: 0×800   Advertised to update-groups:      1   65500, (Received from a RR-client)     6.6.6.6 (metric 2297856) from 6.6.6.6 (6.6.6.6)       Origin IGP, metric 0, localpref 100, valid, internal   65500, (Received from a RR-client)     5.5.5.5 (metric 2297856) from 5.5.5.5 (5.5.5.5)       Origin IGP, metric 0, localpref 100, valid, internal, best R7#

Table1: R7 best path selection for 192.168.10.0/24

	Attribute	Path1	Path2
1	weight	0	0
2	local preference	100	100
3	originated locally	No	No
4	AS_PATH	65500	65500
5	ORIGIN	i	i
6	MED	0	0
7	eBGP<>iBGP	iBGP	iBGP
8	Best IGP metric to NEXT-HOP	2297856	2297856
9	Multipath	No	No
10	oldest path	No	No
11	Lowest neighbor router-ID	6.6.6.6	5.5.5.5  <<<

The best route chosen is the route through R5 because of the last criteria (figure2).

R7(config)#do traceroute 192.168.10.1 source 192.168.70.1   Type escape sequence to abort. Tracing the route to 192.168.10.1     1 192.168.57.1 92 msec 44 msec 160 msec   2 192.168.45.1 256 msec 72 msec 96 msec   3 192.168.14.1 136 msec *  280 msec R7(config)#

Figure2: paths to 192.168.10.0/24 from R7

In the other side, network 192.168.70.0/24 (AS 65501) is reachable from R1 (AS 65500) through 2 paths (figure3):

R1:

R1#sh ip bgp BGP table version is 16, local router ID is 192.168.10.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 *> 192.168.10.0     0.0.0.0                  0         32768 i * i192.168.70.0     4.4.4.4                  0    100      0 65501 i *>i                 3.3.3.3                  0    100      0 65501 i R1#sh ip bgp 192.168.70.0 BGP routing table entry for 192.168.70.0/24, version 16 Paths: (2 available, best #2, table Default-IP-Routing-Table) Flag: 0×900   Not advertised to any peer   65501     4.4.4.4 (metric 5639936) from 4.4.4.4 (4.4.4.4)       Origin IGP, metric 0, localpref 100, valid, internal   65501     3.3.3.3 (metric 2809856) from 2.2.2.2 (2.2.2.2)       Origin IGP, metric 0, localpref 100, valid, internal, best       Originator: 3.3.3.3, Cluster list: 2.2.2.2 R1#

Table2: R1 best path selection for 192.168.70.0/24

	Attribute	Path1	Path2
1	weight	0	0
2	local preference	100	100
3	originated locally	No	No
4	AS_PATH	65501	65501
5	ORIGIN	i	I
6	MED	0	0
7	eBGP<>iBGP	iBGP	iBGP
8	Best IGP metric to NEXT-HOP	5639936	2809856 <<<
9	Multipath	No	No
10	oldest path	No	No
11	Lowest neighbor router-ID	2.2.2.2	4.4.4.4

 

Links between R1-R2 and R2-R3 are 2mpbs whereas R1 and R4 are connected through a 512kbps link, therefore the  tie breaker in the best path selection algorithm was the IGP metric to NEXT-HOP and below attributes are not considered.               

figure3: paths to 192.168.70.0/24 from R1

 

 

R1#traceroute 192.168.70.1 source 192.168.10.1   Type escape sequence to abort. Tracing the route to 192.168.70.1     1 192.168.12.2 84 msec 72 msec 96 msec   2 192.168.23.2 104 msec 76 msec 40 msec   3 192.168.36.2 308 msec 184 msec 184 msec   4 192.168.67.2 208 msec *  144 msec R1#

This type of routing is called “hot potato” or “Early exit” routing, because BGP choose the shortest path to transit traffic through the AS.

Hot potato routing can cause asymmetric routing between the source and the destination (figure4).

Figure4: Asymmetric routing

In case AS 65501 need to send and receive traffic between 192.168.10.0/24 and 192.168.70.0 through R5-R4, we have to manipulate more preferable criteria than IGP metric to NEXT-HOP, MED (Multi Exit Discriminator) for example.

In this case one service provider AS 65501 can SUGGEST to the other to take into account MED criterion so the  incoming and the outgoing traffic take the same path, which is a less common practice, this will certainly depend on the policies and negotiations, because each provider goal is to control how traffic enter and exit its AS according to its own needs not other providers needs.

The MED (Multi-Exit-Discriminator) is :

- optional non-transitive attribute.

- an INDICATION, SUGGESTION or a HINT to the neighbor AS about the preferred path for a particular incoming traffic, which is complying with the nature of AUTONOMOUS systems.

- used with dual-homed connections to the same neighbor AS.

Let’s suppose AS65500 will accept to take into account the criterion MED from eBGP peers from 65501 for the prefix 192.168.70.0/24, both border routers R5 and R6 will advertise the internal prefix 192.168.70.0/24 with different MED values (the lowest is the preferred).

R5:

ip prefix-list 70_plist seq 5 permit 192.168.70.0/24   route-map Low_MED_45_pmap permit 10  match ip address prefix-list 70_plist  set metric 10   router bgp 65501  neighbor 4.4.4.4 route-map Low_MED_45_pmap out

 

R5#clear ip bgp 4.4.4.4 soft out

R6:

ip prefix-list 70_plist seq 5 permit 192.168.70.0/24   route-map High_MED_36_pmap permit 10  match ip address prefix-list 70_plist  set metric 100   router bgp 65501  neighbor 3.3.3.3 route-map High_MED_36_pmap out

 

R6#clear ip bgp 3.3.3.3 soft out

R4 and R3 has received updates for the prefix 172.168.70.0/24 respectively from R5 and R6 with the different MED which is transmitted further throughout AS 56500 as you can see from R1 routing table:

R1:

R1#sh ip bgp BGP table version is 21, local router ID is 192.168.10.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 *> 192.168.10.0     0.0.0.0                  0         32768 i *>i192.168.70.0     4.4.4.4                 10    100      0 65501 i * i                 3.3.3.3                100    100      0 65501 i R1#

 

R1#sh ip bgp 192.168.70.0 BGP routing table entry for 192.168.70.0/24, version 21 Paths: (2 available, best #1, table Default-IP-Routing-Table) Flag: 0×920   Not advertised to any peer   65501     4.4.4.4 (metric 5639936) from 4.4.4.4 (4.4.4.4)       Origin IGP, metric 10, localpref 100, valid, internal, best   65501     3.3.3.3 (metric 2809856) from 2.2.2.2 (2.2.2.2)       Origin IGP, metric 100, localpref 100, valid, internal       Originator: 3.3.3.3, Cluster list: 2.2.2.2 R1#

 

R1#traceroute 192.168.70.1 source 192.168.10.1   Type escape sequence to abort. Tracing the route to 192.168.70.1     1 192.168.14.2 56 msec 92 msec 64 msec   2 192.168.45.2 108 msec 100 msec 64 msec   3 192.168.57.2 240 msec *  180 msec R1#

The tie is broken by MED value before reaching the criterion “shortest IGP cost to NEXT-HOP”

Table3: R1 best path selection for 192.168.70.0/24

	Attribute	Path1	Path2
1	Weight	0	0
2	local preference	100	100
3	originated locally	No	No
4	AS_PATH	65501	65501
5	ORIGIN	i	I
6	MED	10 <<<	100
7	eBGP<>iBGP	iBGP	iBGP
8	Best IGP metric to NEXT-HOP	5639936	2809856
9	Multipath	No	No
10	oldest path	No	No
11	Lowest neighbor router-ID	2.2.2.2	4.4.4.4

 

Figure5: symmetric routing

Conclusion:

If your policy doesn’t take into account MED, make sure to explicitly reset it for prefixes received from you multi-homed connection with your peer AS.

Tags: BGP

BGP best path selection

The complexity as well as the efficiency of BGP resides in the concept of “attributes” of routes and the way the protocol juggles them to determine the best path, therefore the need for a “quick guide”  to use when dealing with BGP design. I hope the following BGP best path selection diagram will be of help:

Download the pdf version here

BGP for large scale networks

OVERVIEW

All along this lab we will try to practice BGP deployment and focus on main concepts behind inter-autonomous system communications as well as methods used to provide scalability for large networks like service providers.

Figure1: topology

Figure 1 depicts the BGP topology needed to be deployed as well as future deployment and expansion inside some autonomous systems.

PLANNING

Let’s Suppose that ASN 12345 was assigned the range 192.168.4.0/23 and ASN 11897 192.168.6.0/23 from which an address scheme will be planned, the upcoming table details the address scheme calculation and assignment.

Table1: ASN12345 address scheme

networks advertised by BGP 192.168.4.0/23
1100 0000.1010 1000.0000 0100.0000 0000	3 bits are taken for 6 subnets (23-2=6)
1100 0000.1010 1000.0000 0100.0000 0000	zero subnet – 192.168.4.0/26			(not used)
1100 0000.1010 1000.0000 0100.0100 0000	1st subnet – 192.168.4.64/26
1100 0000.1010 1000.0000 0101.1000 0000	penultimate subnet – 192.168.5.128/26
1100 0000.1010 1000.0000 0101.1100 0000	Last subnet – 192.168.5.192/26			(used for PTP segments)
PTP segments 192.168.5.192/30
1100 0000.1010 1000.0000 0101.1100 0000	4 bits are taken for 6 subnets (24-2=14)
1100 0000.1010 1000.0000 0101.1100 0000	zero subnet – 192.168.5.192/30			(not used)
1100 0000.1010 1000.0000 0101.1100 0100	1st subnet – 192.168.5.196/30
1100 0000.1010 1000.0000 0101.1111 1000	penultimate subnet – 192.168.5.184/30
1100 0000.1010 1000.0000 0101.1111 1100	last subnet – 192.168.5.252/30
IP address assignment
Networks advertised by BGP		POINT-TO-POINT interconnections Segments
		Segment	Devices
192.168.4.64/26		192.168.5.196/30	R1-R5
192.168.4.192/26		192.168.5.200/30	R4-R5
192.168.5.0/26		192.168.5.204/30	R1-R3
192.168.5.64/26		192.168.5.208/30	R1-R2
192.168.5.128/26		192.168.5.212/30	R3-R7(ASN27000)

 

Table2 : ASN11897 address scheme

networks advertised by BGP 192.168.6.0/23
1100 0000.1010 1000.0000 0110.0000 0000	4 bits are taken for 14 subnets (24-2=14)
1100 0000.1010 1000.0000 0110.0000 0000	zero subnet – 192.168.6.0/27			(not used)
1100 0000.1010 1000.0000 0110.0010 0000	1st subnet – 192.168.6.32/27
1100 0000.1010 1000.0000 0111.1100 0000	penultimate subnet – 192.168.5.128/27
1100 0000.1010 1000.0000 0111.1110 0000	Last subnet – 192.168.6.224/27			(used for PTP segments)
PTP segments 192.168.6.224/30
1100 0000.1010 1000.0000 0111.1110 0000	3 bits are taken for 6 subnets (23-2=6)
1100 0000.1010 1000.0000 0111.1110 0000	zero subnet – 192.168.6.224/30			(not used)
1100 0000.1010 1000.0000 0111.1110 0100	1st subnet – 192.168.6.228/30
1100 0000.1010 1000.0000 0111.1111 1000	penultimate subnet – 192.168.6.248/30
1100 0000.1010 1000.0000 0111.1111 1100	last subnet – 192.168.6.252/30			(not used)
IP address assignment
Networks advertised by BGP		POINT-TO-POINT interconnections Segments
		Segment	Devices
192.168.6.32/27 advertized by R9		192.168.6.228/30	R12-R9
192.168.6.64/27 advertized by R10		192.168.6.232/30	R8-R9
192.168.6.96/27 advertized by R11		192.168.6.236/30	R12-R10
192.168.6.128/27 advertized by R8		192.168.6.240/30	R12-R11
192.168.6.160/27 advertized by R12		192.168.6.244/30	R8-R10
		192.168.6.248/30	R8-R11

 

Table3 : InterAS address scheme

PTP segments 192.168.11.0/24
1100 0000.1010 1000.0000 1011.1100 0000	6 bits are taken for 62 subnets (26-2=62)
1100 0000.1010 1000.0000 1011.1100 0000	zero subnet – 192.168.11.192/30			(not used)
1100 0000.1010 1000.0000 1011.1100 0100	1st subnet – 192.168.11.196/30
1100 0000.1010 1000.0000 1011.1111 1000	penultimate subnet – 192.168.11.249/30
1100 0000.1010 1000.0000 0111.1111 1100	last subnet – 192.168.11.252/30
IP address assignment
Networks advertised by BGP		POINT-TO-POINT interconnections Segments
		Segment	Devices
-		192.168.11.196/30	R6(ASN26000)-R5(ASN12345)
-		192.168.11.200/30	R12(ASN11897)-R5(ASN12345)
-		192.168.11.204/30	R8(ASN11897)-R5(ASN12345)
-		192.168.11.208/30	R8(ASN11897)-R12(ASN11897)

 

- ASN 27000 contains only router R7 which advertize network 192.168.8.64/26 and connects to R3 (ASN12345) through 192.168.5.212/30.

- ASN 26000 contains only router R6 which advertize network 192.168.0.0/24 and connects to R5 (ASN12345) through 192.168.11.196/30.

Figure2 :address scheme

 

ANALYSIS

The first part of the lab concerns the configuration of confederations inside AS12345 also interactions with AS27000 and AS26000.

The second part focuses on configuration of route reflector, inside AS11897, with redundancy.

1. Part I:
   

Before continuing, here is some concepts around “confederations” to which we will refer as we moves through the configuration:

• c1- inside confederation full iBGP is required.
  
• c2- confederation AS-PATH is used to prevent loops between confederations.
  
• c3- eBGP is needed between confederations (as between AS) and the default TTL=1 therefore we need to consider increasing TTL is loopback interfaces are used to refer to BGP peers.
  
• c4- Not like between AS’s, between sub-AS’s (confederations) the attribute NEXT-HOP is not changed by default.
  
• c5- When choosing best routes according to As-PATH attribute confederation AN are not considered.
  

Let’s proceed with the configuration of confederation CONFED ASN 65000 (note that confederation/ private AS numbers are from the range 64512-65535) on R1:

R1(config)#router bgp 65000

R1(config-router)#bgp router-id 10.10.1.1

R1(config-router)#bgp confederation identifier 12345

R1(config-router)#bgp confederation peers 65001

 

R5(config)#router bgp 65001

R5(config-router)#bgp router-id 10.10.5.1

R5(config-router)#bgp confederation identifier 12345

R5(config-router)#bgp confederation peers 65000

BGP confederation deployment requires the cut of the entire configuration inside AS, this means that if you have any previous BGP configuration you have to start by performing

Router(config-router)#no router bgp

Hence, a best practice is to plan and start with confederations to prepare for future expansion.

eBGP neighboring between R1 (CONCFED ASN65000) and R5 (CONFED ASN65001)

R5(config-router)#neighbor 10.10.1.1 remote-as 65000

R5(config-router)#neighbor 10.10.1.1 ebgp-multihop 2

R5(config-router)#neighbor 10.10.1.1 update-source Loopback0

R5(config-router)#neighbor 10.10.1.1 next-hop-self

 

R1(config-router)#neighbor 10.10.5.1 remote-as 65001

R1(config-router)#neighbor 10.10.5.1 ebgp-multihop 2

R1(config-router)#neighbor 10.10.5.1 update-source loo 0

R1(config-router)#neighbor 10.10.5.1 next-hop-self

Note that R1 and R5 change NEXT-HOP attribute so learned routes between the two confederations become reachable and can be included in routing tables, as a matter of fact in this point two possible methods for IGP routing appear:

• The first is to separate routing between CONFED ASN65000 and CONFED ASN65001 and then NEXT-HOP attribute must be changed.
• The second is to have a unique IGP (remember that inside AS IGP are used only to provide connectivity between routers for BGP routing).
  • A flat addressing protocol like RIPv2 or EIGRP.
  • OSPF protocol with each confederation considered as an area apart and the link between R1-R5 ,or any other future routers (figure3), is the backbone network. In this particular case, many options are available for area type, stubby, totally stubby or Not-So-Stubby.

Figure3: OSPF topology

R1(config-router)#router-id 10.10.1.1

R1(config-router)#area 23 stub no-summary

R1(config-router)#network 10.10.1.1 0.0.0.0 area 0

R1(config-router)#network 192.168.5.196 0.0.0.3 area 0

R1(config-router)#network 192.168.5.204 0.0.0.3 area 23

R1(config-router)#network 192.168.5.208 0.0.0.3 area 23

 

R2(config-router)#router-id 10.10.2.1

R2(config-router)#area 23 stub no-summary

R2(config-router)#network 10.10.0.0 0.0.0.255 area 23

R2(config-router)#network 192.168.5.208 0.0.0.3 area 23

 

R3(config-router)#router-id 10.10.3.1

R3(config-router)#area 23 stub no-summary

R3(config-router)#network 192.168.5.204 0.0.0.3 area 23

R3(config-router)#network 192.168.5.212 0.0.0.3 area 23

Note that OSPF area 23 is a totally stubby area this means that it doesn’t allow LSA3 (summary from other areas), LSA5 external routes from external domains (AS27000 in occurrence) and doesn’t allow ASBR routers (no LSA7).

including the external link 192.168.5.212 in the inside OSPF network allow routes received from ASN27000 to be included in the ASN12345 with a reachable NEXT-HOP attribute. Another option is to exclude this network from OSPF and change NEXT-HOP for the eBGP session from R7.

R5(config-router)#router-id 10.10.5.1

R5(config-router)#area 45 stub no-summary

R5(config-router)#network 10.10.5.1 0.0.0.0 area 0

R5(config-router)#network 192.168.5.196 0.0.0.3 area 0

R5(config-router)#network 192.168.5.200 0.0.0.3 area 45

It’s important for both R1 an R5 to announce respectively 10.10.1.1 and 10.10.5.1 through OSPF, for BGP-RID to be reachable to each other.

R4(config-router)#router-id 10.10.4.1

R4(config-router)#area 45 stub no-summary

R4(config-router)#network 192.168.5.200 0.0.0.3 area 45

with such configuration there is no need to change NEXT-HOP attribute for R1

R1(config-router)#no neighbor 10.10.5.1 next-hop-self

It is possible to perform the following command on R5:

R5(config-router)#no neighbor 10.10.1.1 next-hop-self

But we will have to include external links into OSPF network for external routes NEXT-HOP attribute to be available, and for security reason make those interfaces passive for OSPF. To avoid any additional complexity we will keep:

R5(config-router)#neighbor 10.10.1.1 next-hop-self

Inside the confederation ASN 65000 a iBGP full mesh is required between R1, R2 and R1, this is the split horizon rule that states that routes received from an iBGP neighbor will not be sent to another iBGP neighbor because all routers are supposed to be fully meshed.

R2(config-router)#neighbor 192.168.5.209 remote-as 65000

R2(config-router)#neighbor 192.168.5.205 remote-as 65000

 

R3(config-router)#neighbor 192.168.5.206 remote-as 65000

R3(config-router)#neighbor 192.168.5.210 remote-as 65000

 

R1(config-router)#neighbor 192.168.5.210 remote-as 65000

R1(config-router)#neighbor 192.168.5.205 remote-as 65000

Between R7(ASN27000) and R3(ASN26000) no routing is needed because default NEXT-HOP attributes of received routes are directly reachable, and R7 ip address is known to R3 because was included in OSPF.

The same method like the one deployed between R5(ASN12345) and R6(ASN26000), a default route from R6 that points to R5 and static route from R5 for the BGP RID ip 10.10.6.1 that points to 192.168.11.198

R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.11.197

R5(config)#ip route 10.10.6.1 255.255.255.255 192.168.11.198

Here a test of connectivity between R7(ASN27000) and R6(ASN26000)

R7#sh ip route

…

192.168.8.0/26 is subnetted, 1 subnets

C 192.168.8.64 is directly connected, Loopback1

192.168.4.0/26 is subnetted, 2 subnets

B 192.168.4.64 [20/0] via 192.168.5.214, 00:38:05

B 192.168.4.192 [20/0] via 192.168.5.214, 03:40:28

192.168.5.0/24 is variably subnetted, 3 subnets, 2 masks

B 192.168.5.64/26 [20/0] via 192.168.5.214, 00:56:23

B 192.168.5.0/26 [20/0] via 192.168.5.214, 00:56:23

C 192.168.5.212/30 is directly connected, Serial1/0

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

B 10.10.0.0/24 [20/0] via 192.168.5.214, 00:21:39

C 10.10.7.1/32 is directly connected, Loopback0

B 192.168.0.0/24 [20/0] via 192.168.5.214, 00:40:29

R7#

R6:

R6#sh ip route

…

192.168.8.0/26 is subnetted, 1 subnets

B 192.168.8.64 [20/0] via 10.10.5.1, 00:57:08

192.168.11.0/30 is subnetted, 1 subnets

C 192.168.11.196 is directly connected, Ethernet0/0

192.168.4.0/26 is subnetted, 2 subnets

B 192.168.4.64 [20/0] via 10.10.5.1, 00:38:49

B 192.168.4.192 [20/0] via 10.10.5.1, 00:57:08

192.168.5.0/26 is subnetted, 2 subnets

B 192.168.5.64 [20/0] via 10.10.5.1, 04:24:17

B 192.168.5.0 [20/0] via 10.10.5.1, 01:56:53

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

B 10.10.0.0/24 [20/0] via 10.10.5.1, 00:22:23

C 10.10.6.1/32 is directly connected, Loopback0

C 192.168.0.0/24 is directly connected, FastEthernet1/0

S* 0.0.0.0/0 [1/0] via 192.168.11.197

R6#

 

R7#trace

Protocol [ip]:

Target IP address: 192.168.0.1

Source address: 192.168.8.66

Numeric display [n]:

Timeout in seconds [3]:

Probe count [3]:

Minimum Time to Live [1]:

Maximum Time to Live [30]:

Port Number [33434]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Type escape sequence to abort.

Tracing the route to 192.168.0.1

 

1 192.168.5.214 152 msec 120 msec 108 msec

2 192.168.5.206 252 msec 212 msec 392 msec

3 192.168.5.197 664 msec 408 msec 420 msec

4 192.168.11.198 560 msec 560 msec 772 msec

5 192.168.0.1 [AS 26000] 616 msec 652 msec 700 msec

R7#

 

1. Part II:
   

During the second part we will focus on Route Reflectors deployment and their benefits.

RR is a method of managing expanding mesh topology in large autonomous systems by selecting particular routers as focal points of iBGP.

SPLIT HORIZON rule:

Learned routes from iBGP neighbors will never be sent to another iBGP neighbor, because it is supposed to be a full mesh iBGP.

With n=10 routers, the number of iBGP sessions needed is n*(n-1)/2 = 45 iBGP sessions and with 100 routers (generally service providers) 100*99/2=4950 iBGP sessions in each routers!!!!

Route Reflector will break the law of split horizon and allow a particular router to sent received prefixes from one iBGP neighbor to another, this will significantly lessen the number of iBGP sessions the client is required to maintain and a route reflector processes once UPDATE messages for all peers rather than n times for each peer.

All other client that will be served by the RR are called “clients”, certainly the physical topology must follow the logic one (Figure4 with and without RR physic connectivity).

Figure4 RR physic connectivity:

A “cluster” is called a RR with its clients and a “non-client” is a peer of RR that doesn’t belong to the cluster.

Here is some benefits of route reflector:

- No need for full mesh iBGP;

- Route propagation.

- Neighbor relationship reduced.

- Possible RR (redundancy) deployment.

- RR redundancy should be complementary with physical redundancy.

- Minimal configuration (only on RR clients are assigned).

Special attributes are affected with RR deployments:

- CLUSTER_ID: by default set to RR BGP RID

- CLUSTER_LIST: the RR add the CLUSTER_ID to CLUSTER_LIST before sending update, further RR discard any received prefixes with its own CLUSTER_ID in CLUSTER_LIST.

- ORIGINATOR_ID: The first iBGP BGP RID peer to advertize the route into the AS, an entry point to an AS, for a route will never be its exit point from the AS.

It’s recommended for the RR to have more resources for managing iBGP sessions with clients consequently choose a client (with less resources consumed) for handling eBGP connections.

R5 is connected to both R12 and R8 through eBGP using loopback interfaces so we decided to deploy EIGRP between ASN12345 and ASN11897 to prepare for further addition of other autonomous systems:

R12(config-router)#router eigrp 1258

R12(config-router)#no auto

R12(config-router)#net 192.168.11.200 0.0.0.3

R12(config-router)#net 10.10.12.1 0.0.0.0

R12(config-router)#

*Mar 1 07:22:42.654: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1258: Neighbor 192.168.11.202 (Serial1/0) is up: new adjacency

*Mar 1 07:24:59.042: %BGP-5-ADJCHANGE: neighbor 10.10.5.1 Up

 

R8(config-router)#router eigrp 1258

R8(config-router)#no auto

R8(config-router)#net 192.168.11.204 0.0.0.3

R8(config-router)#net 10.10.8.1 0.0.0.0

R8(config-router)#

*Mar 1 07:28:26.014: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1258: Neighbor 192.168.11.206 (Serial1/0) is up: new adjacency

*Mar 1 07:30:13.806: %BGP-5-ADJCHANGE: neighbor 10.10.5.1 Up

 

R5(config-router)#router eigrp 1258

R5(config-router)#no auto

R5(config-router)#net 192.168.11.200 0.0.0.3

R5(config-router)#net 192.168.11.204 0.0.0.3

R5(config-router)#net 10.10.5.1 0.0.0.0

*Mar 1 06:42:38.886: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1258: Neighbor 192.168.11.201 (Serial1/2) is up: new adjacency

*Mar 1 06:42:52.198: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1258: Neighbor 192.168.11.205 (Serial1/3) is up: new adjacency

*Mar 1 06:44:10.098: %BGP-5-ADJCHANGE: neighbor 10.10.8.1 Up

*Mar 1 06:44:24.130: %BGP-5-ADJCHANGE: neighbor 10.10.12.1 Up

According to the physical topology both R12 and R8 can be RR one primary and secondary so each one of them will establish an iBGP neighbor relationship with clients R9, R10 and R11 and if one RR have problem connecting to particular client it still have the possibility to reach it through the second RR through the second client interface, hence the use of loopback interfaces with “neighbor” command.

Figure5: (ASN11897 IGP)

For iBGP reachability we will deploy EIGRP with asn198 (figure5) for inside hosts as follow:

R8:

router eigrp 198

passive-interface Serial1/0

network 10.10.8.1 0.0.0.0

network 192.168.6.232 0.0.0.3

network 192.168.6.244 0.0.0.3

network 192.168.6.248 0.0.0.3

network 192.168.11.208 0.0.0.3

no auto-summary

R12:

router eigrp 198

passive-interface Serial1/0

network 10.10.12.1 0.0.0.0

network 192.168.6.228 0.0.0.3

network 192.168.6.236 0.0.0.3

network 192.168.6.240 0.0.0.3

network 192.168.11.208 0.0.0.3

no auto-summary

R9:

router bgp 11897

no synchronization

bgp log-neighbor-changes

network 192.168.6.32 mask 255.255.255.224

neighbor 10.10.8.1 remote-as 11897

neighbor 10.10.8.1 update-source Loopback0

neighbor 10.10.12.1 remote-as 11897

neighbor 10.10.12.1 update-source Loopback0

no auto-summary

R10:

router eigrp 198

network 10.10.10.1 0.0.0.0

network 192.168.6.236 0.0.0.3

network 192.168.6.244 0.0.0.3

no auto-summary

R11:

router eigrp 198

network 10.10.11.1 0.0.0.0

network 192.168.6.240 0.0.0.3

network 192.168.6.248 0.0.0.3

no auto-summary

Let’s take a look over the bgp table of one of RR client, R11 for instance:

R11#sh ip bgp

BGP table version is 5, local router ID is 10.10.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

* i192.168.0.0 10.10.5.1 0 100 0 12345 26000 i

* i 10.10.5.1 0 100 0 12345 26000 i

* i192.168.4.64/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

* i192.168.4.192/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

* i192.168.5.0/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

* i192.168.5.64/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

* i192.168.6.32/27 10.10.9.1 0 100 0 i

*>i 10.10.9.1 0 100 0 i

*>i192.168.6.128/27 10.10.8.1 0 100 0 i

* i 10.10.8.1 0 100 0 i

* i192.168.6.160/27 10.10.12.1 0 100 0 i

*>i 10.10.12.1 0 100 0 i

* i192.168.8.64/26 10.10.5.1 0 100 0 12345 27000 i

* i 10.10.5.1 0 100 0 12345 27000 i

R11#

The only prefixes marked as “best” are those with NEXT-HOP attributes included in the routing table, like 10.10.12.1, 10.10.9.1 and 10.10.8.1, BUT not those with NEXT-HOP=10.10.5.1 because there is no route to such ip in the routing table:

R11# sh ip route

…

192.168.11.0/30 is subnetted, 1 subnets

D 192.168.11.208 [90/2172416] via 192.168.6.250, 00:47:16, Serial1/0

[90/2172416] via 192.168.6.242, 00:47:16, Serial1/1

10.0.0.0/32 is subnetted, 5 subnets

D 10.10.9.1 [90/2809856] via 192.168.6.250, 00:56:26, Serial1/0

[90/2809856] via 192.168.6.242, 00:56:26, Serial1/1

D 10.10.8.1 [90/2297856] via 192.168.6.250, 00:47:13, Serial1/0

C 10.10.11.1 is directly connected, Loopback0

D 10.10.10.1 [90/2809856] via 192.168.6.250, 00:54:01, Serial1/0

[90/2809856] via 192.168.6.242, 00:54:01, Serial1/1

D 10.10.12.1 [90/2297856] via 192.168.6.242, 00:47:13, Serial1/1

192.168.6.0/24 is variably subnetted, 10 subnets, 2 masks

C 192.168.6.96/27 is directly connected, Loopback1

B 192.168.6.32/27 [200/0] via 10.10.9.1, 00:11:40

D 192.168.6.236/30 [90/2681856] via 192.168.6.242, 00:47:14, Serial1/1

D 192.168.6.232/30 [90/2681856] via 192.168.6.250, 00:47:14, Serial1/0

D 192.168.6.228/30 [90/2681856] via 192.168.6.242, 00:47:14, Serial1/1

C 192.168.6.248/30 is directly connected, Serial1/0

D 192.168.6.244/30 [90/2681856] via 192.168.6.250, 00:47:14, Serial1/0

C 192.168.6.240/30 is directly connected, Serial1/1

B 192.168.6.160/27 [200/0] via 10.10.12.1, 00:26:39

B 192.168.6.128/27 [200/0] via 10.10.8.1, 00:25:56

R11#

ip address 10.10.5.1 belongs to the peer ASN12345, so we can:

• a)- Use floating static routes at RR clients that point to eBGP speakers R12 and R8 primary and secondary (different administrative distances), we can use default routes to R12 and R8, the unique exit and entry points to AS11897, this is a not scalable solution.
• b)- inject by redistribution the route to the RID of the eBGP peer R5 from R12 and R8 RIGRP 1285 routing table into EIGRP 198 routing table, this is not scalable as we will have to do that with every new AS neighbor which make this solution prone to errors.
• c)- Change NEXT-HOP attribute on eBGP speakers R12 and R8, the easiest and th most scalable solution.

Let’s try all of those solutions:

Solution (a):

R11(config)#ip route 0.0.0.0 0.0.0.0 10.10.12.1 5

R11(config)#ip route 0.0.0.0 0.0.0.0 10.10.8.1 10

 

R9(config)#ip route 0.0.0.0 0.0.0.0 192.168.6.230 5

R9(config)#ip route 0.0.0.0 0.0.0.0 192.168.6.234 10

 

R10(config)#ip route 0.0.0.0 0.0.0.0 192.168.6.238 5

R10(config)#ip route 0.0.0.0 0.0.0.0 192.168.6.246 10

 

R11(config)#ip route 0.0.0.0 0.0.0.0 192.168.6.242 5

R11(config)#ip route 0.0.0.0 0.0.0.0 192.168.6.250 10

R12 will be the primary choice and in case of a failure the second route will be considered.

From R11:

R11(config)#do sh ip bgp

BGP table version is 24, local router ID is 10.10.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

* i10.10.0.0/24 10.10.5.1 0 100 0 12345 i

*>i 10.10.5.1 0 100 0 12345 i

*>i192.168.0.0 10.10.5.1 0 100 0 12345 26000 i

* i 10.10.5.1 0 100 0 12345 26000 i

*>i192.168.4.64/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

*>i192.168.4.192/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

*>i192.168.5.0/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

*>i192.168.5.64/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

* i192.168.6.32/27 10.10.9.1 0 100 0 i

*>i 10.10.9.1 0 100 0 i

*>i192.168.6.64/27 10.10.10.1 0 100 0 i

* i 10.10.10.1 0 100 0 i

*> 192.168.6.96/27 0.0.0.0 0 32768 i

Network Next Hop Metric LocPrf Weight Path

*>i192.168.6.128/27 10.10.8.1 0 100 0 i

* i 10.10.8.1 0 100 0 i

* i192.168.6.160/27 10.10.12.1 0 100 0 i

*>i 10.10.12.1 0 100 0 i

* i192.168.8.64/26 10.10.5.1 0 100 0 12345 27000 i

*>i 10.10.5.1 0 100 0 12345 27000 i

R11(config)#

Now all networks seem to be are available and reachable and this is confirmed by the result of “trace” command:

R11(config)#do trace

Protocol [ip]:

Target IP address: 192.168.8.65

Source address: 192.168.6.97

Numeric display [n]:

Timeout in seconds [3]:

Probe count [3]:

Minimum Time to Live [1]:

Maximum Time to Live [30]:

Port Number [33434]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Type escape sequence to abort.

Tracing the route to 192.168.8.65

 

1 192.168.6.242 72 msec 120 msec 48 msec

2 192.168.11.202 292 msec 504 msec 324 msec

3 192.168.5.198 516 msec 404 msec 812 msec

4 192.168.5.205 560 msec 492 msec 588 msec

5 192.168.5.213 864 msec 924 msec 564 msec

R11(config)#

the path taken by tICMP traffic is R12->R5->R1->R3->R7

Solution (b):

Before continuing let’s revoke changes concerning the solution (a):

 

R9(config)#no ip route 0.0.0.0 0.0.0.0 192.168.6.230 5

R9(config)#no ip route 0.0.0.0 0.0.0.0 192.168.6.234 10

 

R10(config)#no ip route 0.0.0.0 0.0.0.0 192.168.6.238 5

R10(config)#no ip route 0.0.0.0 0.0.0.0 192.168.6.246 10

 

R11(config)#no ip route 0.0.0.0 0.0.0.0 192.168.6.242 5

R11(config)#no ip route 0.0.0.0 0.0.0.0 192.168.6.250 10

 

R11(config)#do sh ip route 10.10.5.1

% Subnet not in table

R11(config)#

 

R8#sh ip route 10.10.5.1

Routing entry for 10.10.5.1/32

Known via “eigrp 1258″, distance 90, metric 2297856, type internal

Redistributing via eigrp 1258

Last update from 192.168.11.206 on Serial1/0, 03:21:56 ago

Routing Descriptor Blocks:

* 192.168.11.206, from 192.168.11.206, 03:21:56 ago, via Serial1/0

Route metric is 2297856, traffic share count is 1

Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

 

R8#

EIGRP 1258 routing table is distinct from EIGRP 198 (figure5) that’s why R8 and R12 know about 10.10.5.1 but nor R9, R10 and R11.

This is the routing table of R11 before redistribution:

R11(config)#do sh ip bgp

BGP table version is 31, local router ID is 10.10.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

* i10.10.0.0/24 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

* i192.168.0.0 10.10.5.1 0 100 0 12345 26000 i

* i 10.10.5.1 0 100 0 12345 26000 i

* i192.168.4.64/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

* i192.168.4.192/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i

* i192.168.5.0/26 10.10.5.1 0 100 0 12345 i

* i 10.10.5.1 0 100 0 12345 i