BGP design for a dual homed enterprise – the bare minimums!
We are back with another article and this time I would take a look at a typical enterprise network that connects to more than one ISP’s (I would consider two) for redundancy. One of main concerns in any typical dual homed BGP network is preventing your own AS from being a transit network. In this article we would take a look at how this can be achieved. In addition to that, most enterprises would like to prefer one ISP over the other for each directional streams of traffic. For instance, in the diagram that’s shown below, AS 100 which happens to be a Enterprise network (say) and would want to use ISP-B( AS 200) for its incoming traffic and would want to use ISP B (AS 300) for its outgoing traffic, but of course you should have each of them capable of handling both the streams when one of the ISP’s is inaccessible for some reason.
With this basic goals let’s begin designing and implementing this network.
I have already deployed BGP on all four routers R1, R2, R3 and R4. I have created some internal routes on each of these routers that would provide us with some meat to work with,
Shown below is the complete BGP table for R1 host router, before changing any of the BGP attributes on the router.
note that 126.96.36.199/24 exists in AS 400, which has peering relationship with both the ISP’s and hence the BGP process on R1 is learning it from both AS 200 and AS 300.
Coming to the first design aspect which is to prevent the host network (R1 in AS 100) from being a transit network, to achieve that we should stop the subnets advertised by ISP A from reaching ISP B and vice versa through R1. We facilitate this by matching the AS path for both the ISP AS paths using as-path access lists and then by using them in a deny route-map, which we would then implement on the neighbor’s in the outbound direction, as shown below.
That stops R2’s and R3’s routes being advertised into one another using R1, hence prevents R1 from becoming a transit for both the ISP’s.
Now moving on to the second part of the design objective, that is preferring AS 200 as the outbound ISP and AS 300 as the inbound ISP. Note that there are two parts to it, in the former we are talking about traffic leaving AS 100 and in the latter we refer to traffic that enters AS 100.
To make AS 300 as the preferred path for all outbound traffic we match the routes being advertised by AS 300 and set the local preference to any value above 100 (this can also be achieved by changing the cisco proprietary attribute of “weight”)
Note that the route with best local preference is placed in the routing table.
Note the LocPref value changed to 120 on all the routes learned from AS 300.
Also note that the route 188.8.131.52/24 is now preferred via AS 300 than via AS 200.
That completes our second goal, now moving on to the third and last aspect of the design, which is to make AS 300 less preferable (or AS 200 more preferable) for external traffic into the host AS.
To achieve this, we would create another as-path access list to collect all the locally advertized subnets. Once done, we would then use them in a route- map to prepend the last/local AS number a couple of times, we would then use the neighbor statements on the ISP neighbor command that needs to be less preferred.
This would prepend AS 100 to the AS paths that are advertised making it unlikely to be chosen as a return path, just to be sure let’s take a look at R4’s routing table to see how this may turn out.
A look at the R4 reveals that all the routes that are learned from AS 300 has a longer AS path with more hops on it and those that are learned from 200 have a much shorter hop, hence routes out of 200 are preferred.
That completes the second part of this objective.
Note that this method of AS preference would work if the person/AS originating the traffic chooses to keep all other all other parameters such as local preference, weight, origin status at their defaults. However should he change those parameters, we might still end up receiving traffic in the ISP that we don’t want to (just like the way we do it while sending our traffic out). Its best to keep your ISP in the loop while you set these preferences, its better yet if your ISP can do this for you (in which case you mark the routes to be treated a certain way with a community tag maybe?)
That completes the design session and we have achieved all our three goals. Please stay tuned for more sessions on hot and ‘not so hot’ networking topics.