The previous
configurations and description applies to border leaf topologies with
full-meshed peering with the DC edge routers. Full-meshed connectivity between
border leaf and DC edge router along with node redundancy is recommended, as
this topology supports the highest level of redundancy. However there are
certain deployments, where the full-meshed approach cannot be deployed.
For example, consider
a case where the physical installation of the border leaf nodes and DC edge
routers are in different buildings and you only have limited fiber available.
Such topologies, where each border leaf has only a single link to the DC edge
router is often called U-shape.
By default, the border
leaf when using default route configuration according to option 1 (default
route injection for all VRF with default-information originate always
configured under the VPNv4/6 address family) injects the default route in the
fabric independent if the external link towards the DC edge router is down or
up.
In U-shape topologies
this could cause blackholing for certain flows, as the traffic sourced on the
leaf switch is hashed along the two default routes (ECMP) injected by the two
border leaf nodes.
Cisco NX-OS version
7.2(0)D1(1) or 7.2(0)N1(1) or later is required on the border leaf as this
software version supports the U-shape topology. The DCNM 7.2(1) with the V3
POAP templates (for example, Fabric_N5600_N6K_BorderLeaf_v3) provides the
required configuration.
The border leaf POAP
template provides the required configuration with the specific route-maps to
avoid blackholing as shown below.
ip prefix-list default-route seq 5 permit 0.0.0.0/0 le 1
ipv6 prefix-list default-route-v6 seq 5 permit 0::/0
route-map DEFAULT-ROUTE-MODIFY permit 100
match ip address prefix-list default-route
set local-preference 50
route-map DEFAULT-ROUTE-MODIFY permit 1000
router bgp 65000
!Peering to the first RR
neighbor 44.2.0.101 remote-as 65000
address-family ipv4 unicast
send-community both
route-map DEFAULT-ROUTE-MODIFY in
next-hop-self
address-family ipv6 unicast
send-community both
route-map DEFAULT-ROUTE-MODIFY-V6 in
next-hop-self
address-family vpnv4 unicast
send-community both
route-map DEFAULT-ROUTE-MODIFY in
address-family vpnv6 unicast
send-community both
route-map DEFAULT-ROUTE-MODIFY-V6 in
address-family ipv4 mvpn
send-community both
address-family ipv6 mvpn
send-community both
!Peering to the second RR
neighbor 44.2.0.144 remote-as 65000
address-family ipv4 unicast
send-community both
route-map DEFAULT-ROUTE-MODIFY in
next-hop-self
address-family ipv6 unicast
send-community both
route-map DEFAULT-ROUTE-MODIFY-V6 in
next-hop-self
address-family vpnv4 unicast
send-community both
route-map DEFAULT-ROUTE-MODIFY in
address-family vpnv6 unicast
send-community both
route-map DEFAULT-ROUTE-MODIFY-V6 in
address-family ipv4 mvpn
send-community both
address-family ipv6 mvpn
send-community both
Note |
The route-map
'deny-default-route' as shown in the previous section is replaced by the
route-map 'DEFAULT-ROUTE-MODIFY'.
|
The route-map
"DEFAULT-ROUTE-MODIFY" along the additional BGP route-target import statement
65000:9999 (same as on the interior leaf) will re-import the default route
advertised by the other border leaf. This default route is imported per
specific tenant with a lower local preference and is only installed in the
forwarding table when the external learnt default route from the DC edge router
is unavailable.
At border leaf,
within every tenant:
vrf context CiscoLive:Part4
vni 65004
rd auto
address-family ipv4 unicast
route-target both auto
route-target import 65000:9999
vrf context CiscoLive:Part3
vni 65005
rd auto
address-family ipv4 unicast
route-target both auto
route-target import 65000:9999
Feedback