Specific eBGP Tools: Multi-hop, Multipath, IGP backdoor
EBGP Multi-hop:
By design, a BGP routing process expects eBGP peers to be directly connected. However, there are many real-world scenarios where this rule would prevent routing from occurring. In such cases eBGP peering sessions are configured with the “neighbor ebgp-multihop <ValueX>” command (the <ValueX> represents the TTL to be configured in the IP packet header for the peering). Because the interface used to build the peering is not used by the remote peer (because of the multi-hop) the peers need also to modify the default address used for peering by using the “neighbor update-source” command as well. This command forces the eBGP for which it applies to set the NEXT_HOP attribute to the chosen interface (this is not true for iBGP!).
NOTE: in case single hop is used for eBGP, but there is a will for not using the connected interface for building the peering, the “neighbor disable-connected-check” command must be used. In Multi-hop configuration this is not needed (because the “eighbor ebgp-multihop” allows that).
NOTE: The eBGP Multihop command sets the TTL on packets it sends, but does not control the TTL on pacjets it receives. An enhancement to this is given by the “BGP Support for TTL Security Check” feature. When configuring the BGP Support for TTL Security Check feature to support an existing multihop peering session, you must first disable the neighbor ebgp-multihop router configuration command by entering the no neighbor ebgp-multihop command before configuring this feature with the “neighbor ttl-security router” configuration command. These commands are mutually exclusive, and only one command is required to establish a multihop peering session.
BGP Multipath:
When a BGP speaker learns two identical eBGP paths for a prefix from a neighboring autonomous system (that is Weight, Local Pref, AS-Path, Origin and MED are identical), it will choose the path with the lowest route ID as the best path (tie break). By default only the best path is installed in the RIB.
If BGP multipath support is enabled and the eBGP paths are learned from the same neighboring autonomous system, instead of one best path being picked by the ID tie-breaker, multiple paths are installed in the IP routing table. During packet switching, depending on the switching mode, either per-packet or per-destination load balancing is performed among the multiple paths. A maximum of six paths is supported. The “maximum-paths” command controls the number of paths allowed. By default, BGP will install only one path to the IP routing table (= “maximum-paths 1” is default).
NOTE: Multipath is also available for iBGP using the format: “maximum-paths ibgp <1-6>”.
IMPORTANT: to enable unequal load balancing, check the use of the Bandwidth Link Extended Community (dmzlink-bw)
eBGP and IGP backdoor:
Suppose a network of multiple AS not only runs eBGP but also an IGP between them (case typical of internal organizations, or of a LAB….). In this case a given prefix can be announced by both the IGP and by a eBGP neighbor. In many cases this can lead to inefficiency of path, mainly due to the fact that a router, learning both announcements, will naturally choose the eBGP path because of eBGP administrative dinstance.
Suppose thre routers are in three apart AD: RTA in AS1, RTB in AS2 and RTC in AS3, plus RTA and RTB run a IGP between them.
Suppose now that a network (Network_A) in advertised by RTA in both eBGP and IGP. RTC learns the path via eBGP only. Suppose eBGP metric are set favourable from RTB towards AS3. This means RTB learns Network_A from the IGP and twice by eBGP. Because of the eBGP metrics the path to Network_A in the BGP table is chosen through AS3, and then because of the administrative distance the path to Network_A is chosen from eBGP instead of IGP. This lead RTB to go though to RTC and AS3 instead of using the better path.
The the “backdoor” keyword can be configured to tell the router which receives both eBGP and IGP advertisements for a network to artificially assign an administrative distance of 200 in case such network is learned through eBGP. The objective is to make Interior Gateway Protocol (IGP) learned routes preferred based on administrative distance. A backdoor network is treated as a local network, except that it is not advertised as injected. A network that is marked as a backdoor is not sourced by the local router. The BGP best path selection algorithm does not change when a network is configured as a back door.
In the example RTB will need to be told that Network_A is a backdoor network, using:
router bgp 2
neighbor <ip_RTA> remote-as 1
neighbor <ip_RTC> remote-as 3
network Network_A backdoor
Connecting to a Service Provider Using eBGP
Influencing Inbound Path Selection: BGP can influence inbound path selection using either the AS-path or the MED attribute.
– using MED;
– using AS-path via outbound route-maps;
Using MED:
Basically MED allows for a cleaner approach, but requires both party to explicitely set a policy to announce and use the MED attribute (see Cisco IOS routers using a missing MED as a zero MED, contraryu to IETF defaults and similar).
bgp always-compare-med command to compare MED attributes from peers in other autonomous systems.
router bgp 40000
bgp always-compare-med
bgp deterministic-med
bgp bestpath med missing-as-worst
neighbor 192.168.1.2 remote-as 60000
neighbor 192.168.1.3 remote-as 50000
neighbor 192.168.1.2 route-map Set_MED_Low out
neighbor 192.168.1.3 route-map Set_MED_HIGH out
no auto-summary
no synchronization
network 172.17.1.0 mask 255.255.255.0
!
route-map Set_MED_Low permit 10
set metric 10
!
route-map Set_MED_High permit 10
set metric 50
!
end
Using AS-Path prepending:
The AS-Path prepending can be instead useful to try to influence the inbound path slection when the service provider does not want to configure an explicit policy for MED (or when TWO different SPs are providing Internet transit – case for which MED is unusable). The AS-Path prepending tries to influence inbound path selection making the route, through a given autonomous system, appear to be longer than the path through the effectively closer autonomous system. Although this usually works, it can be source of problems if the receiving service provider deploys explicit AS-path based policies. In such case it must allow multiple instances of the same AS in an AS-path.
router bgp 40000
neighbor 192.168.1.2 remote-as 60000
neighbor 192.168.1.2 route-map PREPEND out
no auto-summary
no synchronization
network 172.17.1.0 mask 255.255.255.0
!
route-map PREPEND permit 10
set as-path prepend 40000 40000
Note: Sometimes organizations may use internally private AS numbers to split their AS into functional parts (a concept quite similar to Confederations, without the special rules of Confederations). At a given point, when peering with another public AS the private AS numbers must be removed using the “neighbor remove-private-AS” command.
In case the policy need to be applied based on AS, use AS-PATH access-lists to select the path. In case the policy need to be applied per neighbor, use communities. In case the policies need to be applied on non-neighbor, non-AS prefixes, use prefix lists. In case no distinction is needed, just use the set command (= match all).
Influencing Outbound Path Selection: BGP can use to influence inbound path selection either the Local_Pref attribute (within its iBGP network), outbound route filter (ORF) capability (trying to suggest the AS neighbor a policy to announce) or explicitely modifying attributes from incoming prefixes. If possible ORF allows for the least use of resources (but require neighbors to accept inbound filtering on the other side as outboun filters on theirs).
Local preference is of cource a method, when such agreements are not possible.
– using Weight in inbound;
– setting the Local_Pref for iBGP peers;
– using prefix-list filters in inbound (eventually with ORF);
– using AS-Path filter-list in inbound;
Weight:
The weight is a useful attribute for choosing the outbound path selection (both eBGP and iBGP), and being the first attribute to be checked, is always a way to override decisions (although it may not scale, being local to each router). The weight can be set on a per neighbor basis or on prefixes basis, when processed through an inbound route-map:
router bgp 400
bgp router-id 192.168.0.1
neighbor 192.168.107.2 remote-as 100
neighbor 192.168.107.2 route-map Weight_IN in
!
ip community-list 10 permit 100:12345
!
route-map Weight_IN permit 10
match community 10
set weight 65535
!
end
2610b(config)router bgp 400
2610b(config-router)neighbor 192.168.0.2 weight 1000
2610b# sh ip bgp
BGP table version is 19, local router ID is 192.168.0.1
Status codes: s suppressed, d damped, h history, valid, > best, i – internal,
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
> 0.0.0.0 192.168.107.2 4294967294 65535 100 300 200 i
> 10.32.0.0/16 192.168.107.2 4294967294 65535 100 300 i
i 192.168.102.2 0 100 1000 100 300 i
Local_Pref:
By default all routes advertised to the iBGP network or installed have a Local_pref value set to 100. This can be modified on a per router basis (using the “bgp default local-preference 200”) or explictely on a per router, per prefix basis (using a route map and setting the local_pref after matching a given prefix).
router bgp 100
network 10.108.0.0
neighbor 10.108.1.1 remote-as 200
neighbor 10.108.1.1 route-map set-local-pref in
neighbor 12.10.1.1 remote-as 100
neighbor 12.10.1.1 update-source Loopback 0
neighbor 12.10.1.1 next-hop-self
bgp default local-preference 200
!
access-list 2 permit 172.20.0.0 0.0.255.255
access-list 2 deny any
!
route-map set-local-pref permit 10
match ip address 2
set local preference 120
!
route-map set-local-pref permit 20
!
end
Prefix-List filtering and ORF:
Filtering incoming prefixes form a neighbor, in order to priviledge another path, is an obvious possibility. In order to do this, anyway, prefix announcements must be wasted. This can be prone of overhead if only a single or few routes are necessary. An alternative approach to achieve this is to enable the peers to communicate local inbound filter to the respective remote advertising neighbor (from its perspective as outbound filters). In pratice this achieves the same result, but avoids sending prefixes that will be discarded. BGP prefix-based outbound route filtering uses the BGP ORF send and receive capabilities to minimize the number of BGP updates that are sent between BGP peers.
The BGP prefix-based outbound route filtering is simply enabled through the advertisement of ORF capabilities to peer routers. The advertisement of the ORF capability indicates that a BGP peer will accept a prefix list from a neighbor and apply the prefix list to locally configured ORFs (if any exist). When this capability is enabled, the BGP speaker can install the inbound prefix list filter to the remote peer as an outbound filter, which reduces unwanted routing updates.
The BGP ORF capabilities MUST be enabled on each participating router before prefix-based ORF announcements can be received.
Further IP addresses to be used for outbound route filtering must be defined in an IP prefix list. BGP distribute lists and IP access lists are not supported by ORF. Outbound route filtering is configured for eBGP peering sessions only. There is need to select which inbound prefix-list filter is “exported”. ORF choses it automatically. A “clear ip bgp <neighbor> in prefix-filter”, though, must be issued to align the neighbors and export filters.
1720b(config)router bgp 100
1720b(config-router)neighbor 192.168.106.2 capability ?
orf Advertise ORF capability to the peer
1720b(config-router)neighbor 192.168.106.2 capability orf ?
prefix-list Advertise prefixlist ORF capability to this neighbor
1720b(config-router)neighbor 192.168.106.2 capability orf prefix-list ?
both Capability to SEND and RECEIVE the ORF to/from this neighbor
receive Capability to RECEIVE the ORF from this neighbor
send Capability to SEND the ORF to this neighbor
1720b(config-router)neighbor 192.168.106.2 capability orf prefix-list both
2610a#
%BGP-5-ADJCHANGE: neighbor 192.168.106.1 Down Peer closed the session
2610a(config)router bgp 300
2610a(config-router)neighbor 192.168.106.1 capability orf prefix-list both
02:36:49: %BGP-5-ADJCHANGE: neighbor 192.168.106.1 Up
2610a# sh ip bgp neighbors 192.168.106.1
BGP neighbor is 192.168.106.1, remote AS 100, external link
BGP version 4, remote router ID 192.168.0.3
BGP state = Established, up for 00:01:57
Last read 00:00:27, hold time is 90, keepalive interval is 30 seconds
Configured hold time is 90, keepalive interval is 30 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 2 2
Notifications: 0 0
Updates: 2 0
Keepalives: 33 33
Route Refresh: 1 2
Total: 38 36
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP table version 2, neighbor version 2
Index 2, Offset 0, Mask 0x4
AF-dependant capabilities:
Outbound Route Filter (ORF) type (128) Prefix-list:
Send-mode: advertised, received <<<<<<<
Receive-mode: advertised, received <<<<<<<
Sent Rcvd
Prefix activity: —- —-
Prefixes Current: 1 0
Prefixes Total: 1 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: ——– ——-
Total: 0 0
Number of NLRIs in the update sent: max 1, min 0
Connections established 2; dropped 1
Last reset 00:02:38, due to Peer closed the session
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 192.168.106.2, Local port: 179
Foreign host: 192.168.106.1, Foreign port: 11003
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x91655C):
Timer Starts Wakeups Next
Retrans 8 0 0x0
TimeWait 0 0 0x0
AckHold 7 1 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
iss: 1996884064 snduna: 1996884302 sndnxt: 1996884302 sndwnd: 16147
irs: 3811200845 rcvnxt: 3811201058 rcvwnd: 16191 delrcvwnd: 212
SRTT: 210 ms, RTTO: 904 ms, RTV: 694 ms, KRTT: 0 ms
minRTT: 0 ms, maxRTT: 300 ms, ACK hold: 200 ms
Flags: passive open, nagle, gen tcbs
Datagrams (max data segment is 1460 bytes):
Rcvd: 15 (out of order: 0), with data: 8, total data bytes: 212
Sent: 12 (retransmit: 0, fastretransmit: 0), with data: 10, total data bytes: 256
2610a# sh ip bgp neighbors 192.168.106.1 advertised-routes
BGP table version is 4, local router ID is 192.168.0.4
Status codes: s suppressed, d damped, h history, valid, > best, i – internal,
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
>i0.0.0.0 192.168.111.2 0 100 0 200 i
>i10.31.0.0/16 192.168.0.7 0 100 0 i
>i10.32.0.0/16 192.168.0.7 0 100 0 i
Configuring an inbound filter and sending it through ORF:
1720b(config)ip prefix-list AS300_to_AS100 permit 10.32.0.0/16
1720b(config)ip prefix-list AS300_to_AS100 deny 10.31.0.0/16
1720b(config)ip prefix-list AS300_to_AS100 permit 0.0.0.0/0 le 32
1720b(config)router bgp 100
1720b(config-router)neighbor 192.168.106.2 prefix-list AS300_to_AS100 in
1720bclear ip bgp 192.168.106.2 in prefix-filter
.Nov 11 15:09:53: BGP: 192.168.106.2 send message type 5, length (incl. header) 55
2610aclear ip bgp 192.168.106.1 in prefix-filter
.Nov 11 15:09:22: BGP: 192.168.106.1 sending REFRESH_REQ(5) for afi/safi: 1/1
.Nov 11 15:09:22: BGP: 192.168.106.1 send message type 5, length (incl. header) 23
.Nov 11 15:09:53: BGP: 192.168.106.1 rcv message type 5, length (excl. header) 36
2610a# sh ip bgp neighbors 192.168.106.1 received prefix-filter
Address family: IPv4 Unicast
ip prefix-list 192.168.106.1: 3 entries
seq 5 permit 10.32.0.0/16
seq 10 deny 10.31.0.0/16
seq 15 permit 0.0.0.0/0 le 32
2610a# sh ip bgp neighbors 192.168.106.1 advertised-routes
BGP table version is 4, local router ID is 192.168.0.4
Status codes: s suppressed, d damped, h history, valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
>i0.0.0.0 192.168.111.2 0 100 0 200 i
>i10.32.0.0/16 192.168.0.7 0 100 0 i
Explicit Filters:
– distribution-lists {in|out} (not recommended in BGP);
– prefix-list {in|out}, using prefix lists;
– filter-lists {in|out}, using AS-path ACLs;
Prefix Lists:
(See ORF example)
Filter Lists (based on AS path ACLs)
2610b# sh ip bgp
BGP table version is 13, local router ID is 192.168.0.1
Status codes: s suppressed, d damped, h history, valid, > best, i – internal,
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
0.0.0.0 192.168.107.2 4294967294 
0 100 300 200 i
>i 192.168.102.2 0 100 0 100 300 200 i
10.32.0.0/16 192.168.107.2 4294967294 0 100 300 i
>i 192.168.102.2 0 100 0 100 300 i
2610b# sh ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 9
Paths: (2 available, best 2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
192.168.107.2
100 300 200
192.168.107.2 from 192.168.107.2 (192.168.0.6)
Origin IGP, metric 4294967294, localpref 100, valid, external
100 300 200
192.168.102.2 (metric 51) from 192.168.0.2 (192.168.0.2) <<<< remove it
Origin IGP, metric 0, localpref 100, valid, internal, best
2610b(config)ip as-path access-list 100 deny _200$
2610b(config)ip as-path access-list 100 permit .
2610b(config)router bgp 400
2610b(config-router)neighbor 192.168.0.2 filter-list ?
<1-500> AS path access list
2610b(config-router)neighbor 192.168.0.2 filter-list 100 ?
in Filter incoming routes
out Filter outgoing routes
2610b(config-router)neighbor 192.168.0.2 filter-list 100 in
2610b# sh ip bgp
BGP table version is 14, local router ID is 192.168.0.1
Status codes: s suppressed, d damped, h history, valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
> 0.0.0.0 192.168.107.2 4294967294 0 100 300 200 i
10.32.0.0/16 192.168.107.2 4294967294 0 100 300 i
>i 192.168.102.2 0 100 0 100 300 i
Using Route-Maps for many purposes (Inbound and Outbound):
Route maps are the most flexible tool for configuring BGP policies. Primarily Route-maps play a role when setting the attributes to assign to announced prefixes. Anyway the can be used to modify the attributes received with prefixes. Typical for instance is the use of route-maps in association to adding, deleting or evaluating communities in advertisements.
– using Communities (sending, adding, removing, evaluating) in outbound and inbound route-maps;
– using Route-maps for setting outbound attributes;
– using Route-maps for modifying inbound selection attributes (eventually with policy-list and continues statements);
Route-maps with community to influece policy.
Community can be sent, evaluated added and removed:
– By default Community are accepted, but not sent. To enable sending community use the command “neighbor send-community”.
– Communities can be set using a route-map and using the “set community {additive}” command.
– Communities can be evaluated using the “match community <community list> {exact-match}” command.
– Communities can be also removed using the “set comm-list <LIST> delete” command.
2610b# sh ip bgp
BGP table version is 14, local router ID is 192.168.0.1
Status codes: s suppressed, d damped, h history, valid, > best, i – internal,
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
> 0.0.0.0 192.168.107.2 0 0 100 300 200 i
10.32.0.0/16 192.168.107.2 0 0 100 300 i
>i 192.168.102.2 0 100 0 100 300 i
2610b(config)ip community-list 10 permit 100:12345
2610b(config)route-map ACCEPT-Community-and-Police
2610b(config-route-map)match community 10
2610b(config-route-map)set weight 65535
2610b(config)router bgp 400
2610b(config-router)neighbor 192.168.107.2 route-map ACCEPT-Community-and-Police in
2610b# sh ip bgp
BGP table version is 17, local router ID is 192.168.0.1
Status codes: s suppressed, d damped, h history, valid, > best, i – internal,
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
> 0.0.0.0 192.168.107.2 0 65535 100 300 200 i
> 10.32.0.0/16 192.168.107.2 0 65535 100 300 i
i 192.168.102.2 0 100 0 100 300 i
Removing the community (it can be done after matching it):
2610b(config)route-map ACCEPT-Community-and-Police
2610b(config-route-map)set comm-list 10 delete
2610b# sh ip bgp
BGP table version is 19, local router ID is 192.168.0.1
Status codes: s suppressed, d damped, h history, valid, > best, i – internal,
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
> 0.0.0.0 192.168.107.2 4294967294 65535 100 300 200 i
> 10.32.0.0/16 192.168.107.2 4294967294 65535 100 300 i
i 192.168.102.2 0 100 0 100 300 i
2610b# sh ip bgp 10.32.0.0
BGP routing table entry for 10.32.0.0/16, version 19
Paths: (2 available, best 1, table Default-IP-Routing-Table)
Flag: 0x880
Advertised to non peer-group peers:
192.168.0.2
100 300
192.168.107.2 from 192.168.107.2 (192.168.0.6)
Origin IGP, metric 4294967294, localpref 100, weight 65535, valid, external, best
100 300
192.168.102.2 (metric 51) from 192.168.0.2 (192.168.0.2)
Origin IGP, metric 0, localpref 100, valid, internal
2610b# sh run | be bgp
router bgp 400
no synchronization
bgp router-id 192.168.0.1
bgp log-neighbor-changes
bgp bestpath med missing-as-worst
timers bgp 30 90
neighbor 192.168.0.2 remote-as 400
neighbor 192.168.0.2 update-source Loopback999
neighbor 192.168.0.2 filter-list 100 in
neighbor 192.168.107.2 remote-as 100
neighbor 192.168.107.2 route-map ACCEPT-Community-and-Police in
no auto-summary
!
ip bgp-community new-format
!
ip community-list 10 permit 100:12345
!
ip as-path access-list 100 deny _200$
ip as-path access-list 100 permit .
!
route-map ACCEPT-Community-and-Police permit 10
match community 10
set weight 65535
set comm-list 10 delete
!
end
In case the policy needs to be applied based on AS, use AS-PATH access-lists to select the path. In case the policy need to be applied per neighbor, use communities. In case the policies need to be applied on non-neighbor, non-AS prefixes, use prefix lists. In case no distinction is needed, just use the set command (= match all).