DATACOM 2 is about to release a new Ethernet Switch platform,
DM4050, as FOA (first office application), which will be shipped with
DmOS as its operating system. In this post, I’d like to show you guys some of its use cases as a L3 CPE multihomed with BGP 1, specifically we’ll see some of the features that are available as far as inbound and outbound BGP policy routing on
In this topology,
SW6_DM4050 provides L3 access for a specific carrier network. In this case,
DM4050 is on a private (AS - autonomous system)
AS 65000 and it’s multihomed to an upstream ISP
AS 2 that has two routers
AS 65000, there’s a
DM4100 as a router-reflector and the rest of the L3 topology is simply abstracted as a
L3 cloud, which could be a flat OSPF backbone or a multi-area design.
Metro Ethernet L2
Typically, on carrier networks,
DM4050 will probably have some metro Ethernet 10GE aggregation rings, running either EAPS or STP, since this platform has 6 x 10GE interfaces, but I won’t focus on this L2 feature set in this post.
There are several attributes on BGP that can be used to influence how prefixes are supposed to be routed both inbound and outbound 1. In the following sections, I’ll show some of them that are commonly used. Let’s assume our local AS has four public routable /24 prefixes,
184.108.40.206/22, and we’d like to influence that the incoming traffic for the first two prefixes comes from one upstream router
MX1 and the incoming traffic for the last two prefixes comes from the other upstream router
CSR2. Plus, let’s say the upstream
AS 2 announces the prefix
220.127.116.11/32 and we’d like to enforce that the outbound traffic from our local AS to this prefix goes through
MX1 preferably. These prefixes are illustrated in Figure 2, just check out both gray and brown arrows for a visual representation.
Let’s review some of BGP’s attributes first to understand how we’re going to set the routing policies. Afterwards, I’ll show some configuration snippets just in case you need them.
You can use
LOCAL_PREF in order to enforce how your AS routes traffic outbound. The higher this value, the most preferable the L3 switch/router will be to route traffic out of your autonomous system. This attribute is propagated inside your AS, so all iBGP peers will choose the best route based on the highest
LOCAL_PREF. Since you can set this attribute based on a set of prefixes, you can even have multiple routers and each of them could be the most preferable gateway for a subset of these prefixes. Typically, you weigh the
LOCAL_PREF value according to the preference of your gateways based on some matching criteria.
In this case, to make sure that the prefix
18.104.22.168/32 received from
AS 2 is preferably routed through
MX1 (192.168.52.1) and then
CSR2 (192.168.53.2) as a second gateway, we’ll set the local preference as 1000 when receiving this prefix from
MX1, and local preference as 500 from
Keep in mind that outbound policies have higher preference over inbound policies, which means that in order for your inbound policies to have the expected outcome you have to make sure that the upstream AS provider doesn’t have outbound policies in place that will overrule your inbound attributes. Usually, upstream ISPs provide looking glass routers for you to check this out.
It’s possible to prepend the local AS on the
AS_PATH in order to try to influence how the remote-as is supposed to route towards our local
AS 65000. The longer the
AS_PATH the least preferable the prefix is.
In this use case, we have four /24 prefixes,
22.214.171.124/22, and we’d like to influence that the incoming traffic for the last two prefixes,
126.96.36.199/24, comes from
CSR2 preferably. To accomplish this, I’ll prepend the local AS tree times when announcing these last two prefixes to
CSR2 and five times to
- MED (aka MULTI_EXIT_DISC)
MED is used when you have multiple BGP sessions to the same remote AS and you want to influence how they are supposed to route. In short,
MED is less powerful than the
AS_PATH is considered first in the selection path algorithm over
MED is not transitive (it’s not carried out by BGP updates over multiple ASes). The lower the
MED value the better. In this example, let’s use
MED to tell
AS 2 that we’d like that the incoming traffic of the first two prefixes,
188.8.131.52/24 comes from
MX1 preferably. We’ll set
MED as 20000 for these two prefixes being exported to
MED as 15000 for these prefixes exported to
The following configuration snippets show the configuration that is relevant to BGP.
184.108.40.206/32 was learned from both
MX1 (192.168.52.1) and
CSR2 (192.168.53.2), and the route entry selected as best is the one from
LOCAL_PREF 1000 > 500. As a result, traffic leaving from our local AS will route towards
SW4_DM4100, from an iBGP perspective:
CSR2's point of view, we can confirm that
220.127.116.11/24 is routed inside
AS 2 through
MED 15000 < 20000. The next-hop
18.104.22.168 is reachable by an internal network inside
AS 2. In addition, both
22.214.171.124/24 is routed through
CSR2 since the
65000 x 3 is shorter than
65000 x 5.
MX1's perspective, just for the sake of completeness, we can double check what we’ve seen on
CSR2. Note that the last two prefixes were prepended 5 times.