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: 0x800

  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.

Advertisements

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:0x22, Inherited polices:0x0

 *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:0x88, Inherited polices:0x22

This template inherits:

  Common_Session_Config index:1 flags:0x0

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:0x480, Inherited polices:0x0

Locally configured policies:

  prefix-list NOTHING_plist out

  default-originate route-map none

Inherited policies:

 

Template:Common_Policy_Config, index:1.

Local policies:0x80004, Inherited polices:0x0

 *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:0x408, Inherited polices:0x80004

This template inherits:

  Common_Policy_Config, index:1, seq_no:10, flags:0x408

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:0x2, Inherited polices:0x80004

This template inherits:

  Common_Policy_Config, index:1, seq_no:10, flags:0x2

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

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: 0x0) 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: 0x820) 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:
%d bloggers like this: