Use MED to Influence Incoming Traffic Flow
In previous lab exercises, you used BGP weights and BGP local preference to change the BGP tables on your routers, thus changing the outgoing traffic flow. In this exercise, we’ll change the incoming traffic flow with the BGP Multi-Exit Discriminator (MED) attribute.
Changing incoming traffic flow is more critical for networks that are not content providers. It’s also much more challenging than changing the outgoing traffic flow, as you must try to influence the BGP tables on other people’s routers.
Existing Router Configuration
The routers in your lab use the following BGP AS numbers. Each autonomous system advertises an IPv4 prefix. Upstream routers (x1, x2) also advertise the default route to your router (rtr).
|Node/ASN||Router ID||Advertised prefixes|
Your routers have these BGP neighbors:
|Node||Router ID /
Your network is also running OSPF in the backbone area:
Start the Lab
Assuming you already set up your lab infrastructure:
- Change directory to
- Execute netlab up to start the lab using the usual external devices for X1 and X2, or netlab up single.yml to start the lab that uses only your chosen devices1. You can also run this lab without using netlab
- Log into your devices (C1 and C2) with netlab connect and verify their configurations.
netlab will configure IP addressing, OSPF, BGP, IBGP sessions, EBGP sessions, and BGP prefix advertisements on your routers. If you’re not using netlab, you’ll have to configure your routers manually.
Check the BGP Tables on External Routers
Log into X1 and X2 and check their BGP tables. Use
sudo vtysh -c 'show ip bgp' command if you’re running Cumulus Linux on external routers:
$ netlab connect x1 sudo vtysh -c 'show ip bgp 192.168.42.0' Connecting to container clab-med-x1, executing sudo vtysh -c "show ip bgp 192.168.42.0" BGP routing table entry for 192.168.42.0/24 Paths: (2 available, best #2, table default) Advertised to non peer-group peers: x2(10.0.0.11) 10.1.0.1 65000 10.0.0.11 (metric 10) from x2(10.0.0.11) (10.0.0.11) Origin IGP, localpref 100, valid, internal Last update: Mon Nov 6 07:08:30 2023 65000 10.1.0.1 from 10.1.0.1 (10.0.0.1) Origin IGP, valid, external, bestpath-from-AS 65000, best (Peer Type) Last update: Mon Nov 6 07:08:12 2023
$ netlab connect x2 sudo vtysh -c 'show ip bgp 192.168.42.0' Connecting to container clab-med-x2, executing sudo vtysh -c "show ip bgp 192.168.42.0" BGP routing table entry for 192.168.42.0/24 Paths: (2 available, best #2, table default) Advertised to non peer-group peers: x1(10.0.0.10) 10.1.0.5 65000 10.0.0.10 (metric 10) from x1(10.0.0.10) (10.0.0.10) Origin IGP, localpref 100, valid, internal Last update: Mon Nov 6 07:08:29 2023 65000 10.1.0.5 from 10.1.0.5 (10.0.0.2) Origin IGP, valid, external, bestpath-from-AS 65000, best (Peer Type) Last update: Mon Nov 6 07:08:11 2023
X1 and X2 prefer the EBGP path to the customer prefix (
192.168.42.0/24) over the IBGP path. The distinction between the two paths is small enough for MED to work.
Using BGP Multi-Exit Discriminator (MED)
The Border Gateway Protocol 4 (BGP-4) RFC (RFC 4271) defines the MULTI_EXIT_DISC attribute as an optional attribute that is
intended to be used on external (inter-AS) links to discriminate
among multiple exit or entry points to the same neighboring AS. The first limitation of MED is that it can only influence incoming traffic flow if your network connects to a single upstream network.
RFC 4271 also defines how to use MED: “All other factors being equal, the exit point with the lower metric SHOULD be preferred.” MED is a weak metric considered at the end of the BGP path selection process. You can use it to influence incoming traffic only if the upstream network uses no other routing policy.
Finally, RFC 4271 defines MED propagation rules:
- MED can be used on EBGP sessions.
- If received over EBGP, the MED attribute MAY be propagated over IBGP to other BGP speakers within the same AS.
- The MED attribute received from a neighboring AS MUST NOT be propagated to other neighboring ASes.
We’ll use the above behavior to implement a straightforward routing policy:
- Set the MED on routes advertised from C1 to X1 to 50
- Set the MED on routes advertised from C2 to X2 to 100 (remember: higher MED is worse).
You will probably have to configure a routing policy (often called a route-map) on C1 and C2 to change the MED and then apply the routing policy as the outbound policy on the EBGP neighbors.
Applying routing policy parameters to BGP neighbors doesn’t necessarily change the BGP table, as the new routing policy might be evaluated only on new incoming updates. You might have to use a command similar to
clear ip bgp * soft to tell your routers to resend their BGP updates.
Examine the BGP tables on X1 and X2 to verify that the routes from AS 65000 have the desired metric. This is a printout you should get on X2 running Cumulus Linux:
$ netlab connect x2 sudo vtysh -c 'show ip bgp 192.168.42.0' Connecting to container clab-med-x2, executing sudo vtysh -c "show ip bgp 192.168.42.0" BGP routing table entry for 192.168.42.0/24 Paths: (2 available, best #1, table default) Advertised to non peer-group peers: 10.1.0.5 65000 10.0.0.10 (metric 10) from x1(10.0.0.10) (10.0.0.10) Origin IGP, metric 50, localpref 100, valid, internal, bestpath-from-AS 65000, best (MED) Last update: Mon Nov 6 07:36:36 2023 65000 10.1.0.5 from 10.1.0.5 (10.0.0.2) Origin IGP, metric 100, valid, external Last update: Mon Nov 6 07:36:36 2023
X2 has two paths toward
- IBGP path received from 10.0.0.10 (X1) with metric 50. This is the best path due to MED value.
- EBGP path received from 10.1.0.5 (C2) with metric 100. This is a valid path, but there are better.
If you get a similar printout in your lab, you accomplished your mission – you managed to change the incoming traffic flow to avoid the C2-X2 link.
In real life, you cannot log into other people’s routers. In most cases, you’re limited to observing the incoming traffic counters on your uplinks and hoping for the best. You might be able to use looking glasses (if available) in adjacent networks to inspect their BGP tables or use the traceroute tool from a remote vantage point (for example, your laptop tethered to a mobile Internet connection) to check the traffic flow into your network.
The following information might help you if you’re not using netlab to build the lab:
This lab uses a subset of the 4-router lab topology. Some links are unused to retain the interface names from that topology.
|Link Name||Origin Device||Origin Port||Destination Device||Destination Port|
|ISP internal link||x1||swp2||x2||swp2|
|Customer internal link||c1||Ethernet3||c2||Ethernet3|
|Node/Interface||IPv4 Address||IPv6 Address||Description|
|Ethernet3||192.168.42.1/24||Customer internal link|
|Ethernet3||192.168.42.2/24||Customer internal link|
|swp2||192.168.100.10/24||ISP internal link|
|swp2||192.168.100.11/24||ISP internal link|
Using your chosen devices in the ISP network might make it easier to check the status of the BGP tables on X1 and X2. It will also consume more memory (Cumulus Linux and FRR are very memory-efficient). ↩