L3VPN Redistribution
Configuration Steps
- Configure the VRFs
- Configure the RDs
- Configure the import/export RTs
- Assign the PE=>CE interfaces to VRFs
- Configure IGP/BGP between PE-CE
- Configure MP-BGP between PEs
- Mutually redistribute between MP-BGP and the PE-CE IGP
BGP<=>RIP
RIP=>BGP
RIP metric => BGP MED (auto)
RIP=>BGP=>RIP
RIP metric => BGP MED => RIP metric (auto)
OTHER=>BGP=>RIP
BGP X => RIP metric (manual)
If "auto" doesn't work (for whatever reason), you can trying clearing the vrf routing table on the PE or you can use the following to set manually the RIP metric:
- redistribute bgp 100 metric transparent
- redistribute bgp 100 metric X
- redistribute bgp 100 route-map X
If version 2 is to be used, then it must be defined under the ipv4 vrf address-family on the PE.
RIP metric = hops (0-16)
Configuration
IOS
router rip
address-family ipv4 vrf VPN
redistribute bgp 200
!
router bgp 100
address-family ipv4 vrf VPN
redistribute rip
IOS-XR
router rip
vrf VPN
redistribute bgp 200
!
router bgp 200
vrf VPN
address-family ipv4 unicast
redistribute rip
BGP<=>EIGRP
EIGRP=>BGP
EIGRP composite metric => BGP MED (auto)
EIGRP vector metrics => BGP Extended Cost Community (auto)
EIGRP=>BGP=>EIGRP
EIGRP composite metric => BGP MED => EIGRP composite metric (auto)
EIGRP vector metrics => BGP Extended Cost Community => EIGRP vector metrics (auto)
original internal EIGRP routes appear as internal EIGRP routes when redistributed
original external EIGRP routes appear as external EIGRP routes when redistributed
OTHER=>BGP=>EIGRP
BGP X => EIGRP metrics (manual)
original routes appear as external EIGRP routes when redistributed
If "auto" doesn't work (for whatever reason), you can trying clearing the vrf routing table on the PE or you can use the following to set manually the EIGRP metrics:
- redistribute bgp 100 metric K1 K2 K3 K4 K5
- redistribute bgp 100 route-map X
- redistribute bgp 100 route-policy X
- redistribute bgp 100 & default-metric K1 K2 K3 K4 K5
EIGRP vector metrics = K1 K2 K3 K4 K5 (i.e. 1000 10 255 1 1500)
Configuration
IOS
router eigrp 100
address-family ipv4 vrf VPN autonomous-system 1
redistribute bgp 200
exit-address-family
!
router bgp 200
address-family ipv4 vrf VPN
redistribute eigrp 1
IOS-XR
router eigrp 100
vrf VPN
address-family ipv4
autonomous-system 1
redistribute bgp 200
!
router bgp 200
vrf VPN
address-family ipv4 unicast
redistribute eigrp 1
Redistribution of EIGRP into the BGP vrf requires the EIGRP autonomous-system number to be redistributed. Some software releases may accept the global EIGRP process too.
You can use the SoO extended community to prevent any possible loops.
BGP<=>ISIS
ISIS=>BGP
ISIS metric => BGP MED (auto)
ISIS=>BGP=>ISIS
ISIS metric => BGP MED => ISIS metric (auto)
OTHER=>BGP=>ISIS
BGP X => ISIS metric (manual)
You can use the following to set manually the ISIS metric:
- redistribute bgp 100 metric X
- redistribute bgp 100 route-map X
ISIS metric = hops (10)
Configuration
IOS
router isis 100
address-family ipv4 vrf VPN
redistribute bgp 200
!
router bgp 200
address-family ipv4 vrf VPN
redistribute isis 100
IOS-XR
router isis 100
vrf VPN
redistribute bgp 200
!
router bgp 200
vrf VPN
address-family ipv4 unicast
redistribute isis 100
Redistribution doesn't take into account the IS-IS connected routes. You have to explicitly define them.
In order to void a possible loop while doing redistribution (when L1 is involved), you can change the distance of the ISIS advertised routes (excluding connected) on the PE to be higher than BGP's.
IOS
router isis 100
vrf VPN
distance 201 0.0.0.0 255.255.255.255 ISIS-NOT-CONNECTED-ACL
BGP<=>OSPF
OSPF=>BGP
OSPF metric => BGP MED + 1 (auto)
OSPF Area/LSA => BGP extended community "OSPF RT" (auto)
OSPF=>BGP=>OSPF
OSPF metric => BGP MED + 1 => OSPF metric (auto)
- original intra-area routes appear as inter-area routes when redistributed (if same OSPF Domain-ID)
- original intra-area routes appear as external-2 routes when redistributed (if different OSPF Domain-ID)
- type-4 LSAs are not redistributed into BGP
- original external routes appear as external-2 routes when redistributed (requires "match external" in redistribution from OSPF to BGP)
OTHER=>BGP=>OSPF
BGP X => OSPF metric (manual)
You can always use the following to manually set the OSPF metric:
- redistribute bgp 200 metric X
- redistribute bgp 200 route-map X
OSPF metric = interface cost (0-65535)
"OSPF RT" Extended Community
"OSPF RT" format is "Area:LSA-Type:External-Type"
LSA Type to OSPF RT conversion
- Type-1/2 => RT 2
- Type-3 => RT 3
- Type-5 => RT 5
- Type-7 => RT 7
- Sham-links => RT 129
- OSPF RT:0.0.0.0:2:0
- area 0.0.0.0
- LSA-Type 1/2
- OSPF RT:0.0.0.0:5:0
- LSA-Type 5
- External 1
- OSPF RT:0.0.0.0:5:1
- LSA-Type 5
- External 2
Configuration
IOS
router ospf 100 vrf VPN
redistribute bgp 200 subnets
!
router bgp 200
address-family ipv4 vrf VPN
redistribute ospf 100 vrf VPN
IOS-XR
router ospf 100
vrf VPN
redistribute bgp 200
!
router bgp 200
vrf VPN
address-family ipv4 unicast
redistribute ospf 100
In IOS, if you don't include the vrf name in the redistribution of OSPF into BGP, it gets automatically added to the configuration.
The DN Bit and the VPN Route Tag
For a PE it is necessary to know if a particular prefix has been learned from another PE router, in order to avoid re-advertisement of it into BGP and cause a loop.
Two mechanisms are mainly used for loop prevention when OSPF is used as PE-CE protocol.
- the DN bit
- the VPN Route (or OSPF Domain) tag
When another PE receives from a CE router, a type 3, 5, 7 LSA with the DN bit set, the prefix information from that LSA is not used during the OSPF route calculation, which means that the prefix doesn't get installed into the PE's BGP table.
Almost all Cisco software releases support the setting of DN bit only for Type-3 LSAs and they use a 32-bit VPN Route tag for Type-5/7 LSAs. The configuration and inclusion of the VPN Route Tag is required by all implementations for backward compatibility with older implementations that do not set the DN bit in type 5/7 LSAs.
If a PE router receives an LSA that contains the same VPN Route Tag as the locally configured tag, then the local PE router knows that another PE router (from the same domain) generated this route and the LSA is ignored.
- 16bit ASNs
- VPN Route tag Format: 1101 000000000000 ASN_of_VPN_Backbone
- 32bit ASNs
- VPN Route tag must be defined manually
You can change this default value by using the "domain-tag" command within the OSPF VRF process configuration.
IOS
router ospf 100 vrf VPN
domain-tag 12345
IOS-XR
router ospf 100
vrf TEST
domain-tag 12345
In case of Multi-VRF (VRF-Lite), the router that is accepting the LSA with the DN bit is actually a CE router with no BGP VPNv4 functionality, so there is no danger of redistributing this prefix into BGP. In order to bypass this DN bit check, the following configuration can be enabled.
IOS
router ospf 100 vrf VPN
capability vrf-lite
IOS-XR
router ospf 100
vrf VPN
disable-dn-bit-check
Verification
IOS
R1#sh ip ospf 100 database summary 10.7.7.7
OSPF Router with ID (10.1.3.1) (Process ID 100)
Summary Net Link States (Area 0)
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 1196
Options: (No TOS-capability, DC, Downward)
LS Type: Summary Links(Network)
Link State ID: 10.7.7.7 (summary Network Number)
Advertising Router: 10.1.2.2
LS Seq Number: 80000005
Checksum: 0x2761
Length: 28
Network Mask: /32
MTID: 0 Metric: 2
R1#sh ip ospf 100 database external 7.7.7.7
OSPF Router with ID (10.1.3.1) (Process ID 100)
Type-5 AS External Link States
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 1302
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 7.7.7.7 (External Network Number )
Advertising Router: 10.1.2.2
LS Seq Number: 80000004
Checksum: 0x6DCF
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 3489661028
Links
OSPF Domain-ID
OSPF Domain-ID is an attribute that defines how (internal, external) the OSPF routes will be transferred from one CE to another CE over their PEs BGP VPNv4 session.
On a PE, if the OSPF Domain-ID of the received BGP prefixes (encoded as extended community) is the same as the OSPF Domain-ID of the local OSPF process, then:
- the MPLS core is treated like a SuperBackbone area (which is considered higher than area 0)
- the PE is treated like an ABR (instead of an ASBR)
- internal routes are being redistributed as Type-3 LSAs (instead of Type-5)
IOS-XR uses a null Domain-ID by default, so this needs to be changed if the other PE is running IOS (which is encoding the OSPF process-id as domain-id). OSPF Domain-ID needs to be changed on the PEs (where redistribution between BGP and OSPF takes place), not on the CEs.
The "type" value can be different is some cases for backwards compatibility (like in 0005 vs 8005).
Detailed Steps
- if the OSPF Domain tag of the local OSPF process is the same as the VPN Route tag of the prefix, then that route isn't installed into BGP
- if the OSPF DN bit check is enabled in the local OSPF process and the OSPF route has this bit set, then that route isn't installed into BGP
- if the route is installed into BGP
- the Domain-ID of the local OSPF process is encoded into OSPF DOMAIN ID community on the prefix
- the area and the LSA type of the OSPF prefix is encoded into OSPF RT community on the prefix
- the Router-ID of the local OSPF process is encoded into OSPF ROUTER ID community on the prefix
- if the Domain-ID of the local OSPF process is the same as the OSPF DOMAIN ID community of the prefix, then that route is passed to the CE as internal else as external
Configuration
IOS
router ospf 100 vrf VPN
domain-id type 0005 value 000000440101
IOS-XR
router ospf 100
vrf VPN
domain-id type 0005 value 000000440101
Verification
You can use "sh ip ospf" to see the Domain-ID of the local OSPF process.
You can use "sh bgp vpn4 unicast" to see the Domain-ID encoded as extended community in the BGP prefixes (OSPF RT is included too).
R2#sh ip ospf 100
Routing Process "ospf 100" with ID 10.1.2.2
Domain ID type 0x0005, value 0x000000440101
Start time: 00:13:37.092, Time elapsed: 00:36:17.144
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
Connected to MPLS VPN Superbackbone, VRF VPN
Event-log disabled
It is an area border and autonomous system boundary router
Redistributing External Routes from,
bgp 100, includes subnets in redistribution
R2#sh bgp vpnv4 unicast vrf VPN 1.1.1.1/32
BGP routing table entry for 100:1:1.1.1.1/32, version 2
Paths: (1 available, best #1, table VPN)
Advertised to update-groups:
1
Local
10.1.2.1 from 0.0.0.0 (2.2.2.2)
Origin incomplete, metric 2, localpref 100, weight 32768, valid, sourced, best
Extended Community: RT:100:1 OSPF DOMAIN ID:0x0005:0x000000440101
OSPF RT:0.0.0.0:3:0 OSPF ROUTER ID:10.1.2.2:0
mpls labels in/out 28/nolabel
R2#sh ip ospf 100 database
OSPF Router with ID (10.1.2.2) (Process ID 100)
...
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
1.1.1.1 10.1.1.1 980 0x80000002 0x00F336
...
LSA Type-3 (Summary) in local OSPF table is encoded as "OSPF RT:0.0.0.0:3:0" in local BGP table.
Propagation of OSPF routes between CE1 and CE2
- same domain-id
- CE1 O => CE2 IA
- different domain-id
- CE1 O => CE2 E2
- sham-link (regardless of domain-id)
- CE1 O => CE2 O
Extra care needs to be taken if route tags are changed manually on OSPF=>BGP redistribution, because external OSPF routes are tagged by the BGP ASN when BGP=>OSPF redistribution takes place, which means that the original tag is lost (which could lead to a loop)
IOS
R6#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "ospf 100", distance 110, metric 2
Tag Complete, Path Length == 1, AS 100, , type extern 2, forward metric 1
Last update from 10.10.10.5 on POS4/0, 00:00:03 ago
Routing Descriptor Blocks:
* 10.10.10.5, from 10.10.10.5, 00:00:03 ago, via POS4/0
Route metric is 2, traffic share count is 1
Route tag 3489661028
If a BGP VPNv4 route is redistributed into OSPF, then redistributed into another IGP like RIP (where all the information (DN bit, VPN Route-Tag) needed to prevent looping is lost), and then redistributed back into OSPF, then it is possible that it could be redistributed back into BGP as a VPNv4 route, thereby causing a loop.
You can use route tags at every step of redistribution in order to avoid possible routing loops, either caused by the above scenario or by mutual redistribution in two places.
