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
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
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
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.
