Author: Nicholas Russo
Most engineers experienced with Border Gateway Protocol (BGP) know that there are many ways to influence the best-path selection algorithm. I’ve blogged about this before by pairing BGP communities with local-preference to influence egress routing out of an autonomous system (AS). Today, I’ll introduce yet another community-based best-path adjustment technique: the BGP cost community. This is an optional, non-transitive (i.e., internal BGP only) community that provides even more control over BGP routing.
This community is poorly understood and rarely used, but I’ve found it handy in tricky situations. It’s an extended community that has three components: a point of insertion (POI), a community ID, and a community value. Each one of these fields deserves its own paragraph as there are several caveats.
The POI indicates where in the BGP best-path algorithm the cost community should be evaluated. There are two choices:
1. Interior Gateway Protocol (IGP): This POI tells BGP to evaluate the cost community after evaluating the IGP cost to the BGP next-hop. Put another way, if the IGP cost to the BGP next-hop is tied across multiple paths, the cost community will be the tie-breaker. Without this community, BGP would compare router IDs and select the lower one, which is completely arbitrary. The IGP POI allows operators to declare “I want to take the shortest IGP path out of the AS, but if there are many equal paths, I want to rank them from best to worst”.
2. Pre-best-path: This POI tells BGP to evaluate the cost community before any of the BGP best-path attributes, assuming the other pre-best-path checks like next-hop accessibility and iBGP synchronization (if configured) are met. It even overrides Cisco’s “weight” attribute, making it a very powerful traffic engineering technique. The use cases leveraging this POI are obscure and are discussed later.
The diagram below illustrates each point of insertion so you can better understand when they are evaluated. Naturally, pre-best-path and IGP inserted cost communities are never compared directly.
The community ID identifies the community’s context. Perhaps you’ve assigned an ID of 10 to indicate the inverse bandwidth (i.e., lower is better) and an ID of 20 to indicate the latency of an egress link. It’s illogical to directly compare bandwidth-to-latency, although comparing bandwidth-to-bandwidth or latency-to-latency across different paths makes perfect sense. When a route has multiple cost communities applied, the lowest value is evaluated first, and the IDs range from 0 to 255 (unsigned 8-bit integer). Applying multiple cost communities to a single route is rare, and I haven’t observed it in production; I won’t detail it today.
The community value is a 32-bit unsigned integer ranging from 0 to 4,294,967,295. Interestingly, all 256 cost communities come with a default value of 2,147,483,647 (2^31 - 1), the midpoint of the range. Suppose there are two iBGP-learned routes that have equal attributes up to and including the IGP cost to the BGP next-hop. One route has a cost community with the IGP POI, an ID of 10, and a value of 3 billion. The second route has no cost community assigned. The best-path becomes the second route, because the default cost community value of ~2.1 billion is less than the explicit value of 3 billion.
Now that you understand the fundamentals of how cost communities operate, let’s examine a more interesting example. The topology below depicts 4 routers. R1, R2, and R3 are in AS 65123 with Intermediate System to Intermediate System (IS-IS) as the IGP. The entire topology is IPv6-only (you should be migrating away from IPv4!) but the same cost community logic applies to any BGP-supported address-family. R1 has iBGP sessions to R2 and R3, allowing it to learn routes from both. R2 and R3 have eBGP sessions to R4 in AS 65004, which advertises 6 different IPv6 prefixes from the 2001:db8::/32 documentation range into AS 65123. Each router has a router ID in the format of 10.0.0.X where X is the router number. We’ll focus on configuring cost communities on R2 then evaluating the best-path selection results on R1. From this point forward, I’m assuming you’re familiar with Cisco IOS routing constructs like prefix-lists, route-maps, and so on.
One other important note about the diagram: there are two links from R1 to R3. One is a high-speed link with a cost of 10 and the other is a slower backup link with a cost of 15. R1’s link to R2 also has a cost of 10, so in a steady-state network, R1 will have to break ties between egress paths via R2 and R3.
First, we’ll focus on the IGP POI using the 4 test prefixes shown. For brevity, I’ll refer to them as “prefix A”, “prefix B”, etc., as indicated by the right-most letter in the prefix. On R2, we’ll create a custom IPv6 prefix-list to match each one, allowing us to apply individualized, per-prefix treatment in the route-map. I’ve added descriptions to each route-map clause to explain the treatment of each route.
- a. Prefix A is permitted with no additional modification
- b. Prefix B uses local-preference, a traditional mechanism of influencing egress routing
- c. Prefix C uses an IGP-inserted cost community less (better) than the default
- d. Prefix D uses an IGP-inserted cost community greater (worse) than the default
The text below illustrates R3’s BGP configuration of interest. This includes the prefix-lists, route-map, and the application of the policy inbound from the R4 eBGP peering. Note that R2 does not customize any BGP attributes for any prefix.
# R3
ipv6 prefix-list PL_IPV6_A seq 5 permit 2001:DB8:A::/48
ipv6 prefix-list PL_IPV6_B seq 5 permit 2001:DB8:B::/48
ipv6 prefix-list PL_IPV6_C seq 5 permit 2001:DB8:C::/48
ipv6 prefix-list PL_IPV6_D seq 5 permit 2001:DB8:D::/48
route-map RM_BGP_R4_IN permit 10
description PERMIT WITH NO MODIFICATION
match ipv6 address prefix-list PL_IPV6_A
route-map RM_BGP_R4_IN permit 20
description SET HIGH LOCALPREF (TRADITIONAL)
match ipv6 address prefix-list PL_IPV6_B
set local-preference 200
route-map RM_BGP_R4_IN permit 30
description SET LOW COSTCOM (IGP POI)
match ipv6 address prefix-list PL_IPV6_C
set extcommunity cost igp 85 2000000000
route-map RM_BGP_R4_IN permit 40
description SET HIGH COSTCOM (IGP POI)
match ipv6 address prefix-list PL_IPV6_D
set extcommunity cost igp 85 3000000000
router bgp 65123
neighbor FC00:10:3:4::4 remote-as 65004
address-family ipv6
neighbor FC00:10:3:4::4 route-map RM_BGP_R4_IN in
Next, let’s head to R1 to evaluate the BGP best-path results. We’ll begin with Prefix A, which received no special treatment. R1 chooses R2 over R3 because everything is the same, up to and including the IGP cost to the BGP next-hop of 10. iBGP falls back to the arbitrary tie-breaker of lower BGP router ID, and 10.0.0.2 is less than 10.0.0.3, making R2 the winner.
R1#show bgp ipv6 unicast 2001:db8:a::/48
BGP routing table entry for 2001:DB8:A::/48, version 14
Paths: (2 available, best #2, table default)
Not advertised to any peer
Refresh Epoch 1
65004
FC00::3 (metric 10) from FC00::3 (10.0.0.3)
Origin IGP, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
65004
FC00::2 (metric 10) from FC00::2 (10.0.0.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Suppose your manager asks you to prefer R3 instead of R2 as a tie-breaker instead of relying on the BGP router ID. The goal is still to prefer the shortest IGP egress path out of the AS. You, being a seasoned BGP veteran, know that local-preference is usually a good tool to influence egress routing from your local AS. You apply a local-preference of 200 on Prefix B inbound on R3 (configuration displayed earlier), causing R1 to prefer R3 as the proper egress path. Here’s the proof that it worked. At this point, Prefix A is routing the wrong way and Prefix B is routing the right way, per our manager’s desire.
R1#show bgp ipv6 unicast 2001:db8:b::/48
BGP routing table entry for 2001:DB8:B::/48, version 15
Paths: (2 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
65004
FC00::3 (metric 10) from FC00::3 (10.0.0.3)
Origin IGP, metric 0, localpref 200, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
65004
FC00::2 (metric 10) from FC00::2 (10.0.0.2)
Origin IGP, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Let’s shut down the high-speed link between R1 and R3 (not shown). After IS-IS reconverges, R1 finds a new shortest path to R3 with a cost of 15. Examining the high-level BGP output for prefixes A and B, we see different routing choices. Prefix A still prefers R2, which is now the right way, because it’s the lowest cost egress path from our AS. Prefix B still prefers R3, which is now the wrong way, due to the higher IGP cost towards R3. Do you see why local-preference isn’t the right tool for this job?
R1#show bgp ipv6 unicast 2001:db8:b::/48
BGP routing table entry for 2001:DB8:B::/48, version 20
Paths: (2 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
65004
FC00::3 (metric 15) from FC00::3 (10.0.0.3)
Origin IGP, metric 0, localpref 200, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
65004
FC00::2 (metric 10) from FC00::2 (10.0.0.2)
Origin IGP, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Let’s apply an IGP-inserted cost community to Prefix C. We’ll use an arbitrary ID of 85 and a value of 2 billion, which is less than the default value of ~2.1 billion. This default value is assumed on all routes not carrying an IGP-inserted cost community with ID 85, which accurately describes the Prefix C advertisement from R3. Behind the scenes, I’ve restored the high-speed R1-R2 link. Reviewing the BGP output, we see that R3 is preferred over R2 despite their IGP costs to the BGP next-hops being the same, thanks to our cost community. Unlike Prefix A, we don’t rely on the router ID as a tie-breaker, and we correctly prefer R3 over R2.
R1#show bgp ipv6 unicast 2001:db8:c::/48
BGP routing table entry for 2001:DB8:C::/48, version 24
Paths: (2 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
65004
FC00::3 (metric 10) from FC00::3 (10.0.0.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: Cost:igp:85:2000000000 (default-147483647)
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
65004
FC00::2 (metric 10) from FC00::2 (10.0.0.2)
Origin IGP, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
How does Prefix C behave in the failure scenario? Let’s shut down the high-speed R1-R2 link again and re-evaluate (not shown). We already know Prefix B will continue to use R2 as the preferred egress point because local-preference is evaluated before IGP cost to the BGP next-hop. Since IGP-inserted cost communities are evaluated after IGP cost to the BGP next-hop, R1 correctly chooses R3 as the egress point in this failure scenario. The cost community is ignored because there was no tie to break; R3 is simply the better egress point according to IGP, and R1 should select it.
R1#show bgp ipv6 unicast 2001:db8:c::/48
BGP routing table entry for 2001:DB8:C::/48, version 21
Paths: (2 available, best #2, table default)
Not advertised to any peer
Refresh Epoch 1
65004
FC00::3 (metric 15) from FC00::3 (10.0.0.3)
Origin IGP, metric 0, localpref 100, valid, internal
Extended Community: Cost:igp:85:2000000000 (default-147483647)
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
65004
FC00::2 (metric 10) from FC00::2 (10.0.0.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
To quickly recap:
- a. Prefix A relied on the iBGP tie-breaker of lower router ID; chooses wrong path when network is stable
- b. Prefix B relied on local-preference; chooses wrong path when the network is unstable (R1-R2 link fails, or more broadly, the core topology changes leading to a IGP-based tiebreak)
- c. Prefix C relied on cost community; chooses the right path in both cases!
For completeness, I’ve added a cost community value of 3 billion to Prefix D. This illustrates the usefulness of having a non-zero default value; you can explicitly signal less desired paths in this way. After restoring the R1-R2 link, R1 chooses R2 over R3 because the default cost community of ~2.1 billion is less than R3’s value of 3 billion. I find it particularly helpful that Cisco IOS prints the plus/minus difference from the default value in the output, making it easy to visually compare.
R1#show bgp ipv6 unicast 2001:db8:d::/48
BGP routing table entry for 2001:DB8:D::/48, version 17
Paths: (2 available, best #2, table default)
Not advertised to any peer
Refresh Epoch 1
65004
FC00::3 (metric 10) from FC00::3 (10.0.0.3)
Origin IGP, metric 0, localpref 100, valid, internal
Extended Community: Cost:igp:85:3000000000 (default+852516353)
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
65004
FC00::2 (metric 10) from FC00::2 (10.0.0.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
The use-cases for pre-best-path cost communities are much more obscure. In fact, the only time I’ve ever seen it used in production is when Cisco’s Enhanced Interior Gateway Routing Protocol (EIGRP) is used as a Provider Edge to Customer Edge (PE-CE) routing protocol in Multiprotocol Label Switching (MPLS) networks. For those unfamiliar with MPLS, that’s a lot of new acronyms, and explaining the complex operations of this design would require many blog posts. Suffice it to say that the pre-best-path POI allows BGP to circumvent all other best-path steps. In this EIGRP case, the EIGRP metric is encoded into the cost community at each PE. Remote PEs will make their BGP best-path decisions based on the EIGRP metric before considering any BGP attributes. This allows the MPLS provider to act more like a transparent extension of the EIGRP network, helping to optimize customer routing from end to end.
I’m not going to set all this up (not today, at least), but I will demonstrate how the pre-best-path POI works using two simple examples. I’ve added Prefixes E and F to R6 and advertised them from AS 65004 to AS 65123. On R2, we’ll add two new clauses to our route-map with their corresponding prefix-lists. Prefix E uses a low local-preference of 50 paired with a low cost community of 2 billion. Prefix F performs the opposite action, using a high local-preference of 200 and a high cost community of 3 billion. R2, as always, does not make any adjustments to these prefixes when they are advertised to R1 using iBGP.
# R3
ipv6 prefix-list PL_IPV6_E seq 5 permit 2001:DB8:E::/48
ipv6 prefix-list PL_IPV6_F seq 5 permit 2001:DB8:F::/48
route-map RM_BGP_R4_IN permit 50
description SET LOW LOCALPREF AND LOW COSTCOM (PBP POI)
match ipv6 address prefix-list PL_IPV6_E
set local-preference 50
set extcommunity cost pre-bestpath 86 2000000000
route-map RM_BGP_R4_IN permit 60
description SET HIGH LOCALPREF AND HIGH COSTCOM (PBP POI)
match ipv6 address prefix-list PL_IPV6_F
set local-preference 200
set extcommunity cost pre-bestpath 86 3000000000
Let’s examine Prefix E first. R1 prefers R3 over R2 in this case. Despite the lower (less preferred) local-preference, R3’s path has a lower pre-best-path cost community than R2’s path, which uses the default value. Because these values are compared first (hence the POI’s name), the local-preference is not evaluated.
R1#show bgp ipv6 unicast 2001:db8:e::/48
BGP routing table entry for 2001:DB8:E::/48, version 18
Paths: (2 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
65004
FC00::3 (metric 10) from FC00::3 (10.0.0.3)
Origin IGP, metric 0, localpref 50, valid, internal, best
Extended Community: Cost:pre-bestpath:86:2000000000 (default-147483647)
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
65004
FC00::2 (metric 10) from FC00::2 (10.0.0.2)
Origin IGP, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Here’s the output from Prefix F, and I think you see where this is going. Despite having a higher local-preference (more preferred), R3’s higher cost community makes it less desirable than R2. In my experience the pre-best-path POI is rarely seen because it preempts the entire best-path algorithm. You may find it useful in corner cases where you want to compare routes using an administrative criterion that isn’t well represented by the standard BGP attributes. Consider stacking multiple cost communities (using multiple IDs, of course) to create a more complex selection process.
R1#show bgp ipv6 unicast 2001:db8:f::/48
BGP routing table entry for 2001:DB8:F::/48, version 19
Paths: (2 available, best #2, table default)
Not advertised to any peer
Refresh Epoch 1
65004
FC00::3 (metric 10) from FC00::3 (10.0.0.3)
Origin IGP, metric 0, localpref 200, valid, internal
Extended Community: Cost:pre-bestpath:86:3000000000 (default+852516353)
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
65004
FC00::2 (metric 10) from FC00::2 (10.0.0.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Believe it or not, there’s so much more to the cost community. What happens in a multipath environment? What about when BGP prefixes are aggregated and communities are compared/carried over? Is there any way to make it transitive across AS boundaries? These are discussions for another day, but I’d encourage you to explore this feature in your own lab. If you enjoyed this blog and my no-nonsense, tech-focused style of training, you’ll love my Cisco Advanced Routing series here at Pluralsight.
Reference Configurations
# R1
version 15.6
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
no ip icmp rate-limit unreachable
!
no ip domain lookup
ip cef
ipv6 unicast-routing
ipv6 cef
!
!
interface Loopback0
no ip address
ipv6 address FC00::1/128
!
interface Ethernet0/0
description TO R3 (FAST)
no ip address
ipv6 address FE80::1 link-local
ipv6 router isis 65123
isis network point-to-point
isis metric 10
!
interface Ethernet0/1
description TO R3 (SLOW)
no ip address
ipv6 address FE80::1 link-local
ipv6 router isis 65123
isis network point-to-point
isis metric 15
!
interface Ethernet0/2
description TO R2
no ip address
ipv6 address FE80::1 link-local
ipv6 router isis 65123
isis network point-to-point
isis metric 10
!
interface Ethernet0/3
no ip address
!
router isis 65123
net 49.0000.0000.0000.0001.00
is-type level-2-only
log-adjacency-changes all
passive-interface Loopback0
!
router bgp 65123
template peer-session IBGP
remote-as 65123
update-source Loopback0
exit-peer-session
!
bgp router-id 10.0.0.1
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor FC00::2 inherit peer-session IBGP
neighbor FC00::3 inherit peer-session IBGP
!
address-family ipv6
neighbor FC00::2 activate
neighbor FC00::3 activate
exit-address-family
!
end
# R2
version 15.6
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R2
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
!
no ip icmp rate-limit unreachable
!
no ip domain lookup
ip cef
ipv6 unicast-routing
ipv6 cef
!
!
interface Loopback0
no ip address
ipv6 address FC00::2/128
!
interface Ethernet0/0
description TO R4
no ip address
ipv6 address FE80::2 link-local
ipv6 address FC00:10:2:4::2/64
!
interface Ethernet0/1
no ip address
!
interface Ethernet0/2
description TO R1
no ip address
ipv6 address FE80::2 link-local
ipv6 router isis 65123
isis network point-to-point
isis metric 10
!
interface Ethernet0/3
no ip address
!
router isis 65123
net 49.0000.0000.0000.0002.00
is-type level-2-only
log-adjacency-changes all
passive-interface Loopback0
!
router bgp 65123
template peer-session IBGP
remote-as 65123
update-source Loopback0
exit-peer-session
!
bgp router-id 10.0.0.2
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor FC00::1 inherit peer-session IBGP
neighbor FC00:10:2:4::4 remote-as 65004
!
address-family ipv6
neighbor FC00::1 activate
neighbor FC00::1 send-community both
neighbor FC00::1 next-hop-self
neighbor FC00:10:2:4::4 activate
exit-address-family
!
end
# R3
version 15.6
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R3
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
!
no ip icmp rate-limit unreachable
!
!
no ip domain lookup
ip cef
ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
no ip address
ipv6 address FC00::3/128
!
interface Ethernet0/0
description TO R1 (FAST)
no ip address
ipv6 address FE80::3 link-local
ipv6 router isis 65123
isis network point-to-point
isis metric 10
!
interface Ethernet0/1
description TO R1 (SLOW)
no ip address
ipv6 address FE80::3 link-local
ipv6 router isis 65123
isis network point-to-point
isis metric 15
!
interface Ethernet0/2
description TO R4
no ip address
ipv6 address FE80::3 link-local
ipv6 address FC00:10:3:4::3/64
!
interface Ethernet0/3
no ip address
!
router isis 65123
net 49.0000.0000.0000.0003.00
is-type level-2-only
log-adjacency-changes all
passive-interface Loopback0
!
router bgp 65123
template peer-session IBGP
remote-as 65123
update-source Loopback0
exit-peer-session
!
bgp router-id 10.0.0.3
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor FC00::1 inherit peer-session IBGP
neighbor FC00:10:3:4::4 remote-as 65004
!
address-family ipv6
neighbor FC00::1 activate
neighbor FC00::1 send-community both
neighbor FC00::1 next-hop-self
neighbor FC00:10:3:4::4 activate
neighbor FC00:10:3:4::4 route-map RM_BGP_R4_IN in
exit-address-family
!
ipv6 prefix-list PL_IPV6_A seq 5 permit 2001:DB8:A::/48
ipv6 prefix-list PL_IPV6_B seq 5 permit 2001:DB8:B::/48
ipv6 prefix-list PL_IPV6_C seq 5 permit 2001:DB8:C::/48
ipv6 prefix-list PL_IPV6_D seq 5 permit 2001:DB8:D::/48
ipv6 prefix-list PL_IPV6_E seq 5 permit 2001:DB8:E::/48
ipv6 prefix-list PL_IPV6_F seq 5 permit 2001:DB8:F::/48
!
route-map RM_BGP_R4_IN permit 10
description PERMIT WITH NO MODIFICATION
match ipv6 address prefix-list PL_IPV6_A
!
route-map RM_BGP_R4_IN permit 20
description SET HIGH LOCALPREF (TRADITIONAL)
match ipv6 address prefix-list PL_IPV6_B
set local-preference 200
!
route-map RM_BGP_R4_IN permit 30
description SET LOW COSTCOM (IGP POI)
match ipv6 address prefix-list PL_IPV6_C
set extcommunity cost igp 85 2000000000
!
route-map RM_BGP_R4_IN permit 40
description SET HIGH COSTCOM (IGP POI)
match ipv6 address prefix-list PL_IPV6_D
set extcommunity cost igp 85 3000000000
!
route-map RM_BGP_R4_IN permit 50
description SET LOW LOCALPREF AND LOW COSTCOM (PBP POI)
match ipv6 address prefix-list PL_IPV6_E
set local-preference 50
set extcommunity cost pre-bestpath 86 2000000000
!
route-map RM_BGP_R4_IN permit 60
description SET HIGH LOCALPREF AND HIGH COSTCOM (PBP POI)
match ipv6 address prefix-list PL_IPV6_F
set local-preference 200
set extcommunity cost pre-bestpath 86 3000000000
!
end
# R4
version 15.6
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R4
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
!
no ip icmp rate-limit unreachable
!
!
no ip domain lookup
ip cef
ipv6 unicast-routing
ipv6 cef
!
!
interface Loopback0
no ip address
ipv6 address 2001:DB8:A::/48
ipv6 address 2001:DB8:B::/48
ipv6 address 2001:DB8:C::/48
ipv6 address 2001:DB8:D::/48
ipv6 address 2001:DB8:E::/48
ipv6 address 2001:DB8:F::/48
!
interface Ethernet0/0
description TO R2
no ip address
ipv6 address FE80::4 link-local
ipv6 address FC00:10:2:4::4/64
!
interface Ethernet0/1
no ip address
!
interface Ethernet0/2
description TO R3
no ip address
ipv6 address FE80::4 link-local
ipv6 address FC00:10:3:4::4/64
!
interface Ethernet0/3
no ip address
!
router bgp 65004
bgp router-id 10.0.0.4
bgp log-neighbor-changes
neighbor FC00:10:2:4::2 remote-as 65123
neighbor FC00:10:3:4::3 remote-as 65123
!
address-family ipv6
network 2001:DB8:A::/48
network 2001:DB8:B::/48
network 2001:DB8:C::/48
network 2001:DB8:D::/48
network 2001:DB8:E::/48
network 2001:DB8:F::/48
neighbor FC00:10:2:4::2 activate
neighbor FC00:10:3:4::3 activate
exit-address-family
!
end