Search This Blog

Saturday, February 5, 2011

BGP Route influence through extended communities

Having the following scenario:

The Customer network is multiple single-homed to ISP AS10, while advertising networks 192.168.10-30.0/24 to the ISP and the ISP is advertising networks 200.0.10-30.0/24 to the customer. No default route is configured to any direction.

On the ISP network:

  • All PtP addresses and Lo0 are advertised using OSPF area 0, only Lo1 to 3 from ISP router are advertised using BGP
  • Core1 and Core2 are acting as route-reflectors to PE1, PE2 and ISP
  • PE1 and PE2 configured with next-hop-self to Core1 and Core2
  • All router-ids are configured using Lo0 interface as followed:

    PE1 – 10.255.255.1

    PE2 – 10.255.255.2

    CORE1 – 10.255.255.3

    CORE2 – 10.255.255.4

    ISP – 10.255.255.5

On Customer network:

  • Network 10.0.0.0/24 and Lo0 are advertised through OSPF are 0, only networks 192.168.10-20.0/24 are advertised using BGP
  • CE1, CE2 and CE_LAN are all configured with iBGP fully meshed.
  • CE1 and CE2 configured with eBGP with PE1 and PE2 respectively

Show BGP table on CORE1:

CORE1#sh ip bgp

BGP table version is 7, local router ID is 10.255.255.3

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete


Network Next Hop Metric LocPrf Weight Path

* i192.168.10.0 10.255.255.1 0 100 0 65500 i

* i 10.255.255.2 0 100 0 65500 i

*>i 10.255.255.1 0 100 0 65500 i

* i192.168.20.0 10.255.255.1 0 100 0 65500 i

* i 10.255.255.2 0 100 0 65500 i

*>i 10.255.255.1 0 100 0 65500 i

* i192.168.30.0 10.255.255.1 0 100 0 65500 i

* i 10.255.255.2 0 100 0 65500 i

*>i 10.255.255.1 0 100 0 65500 i

* i200.0.10.0 10.255.255.5 0 100 0 i

*>i 10.255.255.5 0 100 0 i

* i200.0.20.0 10.255.255.5 0 100 0 i

*>i 10.255.255.5 0 100 0 i

* i200.0.30.0 10.255.255.5 0 100 0 i

*>i 10.255.255.5 0 100 0 i

Looking on CORE1 BGP table for prefix 192.168.10.0/24:

CORE1#sh ip bgp 192.168.10.0

BGP routing table entry for 192.168.10.0/24, version 7

Paths: (3 available, best #3, table Default-IP-Routing-Table)

Advertised to update-groups:

1 2

65500, (received & used)

10.255.255.1 (metric 2) from 10.255.255.4 (10.255.255.4)

Origin IGP, metric 0, localpref 100, valid, internal

Originator: 10.255.255.1, Cluster list: 10.255.255.4

65500, (Received from a RR-client), (received & used)

10.255.255.2 (metric 2) from 10.255.255.2 (10.255.255.2)

Origin IGP, metric 0, localpref 100, valid, internal

65500, (Received from a RR-client), (received & used)

10.255.255.1 (metric 2) from 10.255.255.1 (10.255.255.1)

Origin IGP, metric 0, localpref 100, valid, internal, best

CORE1 is learning networks 192.168.10.0/24 to 192.168.30.0/24 from 3 sources – PE1, PE2 and the best from CORE2.

In order to give the customer the ability to influence and control his route prefix advertisement to the ISP we will use community's value. The following table shows which action the ISP PE routers will take following the configured communities:

50:10 – set local-preference 50

200:10 – set local-preference 200

300:10 – set local-preference 300

In short – each PE will set the local-preference for received route according to the route community value. If none configured then the PE will use the default value which is 100.

First we will have to configure the PE's with the following community access-lists:

ip community-list expanded LP50 permit 50:10

ip community-list expanded LP200 permit 200:10

ip community-list expanded LP300 permit 300:10

Then configure the following route-map:

route-map CE-PE permit 10

description LP50

match community LP50

set local-preference 50

!

route-map CE-PE permit 20

description LP200

match community LP200

set local-preference 200

!

route-map CE-PE permit 30

description LP300

match community LP300

set local-preference 300

!

route-map CE-PE permit 40

Due to the fact that we can have only one input and output route-map per neighbor we have to configure all parameters in one route-map.

The apply route-map to the neighbor statement in BGP router configuration:

PE1(config-router)#do sh run | s bgp

router bgp 10

no synchronization

bgp log-neighbor-changes

neighbor ebgp peer-group

neighbor ebgp version 4

neighbor ebgp soft-reconfiguration inbound

neighbor ebgp route-map CE-PE2 in

neighbor 172.16.0.2 remote-as 65500

neighbor 172.16.0.2 peer-group ebgp

no auto-summary

<Output omitted>

I have used a peer-group named ebgp for external BGP peering.

One more important thing is to configure on every router that will use community value the following command:

Router(config)#ip bgp-community new-format

Else you will see single large number in the community value instead of aa:nn format.

Now after finishing configure the PE routers let's move to configure the CE routers, the first example will be in CE2, every route/prefix that CE2 will advertise to PE2 should be with Local-preference of 200.

First configure the following route-map:

route-map CE-PE permit 10

set community 200:10

!

route-map CE-PE permit 20

!

Then apply it to the neighbor statement for PE2:

neighbor 172.16.0.5 route-map CE-PE out

That's it! Following this case the customer can actually control the inbound direction from the ISP to his networks.

Looking on ISP router BGP table:

ISP#sh ip bgp

BGP table version is 58, local router ID is 10.255.255.5

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete


Network Next Hop Metric LocPrf Weight Path

*>i192.168.10.0 10.255.255.2 0 200 0 65500 i

* i 10.255.255.2 0 200 0 65500 i

*>i192.168.20.0 10.255.255.2 0 200 0 65500 i

* i 10.255.255.2 0 200 0 65500 i

*>i192.168.30.0 10.255.255.2 0 200 0 65500 i

* i 10.255.255.2 0 200 0 65500 i

*> 200.0.10.0 0.0.0.0 0 32768 i

*> 200.0.20.0 0.0.0.0 0 32768 i

*> 200.0.30.0 0.0.0.0 0 32768 i

All paths to 192.168.xxx.0/24 networks are preferred through PE2 which leads to CE2.

Note: the reason that ISP sees 2 paths to each 192.168.xxx.0/24 is due to soft-reconfiguration inbound command; looking on PE2 BGP entry for 192.168.10.0/24 will revel:

PE2#sh ip bgp 192.168.10.0/24

BGP routing table entry for 192.168.10.0/24, version 12

Paths: (2 available, best #1, table Default-IP-Routing-Table)

Flag: 0x9C0

Advertised to update-groups:

3

65500

172.16.0.6 from 172.16.0.6 (2.2.2.2)

Origin IGP, localpref 200, valid, external, best

Community: 200:10

65500, (received-only)

172.16.0.6 from 172.16.0.6 (2.2.2.2)

Origin IGP, localpref 100, valid, external

Community: 200:10

Where one path is marked with (received-only)

Now let's configure CE1 as best-path for network 192.168.10.0/24 only, we will configure an access-list that will match the desired prefix:

access-list 1 permit 192.168.10.0 0.0.0.255

Then configure an appropriate route-map:

route-map CE-PE-10 permit 10

match ip address 1

set community 300:10

!

route-map CE-PE-10 permit 20

!

route-map CE-PE permit 20

And finally apply the route-map to the neighbor statement of PE1:

neighbor 172.16.0.1 route-map CE-PE-10 out

The result – network 192.168.10.0/24 is advertised to ISP AS with local-preference of 300 to CE1

ISP#sh ip bgp

BGP table version is 59, local router ID is 10.255.255.5

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete


Network Next Hop Metric LocPrf Weight Path

*>i192.168.10.0 10.255.255.1 0 300 0 65500 i

* i 10.255.255.1 0 300 0 65500 i

*>i192.168.20.0 10.255.255.2 0 200 0 65500 i

* i 10.255.255.2 0 200 0 65500 i

*>i192.168.30.0 10.255.255.2 0 200 0 65500 i

* i 10.255.255.2 0 200 0 65500 i

*> 200.0.10.0 0.0.0.0 0 32768 i

*> 200.0.20.0 0.0.0.0 0 32768 i

*> 200.0.30.0 0.0.0.0 0 32768 i

BGP communities can give a customer the option to influence many route attributes through ISP community-policy.

All major ISP's holds this kind of list, some of the lists can be found in the following link: http://onesc.net/communities/

Cisco reference documents:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml

http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a00801475b2.shtml#insertID



2 comments:

  1. thank you - clear overview of the topic with excellent diagrams and examples.

    ReplyDelete