Showing posts with label VPNv4. Show all posts
Showing posts with label VPNv4. Show all posts

Thursday, February 6, 2014

NTS: Inter-AS MPLS L3VPN

Inter-AS MPLS L3VPN




Inter-AS MPLS L3VPN Options are defined in RFC 4364.



Inter-AS Options
  • Inter-AS Option A (Back-to-Back VRF)
    • one logical/physical interface per VRF in the interconnection
    • one PE-CE eBGP/IGP session per VRF between ASBRs
    • IP traffic between ASBRs
    • no need for common RDs/RTs between ASNs 
    • 2 LSPs and 1 IP path from one PE to the other PE
  • Inter-AS Option B (MP-eBGP between ASBRs)
    • one physical/logical interface for all VRFs in the interconnection
    • eBGP VPNv4 between ASBRs
    • MPLS traffic between ASBRs
    • common RDs/RTs between ASNs (unless RT rewrite is used)
    • next-hop-self on each ASBR for iBGP
      • 3 LSPs from one PE to the other PE
    • redistribute connected/static on each ASBR for the interconnection
      • 2 LSPs from one PE to the other PE
      • filter to redistribute only the peer's address
    • multihop (loopback) peering between ASBRs
      • 2 LSPs from one PE to the other PE
      • static routes for peer's loopback on each ASBR
      • LDP between ASBRs
      • MPLS static label binding for peer's loopback pointing to interconnection on each ASBR
  • Inter-AS Option C (Multihop MP-eBGP between RRs/PEs)
    • one physical/logical interface for all VRFs in the interconnection
    • labeled eBGP session between ASBRs for next-hop exchange
    • multihop eBGP VPNv4 session between RRs
    • MPLS traffic between ASBRs
    • common RDs/RTs between ASNs (unless RT rewrite is used) 
    • change next-hop on each VPNv4 RR for the eBGP session (default)
      • 2 LSPs from one PE to the other PE
    • next-hop-unchanged on each VPNv4 RR for the eBGP session
      • 1 LSP from one PE to the other PE
    • eBGP session between ASBRs with directly connected interfaces
      • next-hop-self on each ASBR for the iBGP sessions
    • multihop (loopback) eBGP session between ASBRs with loopbacks
      • static routes for peer's loopback on each ASBR
      • LDP between ASBRs
      • MPLS static label binding for peer's loopback pointing to interconnection on each ASBR

The transport label changes whenever the next-hop changes.



Inter-AS Option A

ASBR-1

IOS
ip vrf VPN1
 rd 1:100
 route-target 1:100
!
ip vrf VPN2
 rd 1:200
 route-target 1:200
!
interface FastEthernet0/0
 description ** Inter-AS NNI **
!
interface FastEthernet0/0.10
 description ** Customer VPN1 **
 encapsulation dot1q 10
 ip vrf forwarding VPN1
 ip address 10.10.10.1 255.255.255.0
!
interface FastEthernet0/0.20
 description ** Customer VPN2 **
 encapsulation dot1q 20
 ip vrf forwarding VPN2
 ip address 20.20.20.1 255.255.255.0
!
router bgp 1
 neighbor 1.1.1.1 remote-as 1

 neighbor 1.1.1.1 update-source Loopback0
 neighbor 1.1.1.1 description iBGP-VPNv4
!
 address-family vpnv4
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 send-community extended
  neighbor 1.1.1.1 next-hop-self
 exit-address-family
!
 address-family ipv4 vrf VPN1
  neighbor 10.10.10.2 remote-as 2
  neighbor 10.10.10.2 activate
 exit-address-family
!
 address-family ipv4 vrf VPN2
  neighbor 20.20.20.2 remote-as 2
  neighbor 20.20.20.2 activate
 exit-address-family



ASBR-2

IOS
ip vrf test1
 rd 2:100
 route-target 2:100
!
ip vrf test2
 rd 2:200
 route-target 2:200
!
interface FastEthernet0/0
 description ** Inter-AS NNI **
!
interface FastEthernet0/0.10
 description ** Customer VPN1 **
 encapsulation dot1q 10
 ip vrf forwarding VPN1
 ip address 10.10.10.2 255.255.255.0
!
interface FastEthernet0/0.20
 description ** Customer VPN2 **
 encapsulation dot1q 20
 ip vrf forwarding VPN2
 ip address 20.20.20.2 255.255.255.0
!
router bgp 2
 neighbor 2.2.2.2 remote-as 2
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 description iBGP-VPNv4
!
 address-family vpnv4
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 send-community extended
  neighbor 2.2.2.2 next-hop-self
 exit-address-family
!
 address-family ipv4 vrf VPN1
  neighbor 10.10.10.1 remote-as 1
  neighbor 10.10.10.1 activate
 exit-address-family
!
 address-family ipv4 vrf VPN2
  neighbor 20.20.20.1 remote-as 1
  neighbor 20.20.20.1 activate
 exit-address-family



You can also use a different router-id per VRF, using the "bgp router-id" under each vrf address-family.



Inter-AS Option B

ASBR-1

IOS
interface FastEthernet0/0
 description ** Inter-AS NNI **
 ip address
x.x.x.x
 mpls bgp forwarding
!
router bgp 1
 no bgp default route-target filter
 neighbor
PE-1 remote-as 1
 neighbor
PE-1 update-source Loopback0
 neighbor
PE-1 description MP-iBGP with PE-1
 neighbor ASBR-2 remote-as 2
 neighbor
ASBR-2 description MP-eBGP with ASBR-2
 no auto-summary
!
 address-family vpnv4
  neighbor PE-1 activate
  neighbor
PE-1 send-community extended
  neighbor
PE-1 next-hop-self
  neighbor
ASBR-2 activate
  neighbor
ASBR-2 send-community extended
 exit-address-family



ASBR-2

IOS
interface FastEthernet0/0
 description ** Inter-AS NNI **
 ip address
x.x.x.x
 mpls bgp forwarding
!
router bgp 2
 no bgp default route-target filter
 neighbor PE-2 remote-as 2
 neighbor
PE-2 update-source Loopback0
 neighbor
PE-2 description MP-iBGP with PE-2
 neighbor ASBR-1 remote-as 1
 neighbor
ASBR-1 description MP-eBGP with ASBR-1
!
 address-family vpnv4
  neighbor PE-2 activate
  neighbor
PE-2 send-community extended
  neighbor
PE-2 next-hop-self
  neighbor
ASBR-1 activate
  neighbor
ASBR-1 send-community extended
 exit-address-family





Inter-AS Option C

RR-1

IOS
router bgp 1
 no synchronization
 neighbor PE-1 remote-as 1
 neighbor
PE-1 update-source Loopback0
 neighbor
PE-1 description MP-iBGP with PE-1
 neighbor ASBR-1 remote-as 1
 neighbor
ASBR-1 update-source Loopback0
 neighbor
ASBR-1 description MP-iBGP with ASBR-1
 neighbor RR-2 remote-as 2
 neighbor RR-2 ebgp-multihop 255
 neighbor RR-2 update-source Loopback0
 neighbor RR-2 description MP-eBGP with RR-2
 no auto-summary
!
 address-family vpnv4
  neighbor
PE-1 activate
  neighbor
PE-1 send-community extended
  neighbor
PE-1 route-reflector-client
  neighbor ASBR-1 activate
  neighbor
ASBR-1 send-community extended
  neighbor
ASBR-1 route-reflector-client
  neighbor RR-2 activate
  neighbor RR-2 send-community extended
  neighbor RR-2 next-hop-unchanged
  exit-address-family



ASBR-1

IOS
interface FastEthernet0/0
 description ** Inter-AS NNI **
 ip address x.x.x.x
 mpls bgp forwarding
!

route-map PE2-TO-IGP permit 10
 match ip address
PE-2

!
router IGP 100
 redistribute bgp 1 route-map PE2-TO-IGP
!
router bgp 1
 no synchronization
 network PE-1 mask 255.255.255.255
!
 neighbor RR-1 remote-as 1
 neighbor
RR-1 update-source Loopback0
 neighbor
RR-1 description MP-iBGP to RR-1
 neighbor ASBR-2 remote-as 2
 neighbor
ASBR-2 send-label
 Î½eighbor
ASBR-2 description MP-eBGP to ASBR-2
 no auto-summary
!
 address-family vpnv4
  neighbor
RR-1 activate
  neighbor
RR-1 send-community extended
 exit-address-family




ASBR-2

IOS
interface FastEthernet0/0
 description ** Inter-AS NNI **
 ip address x.x.x.x
 mpls bgp forwarding
!

route-map PE1-TO-IGP permit 10
 match ip address PE-1

!
router IGP 200
 redistribute bgp 2 route-map PE1-TO-IGP
!
router bgp 2
 network PE-2 mask 255.255.255.255
!
 neighbor RR-2 remote-as 2
 neighbor
RR-2 update-source Loopback0
 neighbor
RR-2 description MP-iBGP to RR-2
 neighbor ASBR-1 remote-as 1
 neighbor
ASBR-1 send-label
 neighbor
ASBR-1 description MP-eBGP to ASBR-1
!
 address-family vpnv4
  neighbor RR-2 activate
  neighbor RR-2 send-community extended
 exit-address-family




RR-2

IOS
router bgp 2
 neighbor PE-2 remote-as 2
 neighbor PE-2 update-source Loopback0
 neighbor PE-2 description MP-iBGP with PE-2
 neighbor ASBR-2 remote-as 2
 neighbor
ASBR-2 update-source Loopback0
 neighbor
ASBR-2 description MP-iBGP with ASBR-2
 neighbor RR-1 remote-as 1
 neighbor
RR-1 ebgp-multihop 255
 neighbor
RR-1 update-source Loopback0
 neighbor
RR-1 description MP-eBGP with RR-1
!
 address-family vpnv4
  neighbor PE-2 activate
  neighbor
PE-2 send-community extended
  neighbor
PE-2 route-reflector-client
  neighbor ASBR-2 activate
  neighbor
ASBR-2 send-community extended
  neighbor
ASBR-2 route-reflector-client
  neighbor RR-1 activate
  neighbor
RR-1 send-community extended
  neighbor
RR-1 next-hop-unchanged
 exit-address-family





In IOS-XR, in order to send IPv4 prefixes with labels over a labeled BGP session, the IOS-XR router must be the originator of the prefixes. On the other hand, an IOS router can send labeled IPv4 prefixes over a labeled BGP session whether it's the originator or not of those prefixes.

If an output route-map is applied on a labeled BGP session, then labels will be added only to those prefixes that have the command "set mpls-label" under the relevant statement in the route-map. Generally, if a router is advertising IPv4 prefixes with labels, then you can use an output route-map (with the "set mpls-label" command) to specify which prefixes will be sent with a label.

You need to disable the default RT filter from the ASBRs, unless they have all the VRFs locally configured or they are VPNv4 RRs.

In most IOS software releases, the command "mpls bgp forwarding" is added automatically under the eBGP peering interface when a VPNv4 or labeled BGP session is configured between directly connected peers. If you use loopbacks for peering, then you must manually configure it. Always verify its existence, together with the interface's mpls operational state.

IOS
R1#sh mpls int
Interface              IP            Tunnel   BGP Static Operational
FastEthernet0/0.13     Yes (ldp)     No       No  No     Yes
FastEthernet0/0.30     No            No       Yes No     Yes


Generally, Cisco software requires a /32 route for each next-hop that should be label switched. In the Inter-AS B/C options, in IOS-XR you must add manually a /32 static route for the peer address of the interconnection in order to create a label for that. IOS creates automatically a /32 connected route when the relevant VPNv4 or labeled BGP session comes up.

IOS-XR
router static
 address-family ipv4 unicast
  10.10.10.2/32 GigabitEthernet0/2/1/2



IOS
Dec 29 15:45:30.703: %BGP-5-ADJCHANGE: neighbor 10.10.10.2 Up
Dec 29 15:45:30.707: CONN: add connected route, idb: FastEthernet0/0.30, addr: 10.10.10.2, mask: 255.255.255.255



If you want to achieve load-sharing in a MPLS L3VPN environment with RRs, you can use a different RD per PE in combination with BGP multipath.

Inter-AS scenarios emulated in GNS3 might sometimes cause very large delays in data forwarding. Increase the ping/traceroute timeout in order to verify connectivity.



Static Label Bindings

In some cases you don't have the option of enabling LDP or having a VPNv4 or labeled BGP session between directly connected peers, but you still need to have the label switching functionality on their interconnection.

i.e. if you configure the following static route in order to reach peer's loopback:

IOS
ip route 19.19.19.19 255.255.255.255 12.1.19.19

IOS
R1#sh mpls forwarding-table 19.19.19.19 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
24         No Label   19.19.19.19/32   0             Fa0/0  12.1.19.19
        MAC/Encaps=18/18, MRU=1504, Label Stack{}
        CA02141C0008CA0417EC0000810000770800
        No output feature configured


then you need to also add a static (outgoing) label binding for that:

IOS
mpls static binding ipv4 19.19.19.19 255.255.255.255 output 12.1.19.19 implicit-null

IOS
R1#sh mpls static binding
19.19.19.19/32: Incoming label: none;
  Outgoing labels:
     12.1.19.19           implicit-null


R1#sh mpls forwarding-table 19.19.19.19 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
24         Pop Label  19.19.19.19/32   0             Fa0/0  12.1.19.19
        MAC/Encaps=18/18, MRU=1504, Label Stack{}
        CA02141C0008CA0417EC0000810000770800
        No output feature configured


At the same time, you must enable MPLS on this interface without using LDP:

IOS
R1#sh mpls int FastEthernet0/0
Interface              IP            Tunnel   BGP Static Operational

IOS
interface FastEthernet0/0
 mpls bgp forwarding

IOS
R1#sh mpls int FastEthernet0/0
Interface              IP            Tunnel   BGP Static Operational
FastEthernet0/0        No            No       Yes No     Yes



Static Label Bindings per Interface

  • multiaccess interfaces
    • next-hop ip address required
    • label required
  • point-to-point interfaces
    • interface required

The above differentiation per interface is applicable only on specific software releases. The multiaccess interface is the common one.

If you must configure specific static labels, then you must first define the label range (which will sometimes require a reload).

Implicit-null is used in the above example due to PHP (pop label) that must happen for the directly connected peer.



Inter-AS L3VPN

If you want to follow a Inter-AS L3VPN path (assuming control-plane has been setup correctly), then you can execute the following algorithm:
  • first router (start PE)
    • Find the VPN label for the prefix
    • Find the Transport label(s) for the prefix's next-hop
  • n router
    • Follow the Transport top label swaps until there is a "Pop Label" for next router
  • n+1 router
    • Find the local VPN label for the prefix
      • If VPN label is "nolabel", then
        • router is the end PE
        • VPN is locally attached
      • If VPN label is other, then
        • router is an RR/ASBR
        • find the Transport label(s) for the prefix's new next-hop
        • go to "n router"
      • If VPN label doesn't exist, then 
        • multiple Transport labels exist
        • go to "n router"

If the route is learned from IGP, the Transport label must be allocated through LDP/RSVP.
If the route is learned from BGP, the Transport label must be allocated through BGP.


Example

R6(PE1)=>R4(P1)=>XR1(ASBR1)=>R1(ASBR2)=>R3(P2)=>R2(PE3)

Start PE

IOS
R6#sh bgp vpnv4 unicast all 7.7.7.7/32
BGP routing table entry for 102:202:7.7.7.7/32, version 36
Paths: (1 available, best #1, table VPN_B)
  Not advertised to any peer
  100
    2.2.2.2 (metric 20) from 20.20.20.20 (20.20.20.20)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:102:202 0x8800:32768:0 0x8801:1:130560
        0x8802:65281:25600 0x8803:65281:1500 0x8806:0:0
      mpls labels in/out nolabel/26


VPN label is 26


IOS
R6#sh mpls forwarding-table 2.2.2.2 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
None       23         2.2.2.2/32       0             Fa0/0.46   20.4.6.4
        MAC/Encaps=18/26, MRU=1496, Label Stack{16 23}
        CA0611100000CA0115B000008100002E8847 0001000000017000
        No output feature configured


Transport label is 16/23, VPN label is 26



IOS
R4#sh mpls forwarding-table labels 16 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
16         Pop Label  19.19.19.19/32   18896         Fa0/0.419  20.4.19.19
        MAC/Encaps=18/18, MRU=1504, Label Stack{}
        CA02141C0008CA0611100000810001A38847
        No output feature configured


Transport label is 23, VPN label is 26


IOS

XR1#sh mpls forwarding-table labels 23 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
23         20         2.2.2.2/32       22628         Fa0/0.119  12.1.19.1
        MAC/Encaps=18/22, MRU=1500, Label Stack{20}
        CA0417EC0000CA02141C0008810000778847 00014000
        No output feature configured



Transport label is 20, VPN label is 26


IOS

R1#sh mpls forwarding-table labels 20 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
20         19         2.2.2.2/32       24518         Fa0/0.13   10.1.3.3
        MAC/Encaps=18/22, MRU=1500, Label Stack{19}
        CA0711100000CA0417EC00008100000D8847 00013000
        No output feature configured



Transport label is 19, VPN label is 26



IOS

R3#sh mpls forwarding-table labels 19 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
19         Pop Label  2.2.2.2/32       85693         Fa0/0.23   10.2.3.2
        MAC/Encaps=18/18, MRU=1504, Label Stack{}
        CA0517EC0000CA0711100000810000178847
        No output feature configured



VPN label is 26



IOS

R2#sh bgp vpnv4 unicast all 7.7.7.7/32
BGP routing table entry for 102:202:7.7.7.7/32, version 4
Paths: (1 available, best #1, table VPN_B)
  Advertised to update-groups:
     1
  Local
    40.2.7.7 from 0.0.0.0 (2.2.2.2)
      Origin incomplete, metric 156160, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:102:202 Cost:pre-bestpath:128:156160
        0x8800:32768:0 0x8801:1:130560 0x8802:65281:25600 0x8803:65281:1500
        0x8806:0:0
      mpls labels in/out 26/nolabel


End PE found




RT Rewrite

It is used mainly in Inter-AS topologies, when there is a need to keep different RTs between the ASes. It allows the ASBR (or any other router that's involved) to replace the peer ASN's RTs with their own.

Configuration Steps
  • define the RTs to be replaced
  • configure a route-map that matches the above RTs, deletes them and then adds the new RTs
  • apply the route-map to the bgp neighbor session


IOS
ip extcommunity-list 1 permit rt 200:1
ip extcommunity-list 2 permit rt 200:2
!
route-map RT-REWRITE-ROUTEMAP permit 10
 match extcommunity 1
 set extcomm-list 1 delete
 set extcommunity rt 100:1 additive
 continue 20
!
route-map RT-REWRITE-ROUTEMAP permit 20
 match extcommunity 2
 set extcomm-list 2 delete
 set extcommunity rt 100:2 additive
!
route-map RT-REWRITE-ROUTEMAP permit 30
!
router bgp 100
 neighbor 10.10.10.2 remote-as 200
 !
 address family vpnv4
  neighbor 10.10.10.2 activate
  neighbor 10.10.10.2 send-community extended
  neighbor 10.10.10.2 route-map RT-REWRITE-ROUTEMAP in


Use the "additive" keyword when setting the new RT in order to not erase all other extended communities.

Use the "continue" statement (in ingress route-maps) when you need to rewrite more than one RTs in the same prefix.



NTS: Advanced BGP

Advanced BGP




BGP (Border Gateway Protocol) is defined in RFC 4271.
MP-BGP (Multi-Protocol BGP) is defined in RFC 4760.
Labeled BGP (BGP+Label) is defined in RFC 3107.



enforce-first-as

When enabled, updates received from an eBGP peer that does not list its ASN at the beginning of the as-path in the incoming update are denied (in order to prevent spoofing).

It's enabled by default.

IOS
router bgp 100
 no bgp enforce-first-as


IOS-XR
router bgp 65000
 bgp enforce-first-as disable





local-as & dual-as

When local-as is enabled for a neighbor, it allows a router to appear to be a member of a second ASN, in addition to its real ASN.

This feature can only be used for true eBGP peers (i.e. members of different confederation sub-ASs are not supported).

R4 (IOS)
router bgp 1
 network 4.4.4.4 mask 255.255.255.255
 neighbor 20.4.5.5 remote-as 2
 neighbor 20.4.5.5 local-as 11



R5 (IOS)
router bgp 2
 network 5.5.5.5 mask 255.255.255.255
 neighbor 20.4.5.4 remote-as 11



By default, the new local-as is prepended in incoming and outgoing updates.

IOS
R4#sh bgp ipv4 unicast
BGP table version is 3, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       0.0.0.0                  0         32768 i
*> 5.5.5.5/32       20.4.5.5                 0             0 11 2 i


R5#sh bgp ipv4 unicast
BGP table version is 3, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       20.4.5.4                 0             0 11 1 i
*> 5.5.5.5/32       0.0.0.0                  0         32768 i


Use the "no-prepend" option to avoid prepending the new local-as in the incoming updates.

R4 (IOS)
router bgp 1
 network 4.4.4.4 mask 255.255.255.255
 neighbor 20.4.5.5 remote-as 2
 neighbor 20.4.5.5 local-as 11 no-prepend


IOS
R4#sh bgp ipv4 unicast
BGP table version is 5, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       0.0.0.0                  0         32768 i
*> 5.5.5.5/32       20.4.5.5                 0             0 2 i


R5#sh bgp ipv4 unicast
BGP table version is 5, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       20.4.5.4                 0             0 11 1 i
*> 5.5.5.5/32       0.0.0.0                  0         32768 i



Use the "no-prepend replace-as" option to avoid prepending the real ASN in the outgoing updates.

R4 (IOS)

router bgp 1
 network 4.4.4.4 mask 255.255.255.255
 neighbor 20.4.5.5 remote-as 2
 neighbor 20.4.5.5 local-as 11 no-prepend replace-as


IOS
R4#sh bgp ipv4 unicast
BGP table version is 7, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       0.0.0.0                  0         32768 i
*> 5.5.5.5/32       20.4.5.5                 0             0 2 i


R5#sh bgp ipv4 unicast
BGP table version is 7, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       20.4.5.4                 0             0 11 i
*> 5.5.5.5/32       0.0.0.0                  0         32768 i



Use the "no-prepend replace-as dual-as" option to avoid prepending the new local-as in the incoming updates and the real ASN in the outgoing updates and at the same time allow eBGP connections with both the real ASN and the new local-as.

R4 (IOS)
router bgp 1
 network 4.4.4.4 mask 255.255.255.255
 neighbor 20.4.5.5 remote-as 2
 neighbor 20.4.5.5 local-as 11 no-prepend replace-as dual-as


R5 (IOS)
router bgp 2
 network 5.5.5.5 mask 255.255.255.255
 neighbor 20.4.5.4 remote-as 11



IOS
R4#sh bgp ipv4 unicast
BGP table version is 9, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       0.0.0.0                  0         32768 i
*> 5.5.5.5/32       20.4.5.5                 0             0 2 i


R5#sh bgp ipv4 unicast
BGP table version is 9, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       20.4.5.4                 0             0 11 i
*> 5.5.5.5/32       0.0.0.0                  0         32768 i


or

R5 (IOS)
router bgp 2
 network 5.5.5.5 mask 255.255.255.255
 neighbor 20.4.5.4 remote-as 1



R4#sh bgp ipv4 unicast
BGP table version is 11, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       0.0.0.0                  0         32768 i
*> 5.5.5.5/32       20.4.5.5                 0             0 2 i


R5#sh bgp ipv4 unicast
BGP table version is 11, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       20.4.5.4                 0             0 1 i
*> 5.5.5.5/32       0.0.0.0                  0         32768 i





PE-CE Routing


In order to allow VPN sites with the same ASN talk to each other, you can use one of the following:
  • "neighbor PE allowas-in" in the CE
    • CE accepts its own ASN
  • "neighbor CE as-override" in the PE
    • PE replaces the common CE ASN with its own

eBGP sessions in IOS-XR require an in/out PASS routing policy under the appropriate address-family. Alternatively in some cases you can use "bgp unsafe-ebgp-policy" in order to bypass this.

IOS-XR
vrf VPN
 address-family ipv4 unicast
  import route-target
   100:1
  export route-target
   100:1

!
router bgp 100
 address-family ipv4 unicast
 vrf VPN

  rd 100:1
  bgp unsafe-ebgp-policy
  address-family ipv4 unicast
  neighbor 2.2.2.2
   remote-as 200
   address-family ipv4 unicast
    as-override





Labeled BGP

It's a BGP capability (negotiated between neighbors during session setup) that allows you to exchange labels together with IPv4/IPv6 unicast prefixes. It's used in Inter-AS, CsC, 6PE scenarios, and when LDP+IGP or RSVP-TE are not available for label distribution.

Configuration

IOS
router bgp 100
 address-family ipv4
  neighbor 1.1.1.1 send-label


IOS-XR
router bgp 100
 address-family ipv4 unicast
  allocate-label all
 neighbor 1.1.1.1
  address-family ipv4 labeled-unicast



You can also filter the prefixes for which to allocate labels.

Verification

R2#sh bgp ipv4 unicast neighbors 1.1.1.1 | b capabilities
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised and received
    Address family IPv4 Unicast: advertised and received
    ipv4 MPLS Label capability: advertised and received
    Multisession Capability: advertised and received



In IOS-XR, when you activate a new ipv4-labeled session for an existing ipv4 neighbor, you need to re-apply all settings (i.e. route-policy, send-community) from the ipv4 session to the ipv4-labeled session.



L3VPN

"send-community extended" is usually automatically enabled when activating a neighbor under the BGP VPNv4 address-family. Since RT is an extended community, without this command VPNv4 routes won't be advertised in BGP.

In order to see the VPN label to be used by the PEs, you just need to check the relevant BGP route.

R2#sh bgp vpnv4 unicast all 6.6.6.6/32
...
    5.5.5.5 (metric 4) from 5.5.5.5 (5.5.5.5)
...
      mpls labels in/out nolabel/28


In order to see the IGP/Transport label to be used by the PEs and Ps, you just need to find the label for the route's next-hop. Remember to add the "detail" keyword in order to see the whole label stack (due to possible route recursion).

R2#sh mpls forwarding-table 5.5.5.5
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
27         26         5.5.5.5/32       0             Fa0/0.23   20.2.3.3


In order to see the whole label stack (which includes both the VPN and the IGP label), you can check the relevant CEF entry (inside the VRF) on the PEs.

R2#sh ip cef vrf VPN 6.6.6.6 det
6.6.6.6/32, epoch 0, flags rib defined all labels
  recursive via 5.5.5.5 label 28
    nexthop 20.2.3.3 FastEthernet0/0.23 label 26



If you want to follow a Intra-AS L3VPN path (assuming control-plane has been setup correctly), then you can execute the following algorithm:
  • first router (start PE)
    • Find the VPN label for the prefix
    • Find the Transport label(s) for the prefix's next-hop
  • n router
    • Follow the Transport top label swaps until there is a "Pop Label" for next router
  • n+1 router
    • Find the local VPN label for the prefix
      • If VPN label is "no label", then 
        • router is the end PE
        • VPN is locally attached
      • If VPN label is other, then 
        • ?
      • If VPN label doesn't exist, then 
        • ?

If the route is learned from IGP, the Transport label must be allocated through LDP/RSVP-TE.
If the route is learned from BGP, the Transport label must be allocated through BGP.



Dynamic L3VPN with mGRE Tunnels

If MPLS is not available in a network, you can use GRE (or other types of encapsulation) to "automatically" build dynamic tunnels in order to provide L3VPN services.

The BGP nexthop is used for tunnel endpoint discovery, but instead of adding a transport label, VPN traffic is encapsulated into GRE (having as source a local interface and as destination the neighbor PE).

The L3VPN BGP configuration (regarding VRFs and VPNv4) remains the same as in MPLS L3VPN.

Configuration Steps
  • create a new VRF for the mGRE tunnels
  • create a mGRE tunnel (with no destination) and assign the above VRF to it
  • create a default static route that forwards the above VRF traffic into the mGRE tunnel
  • activate the above VRF under BGP
  • apply an inbound route-map that changes the next-hop to the above VRF to all the PE sessions
The same tunnels can be used for all L3VPNs between the same PEs.

IOS
vrf definition L3VPN-VRF
 rd 1:99
!

interface Tunnel 1
 tunnel mode gre multipoint l3vpn
 tunnel source loopback0
 ip vrf forwarding L3VPN-VRF
 ip address 99.99.99.1 255.255.255.255
 tunnel key 99
!
ip route vrf L3VPN-VRF 0.0.0.0 0.0.0.0 Tunnel1

!
router bgp 1
 neighbor 2.2.2.2 remote-as 1
 neighbor 2.2.2.2 update-source Loopback0
!
 address-family vpnv4
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 send-community extended
  neighbor 2.2.2.2 route-map L3VPN-ROUTEMAP in
 exit-address-family
!
 address-family ipv4 vrf L3VPN-VRF
 exit-address-family
!
route-map L3VPN-ROUTEMAP permit 10
 set ip next-hop in-vrf L3VPN-VRF



In latest releases you can also use multipoint L2TPv3 tunnels instead of the default mGRE ones.

You can also define l3vpn encapsulation profiles for fully automatic tunnel provisioning.

IOS
l3vpn encapsulation ip L3VPN-PROFILE
 transport source loopback 0
 protocol gre key 99
!

router bgp 1
 neighbor 2.2.2.2 remote-as 1
 neighbor 2.2.2.2 update-source Loopback0
!
 address-family vpnv4
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 send-community extended
  neighbor 2.2.2.2 route-map L3VPN-ROUTEMAP in
 exit-address-family

!
route-map L3VPN-ROUTEMAP permit 10
 set ip next-hop encapsulate L3VPN-PROFILE 
        




Link Bandwidth

It is used with BGP multipath to configure load balancing over links with unequal bandwidth.

When enabled, routes learned from directly connected external neighbors are propagated through the iBGP network with the bandwidth of the source external link stored in an extended community.

The link bandwidth extended community attribute is used as a traffic sharing value relative to other paths while forwarding traffic. 

Two or more paths are designated as equal for load balancing if weight, local-preference, as-path length, MED and IGP costs are the same. 

BGP can originate the link bandwidth community only for directly connected links to eBGP neighbors.


Configuration Steps
  • "dmzlink-bw" must be enabled on all BGP routers that need to process the link bandwidth community
  • "dmzlink-bw" must be enabled on all eBGP neighborships from where the bandwidth will be acquired
  • "send-community extended" must be enabled on all iBGP peerings where the link bandwidth community must be propagated to
  • multipath must be enabled where more than one path is expected

R2 (IOS)
router bgp 1
 bgp dmzlink-bw
 neighbor 3.3.3.3 remote-as 1
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 4.4.4.4 remote-as 1
 neighbor 4.4.4.4 update-source Loopback0
 maximum-paths ibgp 4



R3 (IOS)
router bgp 1
 bgp dmzlink-bw
 neighbor 2.2.2.2 remote-as 1
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 next-hop-self
 neighbor 2.2.2.2 send-community extended
 neighbor 4.4.4.4 remote-as 1
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 4.4.4.4 next-hop-self
 neighbor 4.4.4.4 send-community extended
 neighbor 20.3.6.6 remote-as 2
 neighbor 20.3.6.6 dmzlink-bw
 maximum-paths 4
 maximum-paths ibgp 4
!

interface FastEthernet0/0.36
 bandwidth 36000



R4 (IOS)
router bgp 1
 bgp dmzlink-bw
 neighbor 2.2.2.2 remote-as 1
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 next-hop-self
 neighbor 2.2.2.2 send-community extended
 neighbor 3.3.3.3 remote-as 1
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 3.3.3.3 next-hop-self
 neighbor 3.3.3.3 send-community extended
 neighbor 20.4.5.5 remote-as 2
 neighbor 20.4.5.5 dmzlink-bw
 neighbor 20.4.6.6 remote-as 2
 neighbor 20.4.6.6 dmzlink-bw
 maximum-paths 4
 maximum-paths ibgp 4
!

interface FastEthernet0/0.45
 bandwidth 45000
!
interface FastEthernet0/0.46
 bandwidth 46000



IOS
R2#sh bgp
BGP table version is 5, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*mi19.19.19.19/32   4.4.4.4                  2    100      0 2 i
*>i                 3.3.3.3                  2    100      0 2 i


R2#sh bgp ipv4 unicast 19.19.19.19/32
BGP routing table entry for 19.19.19.19/32, version 5
Paths: (2 available, best #2, table default)
Multipath: iBGP
  Not advertised to any peer
  2
    4.4.4.4 (metric 5) from 4.4.4.4 (4.4.4.4)
      Origin IGP, metric 2, localpref 100, valid, internal, multipath
      DMZ-Link Bw 11375 kbytes
  2
    3.3.3.3 (metric 5) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 2, localpref 100, valid, internal, multipath, best
      DMZ-Link Bw 4500 kbytes



Although BGP multipath is enabled, the BGP selection algorithm still chooses one path as the best (based on the standard BGP selection criteria), but both paths are tagged with the "multipath" keyword and appear in the routing table for forwarding. 

R2#sh ip route 19.19.19.19
Routing entry for 19.19.19.19/32
  Known via "bgp 1", distance 200, metric 2
  Tag 2, type internal
  Last update from 3.3.3.3 00:04:36 ago
  Routing Descriptor Blocks:
  * 4.4.4.4, from 4.4.4.4, 00:04:36 ago
      Route metric is 2, traffic share count is 5
      AS Hops 1
      Route tag 2
      MPLS label: none
    3.3.3.3, from 3.3.3.3, 00:04:36 ago
      Route metric is 2, traffic share count is 2
      AS Hops 1
      Route tag 2
      MPLS label: none



Divide the bandwidth entry (Kbps) by 8 to find out the DMZ-Link Bw (KBps) in the"sh bgp" output.

IOS-XR
router bgp 2
 address-family ipv4 unicast
  maximum-paths ibgp 4

  maximum-paths ebgp 4
 !
 neighbor 6.6.6.6
  dmz-link-bandwidth


The above (old-style) configuration is not recommended. In later IOS-XR releases (>4.3.2) you can set the bandwidth extcommunity in a route-policy towards the iBGP neighbor in order to achieve the same thing.

Links




RT Constrain (RTC)

The default behavior is for the PEs to filter out the unwanted RTs, after they receive the prefixes from the RR. After enabling this feature on the PE and the RR, the PE informs the RR what RTs it actually needs and the RR sends only those.

This feature causes two exchanges to happen:
  • The PE sends an RT Constraint (RTC) NLRI to the RR
  • The RR installs an outbound route filter
The rtfilter address-family must be activated on both the RR and the PE.


IOS
router bgp 100
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 update-source Loopback0
 !
 address-family vpnv4
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 send-community extended
 exit-address-family
 !
 address-family rtfilter unicast
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 send-community extended
 exit-address-family



IOS-XR
router bgp 100
 address-family vpnv4 unicast
 !
 address-family ipv4 rt-filter
 !
 neighbor 1.1.1.1
  remote-as 100
  update-source Loopback0
  address-family vpnv4 unicast
  !
  address-family ipv4 rt-filter



It requires IOS-XR > 4.3 or IOS > 15.1.

Links



Fast Convergence

  • Different RD per PE
  • BGP Multipath
  • BGP Best-external
  • BGP PIC
  • Two RRs (one for primary, one for secondary)

Multipath 
It allows installation of multiple BGP paths to the same destination into the IP routing table. These paths are installed in the table together with the best path for load sharing. BGP Multipath does not affect best-path selection. For example, a router still designates one of the paths as the best path, according to the algorithm, and advertises this best path to its neighbors.

  • eBGP multipath
    • maximum-paths x (IOS)
    • maximum-paths ebgp x (IOS-XR)
  • iBGP multipath
    • maximum-paths ibgp x (IOS, IOS-XR)
  • eiBGP multipath (under ipv4 vrf address-family)
    • maximum-paths eibgp x (IOS, IOS-XR)

In IOS-XR, you can also use the "selective" keyword in order to restrict multipath to specific neighbors (the ones with "multipath" configured).

CEF load-sharing might need to be tuned also.

"bgp bestpath as-path multipath-relax" can be used to skip checking the as-path contents and check only its length.


Best-External Path

When configured, enables the advertisement of the best-external path to iBGP/RR peers, if the locally selected best-path is from an internal peer. That way routers internal to the AS have knowledge of more exit paths from the AS.

Usually it's configured on the backup router.

IOS
router bgp 100
 address-family vpnv4
  bgp advertise-best-external


IOS-XR
router bgp 100
 address-family ipv4 unicast
  advertise best-external




PIC (Prefix Independent Convergence)
When configured, provides a capability to install a backup path into the forwarding table to provide prefix independent convergence in case of PE-CE link failure

Core/Edge

IOS
router bgp 100
 address-family vpnv4
  bgp additional-paths install
  bgp recursion host


IOS-XR (3.9)
router bgp 100
 address-family vpnv4 unicast
  additional-paths install backup



For faster convergence you might need to remove the command "bgp recursion host".


Links



QPPB (QoS Policy Propagation via BGP)

It allows you to match BGP routes based on attributes (i.e. community, as-path), mark these with ip prec or qos-group (or other attributes depending on software version) and then mark appropriately the relevant source/destination packets matching the above routes. Further actions (i.e. policing, queuing) can be performed on the marked packets afterwards.


IOS
ip community-list 1 permit 100:1
!
ip as-path access-list 1 permit _200$
!
route-map QPPB-ROUTEMAP permit 10
 match community 1
 set ip precedence 2
!
route-map QPPB-ROUTEMAP permit 20
 match as-path 1
 set ip precedence 5
!
router bgp 100
 table-map QPPB-ROUTEMAP
!

interface FastEthernet0/0
 bgp-policy source ip-prec-map



IOS-XR
route-policy QPPB-ROUTEPOLICY
  if community matches-any (100:1) then
    set qos-group 2
  endif
  if as-path originates-from '200'  then
    set qos-group 5
  endif
end-policy

!
router bgp 100
 address-family ipv4 unicast
  table-policy QPPB-ROUTEPOLICY
!
interface GigabitEthernet0/0/0/0
 ipv4 bgp policy propagation input qos-group source


IOS-XR has various limitations depending on hw used.



RTBH (Remotely Triggered Black Hole) routing/filtering

It allows you to quickly "block" various attacks on your edge routers, by advertising a null route from a single router to all edge routers.

Configuration Steps
  • configure null static route with dummy next-hop on your edge routers
  • configure route-map that matches a tag and sets a dummy next-hop (plus whatever else) on your rtbh router
  • configure redistribution of static routes into BGP using the above route-map on your rtbh router
  • in case of attack, configure a null static route with the appropriate tag for the destination on the rtbh router
i.e. for destination-based RTBH:

edge (IOS)
ip route 192.168.1.1 255.255.255.255 Null0

rtbh router (IOS)
router bgp 100
 redistribute static route-map RTBH-ROUTEMAP
!
route-map RTBH-ROUTEMAP
 match tag 99
 set ip next-hop 192.168.1.1
 set community no-export no-advertise additive



When attack to 10.10.10.10 happens:

rtbh router (IOS)
ip route 10.10.10.10.10 255.255.255.255 Null0 tag 99


It is assumed that the rtbh router has BGP connectivity with all edge routers (either directly, or through RRs).

If you combine loose uRPF + RTBH, you can use it for blocking source ips too.