Influencing Ingress BGP Routing using Conditional Route Advertisement

Influencing Ingress BGP Routing using Conditional Route Advertisement

This blog explores an alternative method to ensure ingress traffic flows in a strict primary/backup manner without relying on techniques like AS-path prepending, local preference, or longest-match routing.

Author: Nicholas Russo


I recently authored a Pluralsight blog post describing how to implement BGP ingress traffic-engineering using communities and local-preference. While that remains a popular and effective method, it isn’t always available.

Common reasons include:

  1. Neither of the upstream providers offer this option
  2. The providers lack a direct peering, limiting the influence of any local-preference adjustments

This blog explores an alternative method to ensure ingress traffic flows in a strict primary/backup manner without relying on techniques like AS-path prepending, local preference, or longest-match routing. The solution is known as BGP conditional route advertisement and while many others have blogged about this before, few have addressed the design considerations and business applicability.

Here’s the topology. It’s similar to the BGP community/local-preference blog with some minor changes. R1 is a small business with two Internet uplinks, one through R2 and one through R4. R4 represents a large national carrier (Verizon, British Telecom, etc.) that has a direct peering to Google, represented by R6. The IPv6 addresses hosted by R6 are the public Google DNS servers, which serve as test endpoints. The other path between R1 and R6 transits R2, R3, and R5. The network runs IPv6 using the RFC 3849 documentation prefix. All concepts discussed in this blog apply to IPv4 as well.

Influencing Ingress BGP Routing using Conditional Route Advertisement

Suppose that R1 is located in a rural area and that R2 represents a local ISP with a small geographic footprint. R2 relies on R3 for transit, and R3 relies on R5 (perhaps another national carrier) for transit, ultimately reaching Google. The primary R1-R2 link is higher speed than the backup R1-R4 link. Furthermore, The R1-R4 link has a high monetary cost, perhaps being cellular-based with a data cap. It should only be used when R1 cannot reach the Internet via R2 (link failure, routing problem, etc.)

A quick sidebar: some of you may be familiar with the “backup interface” concept in which an interface is shutdown (thus incurring no data-based monetary expense) if the primary interface is up.

This solution could technically solve the BGP ingress routing problem, but has some serious drawbacks:

  1. It only tracks interface up/down status, not the presence of BGP routes learned by the ISP
  2. The backup interface has to come up, and the BGP session has to form from the beginning, which can be very slow
# R1 configuration example; not actually configured
interface Ethernet0/1
backup interface Ethernet0/0

BGP conditional advertisement provides a compromise solution between complex BGP attribute manipulation (AS-path prepending, communities/local-preference, etc.) and a simple “backup interface” design. The R1-R4 link and its corresponding BGP session remain up, incurring minimal cost for BGP keepalives, while also guaranteeing the correct ingress routing design in a simple, effective manner.

For added realism, R1 will receive only receive an IPv6 default route (::/0) from each ISP. This should be the only route received, and R1 should unconditionally prefer R2 for egress routing. If we don’t ensure this, R1 will prefer R4 due to its default route having a shorter AS path length compared to R2.

R1#show bgp ipv6 unicast ::/0
BGP routing table entry for ::/0, version 6
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Refresh Epoch 3
  65002 65003 65005 65006
    2001:DB8:1:2::2 (FE80::2) from 2001:DB8:1:2::2 (192.0.2.2)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 2
  65004 65006
    2001:DB8:1:4::4 (FE80::4) from 2001:DB8:1:4::4 (192.0.2.4)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
Influencing Ingress BGP Routing using Conditional Route Advertisement

Preferring R2 over R4 for egress routing is easily achieved using local-preference applied inbound on R2’s default route. The snippet below accomplishes this using a pair of route maps. These route-maps explicitly apply different local-preferences to each default route, avoiding any reliance on default local-preference configurations. Note that the route-maps only permit the default route, so if an ISP advertised longer matches for whatever reason, R1 would reject them. Such a mistake by R4 would divert egress traffic over the R1-R4 link, sapping money from our business.

# R1 configuration
ipv6 prefix-list PL_DEFAULT_ONLY seq 5 permit ::/0

route-map RM_BGP_R2_IN permit 10
 description ONLY ALLOW DEFAULT WITH HIGH LOCALPREF
 match ipv6 address prefix-list PL_DEFAULT_ONLY
 set local-preference 200

route-map RM_BGP_R4_IN permit 10
 description ONLY ALLOW DEFAULT WITH LOW LOCALPREF
 match ipv6 address prefix-list PL_DEFAULT_ONLY
 set local-preference 100

router bgp 65001
 address-family ipv6
  neighbor 2001:DB8:1:2::2 route-map RM_BGP_R2_IN in
  neighbor 2001:DB8:1:4::4 route-map RM_BGP_R4_IN in

R1#show bgp ipv6 unicast ::/0
BGP routing table entry for ::/0, version 7
Paths: (2 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 5
  65002 65003 65005 65006
    2001:DB8:1:2::2 (FE80::2) from 2001:DB8:1:2::2 (192.0.2.2)
      Origin IGP, localpref 200, valid, external, best
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 2
  65004 65006
    2001:DB8:1:4::4 (FE80::4) from 2001:DB8:1:4::4 (192.0.2.4)
      Origin IGP, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
Influencing Ingress BGP Routing using Conditional Route Advertisement

Now, onto the fun part. R1 originates 2001:db8:1111::/48 into BGP, which is the longest prefix that may exist on the IPv6 Internet. This is the only prefix R1 should advertise to the ISPs, and a best practice, you should apply an outbound route-map to guarantee this. This also protects against R1 becoming a transit node between R2 and R4. Additionally, some routers introduce the concept of a Minimum Route Advertisement Interval (MRAI) that governs BGP update batching. On global table eBGP sessions, a Cisco IOS router throttles updates once every 30 seconds by default to prevent excessive BGP control-plane churn. For VRF-aware eBGP sessions and all iBGP sessions, this timer defaults to 0. Juniper, by contrast, has an “out-delay” timer that serves a similar purpose, but this is set to 0 by default for all peers. We’ll set this timer to 0 to ensure R1 advertises its local prefix as soon as it can. Note that the use of templates in this snippet can reduce typing by applying the same configuration items to both upstream ISPs as there is no difference in outbound BGP policy.

# R1 configuration
ipv6 prefix-list PL_LOCAL_PREFIX seq 5 permit 2001:DB8:1111::/48

route-map RM_BGP_LOCAL_PREFIX_OUT permit 10
 description ONLY ALLOW LOCAL /48 PREFIX
 match ipv6 address prefix-list PL_LOCAL_PREFIX

router bgp 65001
 template peer-policy IPV6
  route-map RM_BGP_LOCAL_PREFIX_OUT out
  advertisement-interval 0
 exit-peer-policy
 address-family ipv6
  network 2001:DB8:1111::/48
  neighbor 2001:DB8:1:2::2 inherit peer-policy IPV6
  neighbor 2001:DB8:1:4::4 inherit peer-policy IPV6

A timer that is seldom adjusted is the BGP scan-time. This BGP scanner is a periodic process that checks each route in the BGP table for best-path accuracy and next-hop accessibility. Often, this timer is overlooked thanks to BGP next-hop tracking (NHT). NHT is event-driven and reacts much more quickly than the BGP scanner, which runs once every 60 seconds by default. However, in my personal testing on lightweight lab images (IOU-based), NHT does not trigger when the only remaining route is withdrawn; there are no other candidates routes to select, so I can understand the short-circuit logic.

We want R1 to quickly acknowledge when it loses its default route from R2, so we’ll reduce the BGP scan-time to 5 seconds. This is often a bad idea but consider our network. R1 only learns two BGP routes in total; a default route from each ISP. R1 only originates a single /48 prefix into BGP. With a BGP table of only 3 routes, applying a minimal scan-time works fine. It’s important to perform these risk assessments based on your actual network conditions and not simply a best practices manifesto!

# R1 configuration
router bgp 65001
 address-family ipv6
  bgp scan-time 5

R1#show bgp ipv6 unicast summary | include scan
BGP activity 2/0 prefixes, 3/0 paths, scan interval 5 secs

To enable conditional route advertisement, we need a pair of route-maps. The first route-map identifies the prefixes to advertise to a given peer. We can recycle the prefix-list used in the outbound filtering route-map here, since R1 is only offering a single, indivisible /48 prefix to each ISP. The second route-map identifies the condition upon which the prefixes matched in the first route-map are advertised. There are two options:

  1. exist-map: Advertise the specified prefixes when the target prefixes exist in BGP
  2. non-exist-map: Advertise the specified prefixes when the target prefixes do not exist in BGP

The correct choice for our design is the non-exist-map. We want R1 to advertise its /48 to R4 when it does not have a default route from R2 in the BGP table. The absence of this route could be due to an R1-R2 link failure, a filtering misconfiguration on either router, or any number of routing advertisement problems. When the failure occurs, R1 will detect it in up to 5 seconds (thanks to the scan-time adjustment) and send a BGP update to R4 containing its /48 prefix.

Note that the non-exist-map contains an AS-path access-list matching ^65002_ as a regular expression. The ^ means beginning of line and the _ means any whitespace character. This effectively matches any route received from AS 65002, the rural ISP represented by R2, regardless of origin or overall path length. This multi-step match is important as it ensures R1 matches R2’s specific default route and not simply any default route; recall that R4 also advertises a default route to R1.

# R1 configuration

ip as-path access-list 1 permit ^65002_

route-map RM_BGP_FROM_R2_AS permit 10
 description ONLY MATCH DEFAULT FROM R2 AS WITH REGEX
 match as-path 1
 match ipv6 address prefix-list PL_DEFAULT_ONLY

router bgp 65001
 address-family ipv6
  neighbor 2001:DB8:1:4::4 advertise-map RM_BGP_LOCAL_PREFIX_OUT non-exist-map RM_BGP_FROM_R2_AS


R1#show bgp ipv6 unicast neighbors 2001:db8:1:2::2 advertised-routes | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>   2001:DB8:1111::/48
                       ::                       0         32768 i
Total number of prefixes 1


R1#show bgp ipv6 unicast neighbors 2001:db8:1:4::4 advertised-routes
Total number of prefixes 0


R1#show bgp ipv6 unicast neighbors 2001:db8:1:4::4 | include Condition-map
  Condition-map RM_BGP_FROM_R2_AS, Advertise-map RM_BGP_LOCAL_PREFIX_OUT, status: Withdraw
Influencing Ingress BGP Routing using Conditional Route Advertisement

When a failure occurs, R1’s BGP scanner detects it and advertises its local /48 to R4 as previously discussed. Keep in mind the MRAI concept from earlier; this is a per-neighbor timer and is locally configured on each device. If R4 is a Cisco device running global eBGP with R6 (Google), R4 will not advertise the route for 30 seconds. This can seriously slow convergence and the delay may be unacceptable to some customers. For the purpose of this blog, all other MRAI timers have been set to 0 to better test the conditional advertisement failover technique. You’ll want to test this in your own lab and in production before committing to it!

# R2 configuration
interface Ethernet0/1
 shutdown

%BGP-5-ADJCHANGE: neighbor 2001:DB8:1:2::1 Down Interface flap


R1#show bgp ipv6 unicast neighbors 2001:db8:1:4::4 advertised-routes | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>   2001:DB8:1111::/48
                       ::                       0         32768 i
Total number of prefixes 1


R1#show bgp ipv6 unicast neighbors 2001:db8:1:4::4 | include Condition-map
  Condition-map RM_BGP_FROM_R2_AS, Advertise-map RM_BGP_LOCAL_PREFIX_OUT, status: Advertise
Influencing Ingress BGP Routing using Conditional Route Advertisement

When designing a network, it’s important to test down-events as well as up-events. When the R1-R2 link is restored and the BGP scanner detects that R1 has learned a default route from R2, R1 sends an explicit withdrawal to R4. Remember, R1 is only allowed to advertise that /48 prefix when R2’s default route does not exist in its BGP table.

# R2 configuration
interface Ethernet0/1
 no shutdown

%BGP-5-ADJCHANGE: neighbor 2001:DB8:1:2::1 Up


R1#show bgp ipv6 unicast neighbors 2001:db8:1:2::2 advertised-routes | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>   2001:DB8:1111::/48
                       ::                       0         32768 i
Total number of prefixes 1


R1#show bgp ipv6 unicast neighbors 2001:db8:1:4::4 advertised-routes
Total number of prefixes 0


R1#show bgp ipv6 unicast neighbors 2001:db8:1:4::4 | include Condition-map
  Condition-map RM_BGP_FROM_R2_AS, Advertise-map RM_BGP_LOCAL_PREFIX_OUT, status: Withdraw
Influencing Ingress BGP Routing using Conditional Route Advertisement

As a final optimization, consider using Bidirectional Forwarding Detection (BFD) with your primary carrier. This will detect link failures more quickly than waiting for BGP keepalives and is especially useful in networks with intermediate layer-1 devices such as media converters. Not all carriers offer this capability, so be sure to ask ahead of time.

# R1 configuration
interface Ethernet0/1
 bfd interval 50 min_rx 50 multiplier 3

router bgp 65001
 neighbor 2001:DB8:1:2::2 fall-over bfd single-hop


# R2 configuration
interface Ethernet0/1
 bfd interval 50 min_rx 50 multiplier 3

router bgp 65002
 neighbor 2001:DB8:1:2::1 fall-over bfd single-hop

For those interested in the precise sequence of events, here are some debug logs that detail the failure and restoration events. Note that convergence occurs within a matter of seconds, which is often an acceptable time frame for small branch sites (especially in rural settings).

# R2; disable R1-R2 link
interface Ethernet0/1
 shutdown


R1#debug bgp ipv6 unicast updates
BGP updates debugging is on for address family: IPv6 Unicast

*Oct 31 14:42:16.889: %BFDFSM-6-BFD_SESS_DOWN: BFD-SYSLOG: BFD session ld:1 handle:1,is going Down Reason: DETECT TIMER EXPIRED
*Oct 31 14:42:16.899: %BGP-5-ADJCHANGE: neighbor 2001:DB8:1:2::2 Down BFD adjacency down
*Oct 31 14:42:16.899: BGP(1): Revise route installing ::/0 -> 2001:DB8:1:4::4 (FE80::4) to IPv6 default table


*Oct 31 14:42:18.178: BPG(1): Condition RM_BGP_FROM_R2_AS changes to Advertise
*Oct 31 14:42:18.178: BGP(1): net 2001:DB8:1111::/48 matches ADV MAP RM_BGP_LOCAL_PREFIX_OUT: bump version to 16
*Oct 31 14:42:18.184: BGP(1): 2001:DB8:1111::/48 route sourced locally
*Oct 31 14:42:18.184: BGP: topo global:IPv6 Unicast:base Remove_fwdroute for 2001:DB8:1111::/48
*Oct 31 14:42:18.184: BGP(1): (base) 2001:DB8:1:4::4 send UPDATE (format) 2001:DB8:1111::/48, next 2001:DB8:1:4::1
# R2; enable R1-R2 link
interface Ethernet0/1
 no shutdown


R1#debug bgp ipv6 unicast updates
BGP updates debugging is on for address family: IPv6 Unicast

*Oct 31 14:42:47.410: %BFD-6-BFD_SESS_CREATED: BFD-SYSLOG: bfd_session_created, neigh 2001:DB8:1:2::2 proc:BGP, idb:Ethernet0/1 handle:1 act
*Oct 31 14:42:47.410: %BGP-5-ADJCHANGE: neighbor 2001:DB8:1:2::2 Up
*Oct 31 14:42:47.413: BGP(1): (base) 2001:DB8:1:2::2 send UPDATE (format) 2001:DB8:1111::/48, next 2001:DB8:1:2::1, metric 0, path Local
*Oct 31 14:42:47.413: BGP: nbr_topo global 2001:DB8:1:2::2 IPv6 Unicast:base (0xEEA3EFA0:1) rcvd Refresh Start-of-RIB
*Oct 31 14:42:47.413: BGP: nbr_topo global 2001:DB8:1:2::2 IPv6 Unicast:base (0xEEA3EFA0:1) refresh_epoch is 2

*Oct 31 14:42:47.414: BGP(1): 2001:DB8:1:2::2 rcvd UPDATE w/ attr: nexthop 2001:DB8:1:2::2 (FE80::2), merged path 65002 65003 65005 65006,
*Oct 31 14:42:47.414: BGP(1): 2001:DB8:1:2::2 rcvd ::/0
*Oct 31 14:42:47.414: BGP: nbr_topo global 2001:DB8:1:2::2 IPv6 Unicast:base (0xEEA3EFA0:1) rcvd Refresh End-of-RIB
*Oct 31 14:42:47.420: BGP(1): Revise route installing ::/0 -> 2001:DB8:1:2::2 (FE80::2) to IPv6 default table
*Oct 31 14:42:47.920: %BFDFSM-6-BFD_SESS_UP: BFD-SYSLOG: BFD session ld:1 handle:1 is going UP


*Oct 31 14:42:48.411: BPG(1): Condition RM_BGP_FROM_R2_AS changes to Withdraw
*Oct 31 14:42:48.411: BGP(1): net 2001:DB8:1111::/48 matches ADV MAP RM_BGP_LOCAL_PREFIX_OUT: bump version to 18
*Oct 31 14:42:48.416: BGP(1): 2001:DB8:1111::/48 route sourced locally
*Oct 31 14:42:48.416: BGP: topo global:IPv6 Unicast:base Remove_fwdroute for 2001:DB8:1111::/48
*Oct 31 14:42:48.416: BGP(1): (base) 2001:DB8:1:4::4 send unreachable (format) 2001:DB8:1111::/48
*Oct 31 14:42:48.418: BGP(1): 2001:DB8:1:4::4 rcv UPDATE about 2001:DB8:1111::/48 -- withdrawn

To summarize: if you want to influence ingress traffic flow with BGP and none of the BGP attribute-based options are available to you, consider using conditional route advertisement. It’s excellent for small branch sites that can tolerate a few seconds of downtime with the benefit of massive cost savings by avoiding pay-by-the-byte backup links. 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 2001:DB8:1111::1/48
!
interface Ethernet0/0
 no ip address
 ipv6 address FE80::1 link-local
 ipv6 address 2001:DB8:1:4::1/64
!
interface Ethernet0/1
 no ip address
 ipv6 address FE80::1 link-local
 ipv6 address 2001:DB8:1:2::1/64
 bfd interval 50 min_rx 50 multiplier 3
!
interface Ethernet0/2
 no ip address
!
interface Ethernet0/3
 no ip address
!
router bgp 65001
 template peer-policy IPV6
  route-map RM_BGP_LOCAL_PREFIX_OUT out
  advertisement-interval 0
 exit-peer-policy
 !
 bgp router-id 192.0.2.1
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 2001:DB8:1:2::2 remote-as 65002
 neighbor 2001:DB8:1:2::2 fall-over bfd single-hop
 neighbor 2001:DB8:1:4::4 remote-as 65004
 !
 address-family ipv6
  bgp scan-time 5
  network 2001:DB8:1111::/48
  neighbor 2001:DB8:1:2::2 activate
  neighbor 2001:DB8:1:2::2 inherit peer-policy IPV6
  neighbor 2001:DB8:1:2::2 route-map RM_BGP_R2_IN in
  neighbor 2001:DB8:1:4::4 activate
  neighbor 2001:DB8:1:4::4 advertise-map RM_BGP_LOCAL_PREFIX_OUT non-exist-map RM_BGP_FROM_R2_AS
  neighbor 2001:DB8:1:4::4 inherit peer-policy IPV6
  neighbor 2001:DB8:1:4::4 route-map RM_BGP_R4_IN in
 exit-address-family
!
ip forward-protocol nd
!
ip bgp-community new-format
ip as-path access-list 1 permit ^65002_
!
!
ipv6 prefix-list PL_DEFAULT_ONLY seq 5 permit ::/0
!
ipv6 prefix-list PL_LOCAL_PREFIX seq 5 permit 2001:DB8:1111::/48
route-map RM_BGP_FROM_R2_AS permit 10
 description ONLY MATCH DEFAULT FROM R2 AS WITH REGEX
 match as-path 1
 match ipv6 address prefix-list PL_DEFAULT_ONLY
!
route-map RM_BGP_LOCAL_PREFIX_OUT permit 10
 description ONLY ALLOW LOCAL /48 PREFIX
 match ipv6 address prefix-list PL_LOCAL_PREFIX
!
route-map RM_BGP_R2_IN permit 10
 description ONLY ALLOW DEFAULT WITH HIGH LOCALPREF
 match ipv6 address prefix-list PL_DEFAULT_ONLY
 set local-preference 200
!
route-map RM_BGP_R4_IN permit 10
 description ONLY ALLOW DEFAULT WITH LOW LOCALPREF
 match ipv6 address prefix-list PL_DEFAULT_ONLY
 set local-preference 100
!
!
!
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 Ethernet0/0
 no ip address
 ipv6 address FE80::2 link-local
 ipv6 address 2001:DB8:2:3::2/64
!
interface Ethernet0/1
 no ip address
 ipv6 address FE80::2 link-local
 ipv6 address 2001:DB8:1:2::2/64
 bfd interval 50 min_rx 50 multiplier 3
!
interface Ethernet0/2
 no ip address
!
interface Ethernet0/3
 no ip address
!
router bgp 65002
 bgp router-id 192.0.2.2
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 2001:DB8:1:2::1 remote-as 65001
 neighbor 2001:DB8:1:2::1 fall-over bfd single-hop
 neighbor 2001:DB8:2:3::3 remote-as 65003
 !
 address-family ipv6
  neighbor 2001:DB8:1:2::1 activate
  neighbor 2001:DB8:1:2::1 advertisement-interval 0
  neighbor 2001:DB8:2:3::3 activate
  neighbor 2001:DB8:2:3::3 advertisement-interval 0
 exit-address-family
!
ip forward-protocol nd
!
ip bgp-community new-format
!
!
!
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 2001:DB8::3/128
!
interface Ethernet0/0
 no ip address
 ipv6 address FE80::3 link-local
 ipv6 address 2001:DB8:2:3::3/64
!
interface Ethernet0/1
 no ip address
!
interface Ethernet0/2
 no ip address
 ipv6 address FE80::3 link-local
 ipv6 address 2001:DB8:3:5::3/64
!
interface Ethernet0/3
 no ip address
!
router bgp 65003
 bgp router-id 192.0.2.3
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 2001:DB8:2:3::2 remote-as 65002
 neighbor 2001:DB8:3:5::5 remote-as 65005
 !
 address-family ipv6
  neighbor 2001:DB8:2:3::2 activate
  neighbor 2001:DB8:2:3::2 advertisement-interval 0
  neighbor 2001:DB8:3:5::5 activate
  neighbor 2001:DB8:3:5::5 advertisement-interval 0
 exit-address-family
!
ip forward-protocol nd
!
ip bgp-community new-format
!
!
!
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::4/128
!
interface Ethernet0/0
 no ip address
 ipv6 address FE80::4 link-local
 ipv6 address 2001:DB8:1:4::4/64
!
interface Ethernet0/1
 no ip address
!
interface Ethernet0/2
 no ip address
 ipv6 address FE80::4 link-local
 ipv6 address 2001:DB8:4:6::4/64
!
interface Ethernet0/3
 no ip address
!
router bgp 65004
 bgp router-id 192.0.2.4
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 2001:DB8:1:4::1 remote-as 65001
 neighbor 2001:DB8:4:6::6 remote-as 65006
 !
 address-family ipv6
  neighbor 2001:DB8:1:4::1 activate
  neighbor 2001:DB8:1:4::1 advertisement-interval 0
  neighbor 2001:DB8:4:6::6 activate
  neighbor 2001:DB8:4:6::6 advertisement-interval 0
 exit-address-family
!
ip forward-protocol nd
!
ip bgp-community new-format
!
!
!
end
# R5
version 15.6
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R5
!
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::5/128
!
interface Ethernet0/0
 no ip address
 ipv6 address FE80::5 link-local
 ipv6 address 2001:DB8:5:6::5/64
!
interface Ethernet0/1
 no ip address
!
interface Ethernet0/2
 no ip address
 ipv6 address FE80::5 link-local
 ipv6 address 2001:DB8:3:5::5/64
!
interface Ethernet0/3
 no ip address
 ipv6 address FE80::5 link-local
 ospfv3 1 ipv6 network point-to-point
!
router bgp 65005
 bgp router-id 192.0.2.5
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 2001:DB8:3:5::3 remote-as 65003
 neighbor 2001:DB8:5:6::6 remote-as 65006
 !
 address-family ipv6
  neighbor 2001:DB8:3:5::3 activate
  neighbor 2001:DB8:3:5::3 advertisement-interval 0
  neighbor 2001:DB8:5:6::6 activate
  neighbor 2001:DB8:5:6::6 advertisement-interval 0
 exit-address-family
!
ip forward-protocol nd
!
ip bgp-community new-format
!
!
!
end
# R6
version 15.6
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R6
!
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:4860:4860::8844/128
 ipv6 address 2001:4860:4860::8888/128
!
interface Ethernet0/0
 no ip address
 ipv6 address FE80::6 link-local
 ipv6 address 2001:DB8:5:6::6/64
!
interface Ethernet0/1
 no ip address
!
interface Ethernet0/2
 no ip address
 ipv6 address FE80::6 link-local
 ipv6 address 2001:DB8:4:6::6/64
!
interface Ethernet0/3
 no ip address
!
router bgp 65006
 bgp router-id 192.0.2.6
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 2001:DB8:4:6::4 remote-as 65004
 neighbor 2001:DB8:5:6::5 remote-as 65005
 !
 address-family ipv6
  neighbor 2001:DB8:4:6::4 activate
  neighbor 2001:DB8:4:6::4 default-originate
  neighbor 2001:DB8:4:6::4 advertisement-interval 0
  neighbor 2001:DB8:5:6::5 activate
  neighbor 2001:DB8:5:6::5 default-originate
  neighbor 2001:DB8:5:6::5 advertisement-interval 0
 exit-address-family
!
ip forward-protocol nd
!
ip bgp-community new-format
!
!
!
end


Related tags:

it-ops   networking   cisco  
About the author

Nicholas (Nick) Russo, CCDE #20160041 and CCIE #42518, is an internationally recognized expert in IP/MPLS networking and design. To grow his skillset, Nick has been focused advancing Network DevOps via automation for his clients. Recently, Nick has been sharing his knowledge through online video training and speaking at industry conferences. Nick also holds a Bachelor’s of Science in Computer Science from the Rochester Institute of Technology (RIT). Nick lives in Maryland, USA with his wife, Carla, and daughter, Olivia.

10-day free trial

Sign Up Now