Thursday, February 6, 2014

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.



No comments:

Post a Comment