Archive

Archive for the ‘Real-World’ Category

My First Real World Encounter with BGP !

April 18, 2009 Leave a comment

Hello !!!

So .. I have been busy for the past few weeks in a BGP Project, and for my faithful blog readers I want to share my experience.

Basically the project was a BGP Multihoming Scenario with policy routing.

The customer has its own AS Number and /22 Pool of IP Addresses assigned by the RIR

For Explanation I will use Private AS Numbers and IP Pool from the Private Range

So Lets say the customer is Assigned an AS Number 65503 and an IP Pool – 192.168.128.0 /22

It peers with two ISPs , ISP A and ISP B with AS Numbers 65501 and 65502 respectively.

You can see the Diagram Here ..

bgp-diagram

Now … Here comes the pain … the traffic load share that the customer want is mentioned below.

  • / 22 Pool is subnetted into 4 / 24 pools.
  • Two / 24 pools are used through one ISP both for one incoming and outgoing traffic and other two / 24 are used through another.
  • For Example 192.168.130.0 / 24 and 192.168.131.0 / 24 pools are used through ISP B. The traffic sourced from and destined to these pools must use ISP B.
  • If a link to any ISP goes down the traffic must be re-routed through the other ISP.

To apply policies to BGP updates you have to first categorize them into Inbound BGP Policy ( affects outbound traffic flow ) and Outbound BGP Policy
( affects Inbound Traffic Flow )

Now before I mention the policies i must tell you that when the / 22 pool is advertised from both ISPs without any policies applied or modifications
The routing chips usually prefer ISP A. Thus ISP A is considered a better ISP to reach the /22 pool.

We will first consider Outbound BGP Policy that affects our Incoming traffic.

Here is the configuration of both routers to get the desired ingress traffic share.

Router A


router bgp 65503

neighbor 10.1.1.1 remote-as 65501
no auto-summary
no synchronization
network 192.168.128.0 mask 255.255.252.0

ip route 192.168.128.0 255.255.252.0 Null0

Router B

router bgp 65503

neighbor 172.16.1.1 remote-as 65502
neighbor 172.16.1.1 prefix-list subblocks out
neighbor 172.16.1.1 route-map prepend out
no auto-summary
no synchronization
network 192.168.128.0 mask 255.255.252.0
network 192.168.130.0 mask 255.255.255.0
network 192.168.131.0 mask 255.255.255.0

ip route 192.168.128.0 255.255.252.0 Null0

ip prefix-list aggregate seq 5 permit 192.168.128.0/22

ip prefix-list subblocks seq 5 permit 192.168.130.0/24
ip prefix-list subblocks seq 10 permit 192.168.131.0/24
ip prefix-list subblocks seq 20 permit 192.168.128.0/22

route-map prepend permit 10
match ip address prefix-list aggregate
set as-path prepend 65503 65503 65503

route-map prepend permit 20

As you can see .. Router A only advertises the / 22 pool while Router B advertises three prefixes , two / 24 pools and a / 22 prefix with AS_PATH attribute prepended to it.

This fulfills the requirement as the pools 192.168.130.0 /24 and 192.168.131.0/24 are always reached through ISP B due longer match prefix matching while the other pools are reached through ISP A.

Incase ISP A goes down the the whole / 22 pool can now be reached through ISP B which was previously not the case as ISP B was advertising a the prefix with a longer AS_PATH attribute then ISP A.

If ISP B goes down the /22 pool and the specific subnets can be reached through ISP A as ISP B withdraws its two /24 prefix advertisement to its peers. Thus the match is made on / 22 route that includes ISP A in the path in the global BGP Table.

——————————————————————————————————————————————————

This task was not much difficult but the Outgoing traffic requirement really got me into thinking.

To prevent asymmetric routing the traffic flow that uses an ISP as ingress must also use it as the exit.

So traffic sourced from and destined to 192.168.130.0 /24 and 192.168.131.0 /24 pools must use ISP B. While other traffic must use ISP A.

I really did not want to make the routing table dirty with over 200K routes, and infact after reading Nanog and Sanog presentations from Phillip Smith
this scenario really didn’t require us to do so.

So we are only accepting the default from the providers

Here are the Respective configurations added to the devices.

Router A

router ospf 100

log-adjacency-changes
network 192.168.128.1 0.0.0.0 area 0
network 192.168.128.5 0.0.0.0 area 0
default-information originate metric 20 metric-type 1

router bgp 65503

neighbor 10.1.1.1 prefix-list defaultonly in
ip prefix-list defaultonly seq 5 permit 0.0.0.0/0


Router B
router ospf 100

log-adjacency-changes
network 192.168.128.6 0.0.0.0 area 0
network 192.168.128.9 0.0.0.0 area 0
default-information originate metric 30 metric-type 1

router bgp 65503

neighbor 172.16.1.1 prefix-list defaultonly in
ip prefix-list defaultonly seq 5 permit 0.0.0.0/0

Switch

ip access-list extended ISPB-prefix
permit ip 192.168.130.0 0.0.0.255 any
permit ip 192.168.131.0 0.0.0.255 any

route-map ISPB-policy permit 10
match ip address ISPB-prefix
set ip next-hop 192.168.128.9

router ospf 100
network 192.168.128.2 0.0.0.0 area 0
network 192.168.128.10 0.0.0.0 area 0

interface Vlan200
ip address 192.168.128.33 255.255.255.240
ip policy route-map ISPB-policy

OSPF is enabled on interfaces connecting RA-RB , RA-SW and RB-SW

Note – All interface connecting these links are L3 Routed Interfaces while the link to the Server farm has an SVI where the policy is applied.

Both Routers advertise a default into the OSPF domain which they get from BGP.

Router A advertises a default with metric of 20 while Router B advertises a Default with Mertic of 30.
A policy is applied on the switch to send the traffic with a source address from the pools 192.168.130.0/ 24 and 192.168.131.0/24 to Router B.

So far the routing is simple , any traffic that matches the ISPB-policy on switch is sent to Router B which has BGP route 0.0.0.0/0 pointing to ISP B router.
the traffic that doesnot match the policy on the switch is matched by OSPF default route pointing to Router A and sent to Router A which itself has a BGP
route 0.0.0.0/0 pointing to ISP A router.

If the Connection to ISP A goes down, Router A withdraws its default route that it is injecting into the OSPF domain, the switch then Installs the route via Router B and sends all traffic to router B.

If the connection to ISP B goes down Router B withdraws its default route that it is injecting into the OSPF domain. But the problem is that Switch is still sending
the traffic to Router B that is matched through the policy. …

Not a big deal as Router B installs a OSPF default route learned on RA-RB link from Router A and sends this traffic to router A.

So finally all the traffic share requirements are met and failover implementation is acheived.

My first BGP implementation .. really enjoyed it … im really loving this protocol ..

Next Step — Migrate OSPF to BGP as the Enterprise Core Routing Protocol for another client Network ; ) ….. just joking , need a lot of guts to do so ..

hmm.. Not a bad option though, Check this article on Scalable Policy routing by Ivan Pepelnjak

Zeeshan

Advertisements
Categories: BGP, Real-World Tags: ,