Categories

CUC (6) CUCM (27) Jabber (6) Python (2) Routing (3) Solarwinds Orion NPM (4) switching (1) Video (6) voice (2)

Wednesday, 2 October 2013

Same Provider Multi homing using BGP (local preference and AS path prepend)

Back to my roots: R&S. Recently, I started playing with GNS3 again, mainly to keep my routing skills fresh.  In this post I will discuss a possible routing solution to a dual router WAN link active/standby scenario. I will discuss how to tweak inbound and outbound BGP and some relevant basics of BGP. Basically I want to look at BGP multihoming. Multihoming means thet you have two (or more) routes to any destination connected to Internet/WAN. So you will need a method to decide which route is better or how to load balance.

There is a heaps of information on BGP out there and Cisco has some good, usable BGP case studies online (see sources at the bottom of this post). So lets start with a simple scenario.


SCENARIO
Fig.1 depicts the scenario I will be discussing. Two sites; Copenhagen and Stockholm (yes I am fully aware of the fact that Copenhagen is NOT north of Stockholm!!). The two sites are connected by a WAN, though the same provider. Because I do not really care how this provider routes between the two site, I summarised the provider into a single router (Provider WAN router). Although you could argue that the scenario does not represent multihoming in the strictest sense of the word. 

The Stockholm site is the focus in this post. It has two WAN routers and they are connected to a 3rd router, called Stockholm3. Think of this 3rd router as a  layer 3 Distribution or Core switch, running HSRP or VSS for example. 

You could expand this scenario with an provider router, connected to Internet, injecting a default route into the providers BGP process. Because I only want to discus local metric tweaking and iBGP, I consider this out of scope. 

In this scenario, all but the Provider WAN router are part of the administrative responsibility of the customer.

Figure 1 - Dual WAN link multi homing scenario

OBJECTIVE

Implement redundant WAN connectivity to Copenhagen, in ACTIVE/STANDBY fashion, by means of a set of WAN routers. Equally all traffic into the Stockholm site, should be routed to the ACTIVE router (Stockholm1_WAN) and should fail over to the STANDBY router (Stockholm2_WAN). Please note that the objective is NOT to implement load sharing or load balancing!! I will discuss load sharing in a separate post. This post will purely discuss redundant paths.


SOLUTION and DISCUSSION

So I will use a combination of IGP (OSPF) and BGP.  BGP is pretty much a given, seeing WAN providers will offer this a lot of times. If you are managing your own cloud routers, then this solution will still apply.

On the Stockholm WAN routers I use both BGP and OSPF. eBGP to communicate to my providers routers and iBGP to communicate within the Stockholm AS of 65118 AS of 

So the components of the solution are as follows:

ACTIVE link (Stockholm1-WAN):
Outbound – announce all Stockholm subnets (10.x.x.x) unaltered
Inbound – receive default route (or all routes).


STANDBY link (Stockholm2-WAN):
Outbound – announce all Stockholm subnets with increased metric (AS path prepend)
Inbound – receive default route (or all routes) , and reduce local preference


Let me start with the locacl preference attribute. Local preference is an indication to the AS about which path is preferred to exit the AS in order to reach a certain network. A path with a higher local preference is more preferred. The default value for local preference is 100.

On Stockholm 1:

 
router ospf 1
 router-id 10.11.201.2
 log-adjacency-changes
 network 10.11.201.0 0.0.0.255 area 0
 default-information originate always metric 110

router bgp 65118
 no synchronization
 bgp default local-preference 200
 bgp log-neighbor-changes
 network 10.11.10.1 mask 255.255.255.255
 network 10.11.201.0 mask 255.255.255.0
 network 10.240.10.0 mask 255.255.255.0
 neighbor 10.240.1.2 remote-as 65118
 neighbor 10.240.1.2 description Stockholm2_WAN_iBGP
 neighbor 10.240.1.2 password cisco
 neighbor 192.168.10.1 remote-as 65100
 neighbor 192.168.10.1 description Provider_wan_RTR

On Stockholm2:


router ospf 1
 router-id 10.11.200.2
 log-adjacency-changes
 network 10.11.200.0 0.0.0.255 area 0
 default-information originate always metric 120
!
router bgp 65118
 no synchronization
 bgp log-neighbor-changes
 network 10.11.10.1 mask 255.255.255.255
 network 10.11.200.0 mask 255.255.255.0
 network 10.240.10.0 mask 255.255.255.0
 network 192.168.20.0
 neighbor 10.240.1.1 remote-as 65118
 neighbor 10.240.1.1 description Stockholm_1_WAN_iBGP
 neighbor 10.240.1.1 password cisco
 neighbor 192.168.20.1 remote-as 65100
 neighbor 192.168.20.1 description Provider_RTR1
 neighbor 192.168.20.1 password cisco
 no auto-summary

Stockholm1 is left to default in terms of local preference (value=100)If I check the bgp topology on Stockholm1, for Copenhagen's subnet 172.16.10.1:

Stockholm1_WAN#sh ip bgp 172.16.10.1
BGP routing table entry for 172.16.10.0/24, version 31
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x840
  Advertised to update-groups:
        2
  65100 65218
    192.168.10.1 from 192.168.10.1 (192.168.30.1)
      Origin IGP, localpref 200, valid, external, best

compared to Stockholm 2:


Stockholm2_WAN#sh ip bgp 172.16.10.1
BGP routing table entry for 172.16.10.0/24, version 864
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Flag: 0x840
  Advertised to update-groups:
        1
  65100 65218
    192.168.10.1 from 10.240.1.1 (192.168.10.2)
      Origin IGP, metric 0, localpref 200, valid, internal, best
  65100 65218
    192.168.20.1 from 192.168.20.1 (192.168.30.1)
      Origin IGP, localpref 100, valid, external

As you can see, Stockholm 2, our secondary router, has two available paths to Copenhagen. One path straight to the provider router (192.168.20.1) and a second and most preferred path to Stockholm1 (10.240.1.1). This means that Stockholm1 is our preferred outbound router for all Stockholm egress traffic.  

Let me test this, I will do a trace from our Stockholm 3 router's loopback 10.11.10.1, to Copenhagen loopback 172.16.10.1, first when under normal operation:

Tracing the route to 172.16.10.1

  1 10.11.201.2 60 msec 40 msec 60 msec
  2 192.168.10.1 48 msec 32 msec 28 msec
  3 192.168.30.2 76 msec *  80 msec
Stockholm_3#

Path:  Stockholm1-ProviderRTR-Copenhagen

Now I will kill the link between Stockholm3 and 1. This should see traffic divert to Stockholm 2 and out to the WAN via Stockholm1, which will still have the highest local preference. The traceroute now is:


Tracing the route to 172.16.10.1

  1 10.11.200.2 24 msec 92 msec 8 msec  
 2 10.240.1.1 56 msec 60 msec 32 msec  
3 192.168.10.1 92 msec 36 msec 72 msec  
4 192.168.30.2 100 msec *  92 msec
Stockholm_3#


as you can see, indeed, now there are 4 hops. So this works as per our requirement.


Now we have to influence the path into our and with this will must make the Stockholm1 router (Primary) the most preferred router for all inbound traffic. There could be numerous reasons to do this. In stead of a single provider connecting to our network, we might have two different providers, or even a slow and a fast link.  Regardless of what reason, influencing the AS path is probably the easiest way. Remember, we cannot use local preference to do this as it will not be carried into another AS. So for this we will use another method: AS path prepending.

When using AS Path prepending, we artificially lengthen the AS Path that is being advertised to a neighbor to make them think that the path much longer than it actually is.

As you can see below, the path back to Stockholm, seen from the Provider Router, has two possible paths, both with local preference 100 and metric 11.

Prvdr_WAN_RTR#sh ip bgp 10.11.10.1
BGP routing table entry for 10.11.10.1/32, version 23
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Advertised to update-groups:
        1
  65118
    192.168.10.2 from 192.168.10.2 (192.168.10.2)
      Origin IGP, metric 11, localpref 100, valid, external
  65118
    192.168.20.2 from 192.168.20.2 (192.168.20.2)
      Origin IGP, metric 11, localpref 100, valid, external, best


In this particular case, the path that was received first (longest established neighborship), is selected as the best path.  As you can understand this is not the accepted, controllable behavior we want. (For an explanation on BGP best path selection:  http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml )

Let's have a look at the current AS path seen from the Provider Router, back to Stockholm 3.

Prvdr_WAN_RTR#sh ip bgp
BGP table version is 8, local router ID is 192.168.30.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.11.10.1/32    192.168.10.2                            0     65118 i
*                              192.168.20.2            11           0     65118 i

Without AS path prepending, the path back to Stockholm, goes via AS 65118 and where it is internal (hence the "i"). 

So here is an example of applying AS prepending, very much the same sort of set up as route maps  and then applied to the desired BGP neighbor. in our scenario this will be applied to the Stockholm2 router.

router bgp 65118
 no synchronization
 bgp log-neighbor-changes
 network 10.11.10.1 mask 255.255.255.255
 network 10.11.200.0 mask 255.255.255.0
 network 10.240.10.0 mask 255.255.255.0
 network 192.168.20.0
 neighbor 10.240.1.1 remote-as 65118
 neighbor 10.240.1.1 description Stockholm_1_WAN_iBGP
 neighbor 10.240.1.1 password cisco
 neighbor 192.168.20.1 remote-as 65100
 neighbor 192.168.20.1 description Provider_RTR1
 neighbor 192.168.20.1 route-map prepend out
 neighbor 192.168.20.1 password cisco
 no auto-summary

ip as-path access-list 100 permit ^$

route-map prepend permit 10
 match as-path 100
 set as-path prepend 65118 65118 65118



After the AS path prepend configuration is added to Stockholm2, the route back to Stockholm, as seen from the provider router is as follows:

Prvdr_WAN_RTR#sh ip bgp                                                                                                                    
BGP table version is 9, local router ID is 192.168.30.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.11.10.1/32    192.168.10.2             11            0          65118 i
*                             192.168.20.2            11            0          65118 65118 65118 65118 i                         


As you can see the path back to Stockholm3 is from the provider router, now has a longer AS path through Stcokholm 2, compared to the path through Stockholm1, so the first path in the output above is the preferred path, because it only crosses AS 65118 once. 



sources:








No comments:

Post a Comment