Select Preferred Uplink with BGP Local Preference
In a previous lab exercise, you used BGP weights to prefer a high-speed uplink over a low-speed uplink. That worked well because you had both links attached to the same router. Now, imagine that you have a redundant design with two routers and want to prefer the C1-X1 link over the slower C2-X2 link.
You could use BGP weights to get the job done, but as weights aren’t a BGP attribute and thus aren’t propagated between routers, you’d have to apply them to all BGP sessions on C1 and C2. There’s a better way: BGP has the local preference attribute that works like weights but gets propagated across IBGP sessions.
In this lab, you’ll use BGP local preference to ensure all BGP routers in your network prefer routes received over the C1-X1 link.
Initial Router Configurations
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 (other options)
- Log into your devices (C1 and C2) with netlab connect and verify their configurations.
Note: netlab will configure IP addressing, OSPF, BGP, IBGP sessions, EBGP sessions, and BGP prefix advertisements on your routers. You’ll have to manually configure your routers if you’re not using netlab.
Using BGP Local Preference
- All IBGP update messages contain the LOCAL_PREF attribute.
- A BGP speaker never uses the LOCAL_PREF attribute on EBGP updates.
- The LOCAL_PREF attribute influences the selection of BGP best paths (higher local preference is better).
The RFC does not specify how a router sets the BGP local preference or how it influences the BGP best path selection. Most BGP implementations use these defaults to interoperate with older devices:
- The default value of the LOCAL_PREF attribute that a router adds to EBGP routes before advertising them over IBGP sessions is 100.
- LOCAL_PREF is considered very early in the BGP best path selection process (before AS path length). This behavior makes LOCAL_PREF an ideal attribute when implementing a consistent BGP path selection across a whole autonomous system.
We’ll use the above behavior to implement a straightforward routing policy:
- Set the default local preference on C1 to 200 (making it better than the built-in default value)
- Set the default local preference on C2 to 50 (making it worse than the built-in default).
Some BGP implementations allow you to change the default local preference value with a configuration command similar to bgp default local-preference. If your implementation does not support changing the default LOCAL_PREF value, you’ll have to use a routing policy (often called a route-map) attached to a BGP neighbor to modify it.
If you’re using a network device that cannot change the default LOCAL_PREF value (example: Arista EOS), then you’re probably already familiar with route maps. You might have been using them in the Filter Transit Routes or Filter Advertised Prefixes exercises.
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 in to tell your router to ask its neighbors to resend their BGP updates.
Examine the BGP table on C2 to verify that the routes advertised by C1 (next hop: 10.0.0.1) have a higher local preference and are preferred over routes received from X1 (next hop: 10.1.0.6). This is a printout you should get on Arista EOS:
c2#show ip bgp | begin Network Network Next Hop Metric AIGP LocPref Weight Path * > 0.0.0.0/0 10.0.0.1 0 - 200 0 65100 i * 0.0.0.0/0 10.1.0.6 0 - 50 0 65100 i * > 192.168.42.0/24 - - - - 0 i * 192.168.42.0/24 10.0.0.1 0 - 100 0 i * > 192.168.100.0/24 10.0.0.1 0 - 200 0 65100 i * 192.168.100.0/24 10.1.0.6 0 - 50 0 65100 i
You could dig deeper and examine the details of an IPv4 prefix that originated in AS 65100, for example,
c2#show ip bgp 192.168.100.0/24 BGP routing table information for VRF default Router identifier 10.0.0.2, local AS number 65000 BGP routing table entry for 192.168.100.0/24 Paths: 2 available 65100 10.0.0.1 from 10.0.0.1 (10.0.0.1) Origin IGP, metric 0, localpref 200, IGP metric 20, weight 0, tag 0 Received 00:03:44 ago, valid, internal, best Rx SAFI: Unicast 65100 10.1.0.6 from 10.1.0.6 (10.0.0.11) Origin IGP, metric 0, localpref 50, IGP metric 0, weight 0, tag 0 Received 00:33:52 ago, valid, external Rx SAFI: Unicast
The following information might be helpful 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|