Thursday, February 6, 2014

NTS: L3VPN Redistribution

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
Clearing of vrf routing table might be needed every time a new prefix is redistributed.

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
Clearing of vrf routing table might be needed every time a new prefix is redistributed.

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
Clearing of vrf routing table might be needed every time a new prefix is redistributed.

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
Clearing of vrf routing table might be needed every time a new prefix is redistributed.

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
Examples
  • 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
By default, when a type 3, 5, 7 LSA is sent from a PE to a CE, the DN bit is set by the PE.

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
OSPF=>BGP redistribution on PE1
  • 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
BGP=>OSPF redistribution on PE2
  • 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 0x
000000440101
 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:0x
000000440101
        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.



No comments:

Post a Comment