- CCNP Route - BGP part 1: Internet Connectivity
- CCNP Route - BGP part 2: BGP Intro
- CCNP Route - BGP part 3: eBGP
- CCNP Route - BGP part 4: iBGP
- CCNP Route - BGP part 5: BGP path control
- CCNP Route - BGP part 6: Case Studies, Labs, FAQs
Synchronization rule - if an AS provides transit service to another AS, BGP should not advertise a route, until ALL if the routers within the AS have learned about the route via an IGP.
BGP synchronization was an old routing loop prevention mechanism that worked in the following way:
a BGP border router would not propagate a BGP advertisement to an eBGP peer until the router does see the same IP prefix learned in IGP ( OSPF, ISIS or other internal protocol).
This would ensure that there are no black holes inside the ISP AS caused by routers not talking BGP. Intermediate routers only taking part in IGP would know how to route traffic with this destination.
In old times not all routers were BGP speakers so the rule was added by Cisco and enabled by default.
The rule is now by default disabled.
The rule can be disabled when:
- all routers in the AS take part in iBGP ( using BGP RR or confederations this is easy to achieve)
- in modern MPLS based networks internal routers ( P nodes) do not perform IP routing but MPLS switching so they can be unaware of IP prefixes and can be not part of the iBGP mesh.
https://supportforums.cisco.com/discussion/11666556/bgp-synchronization
Outbound routing is simple with a single Internet-connected router (IGP could flood a default route throughout the Enterprise).
With two (or more) Internet-connected routers in a single Enterprise, additional issues arise, in particular, issues require the use of
BGP between Enterprise routers; in some cases.
Internal BGP Between Internet-Connected Routers
The BGP neighbor relationships inside that Enterprise (a single AS) make routers iBGP peers.
Why iBGP is needed ?
The BGP Update message has the path attribute field. If an eBGP speaker receives an update, the update contains the attributes as well.. now the only proctocol that can communicate and replicate eBGP updates along with their path attribtues inside the AS is iBGP. IGPs cannot communicate Path attributes inside an autonomous system. This is the reason we need iBGP. (link)
With an iBGP peer connection, each Internet-connected router can learn routes from the other router and decide if that other router has a better route to reach some destinations in the Internet. Without that iBGP connection, the routers have no way to know if the other router has a better BGP path.
iBGP operates:
- Only advertise the best route in any BGP Update.
- Do not advertise iBGP-learned routes to iBGP peers.
- iBGP peers do not add ASNs to the AS_Path when advertising to each other.
- iBGP peers do not need to be directly connected.
- iBGP routes are NOT redistributed into IGP by default. To allow: router bgp 6 > bgp redistribute-internal
The most basic iBGP configuration differs only slightly compared to eBGP configuration.
neighbor <neighbor-ip> remote-as <neighbor-SAME-asn> !When two iBGP peers share a common physical link, the iBGP configuration simply requires a single neighbor <remote-as> command on each router.
router bgp 11
neighbor 10.1.1.10 remote-as 11
Often the Internet-connected routers in an Enterprise do not share a common subnet (may be in separate buildings/different cities/continents). In such cases, it makes sense to configure the iBGP peers using a loopback IP address for the TCP connection so that a single link failure does not cause the iBGP peer connection to fail.
One difference between iBGP and eBGP is that IOS uses the low TTL of 1 for eBGP connections by default but does not for iBGP connections.
interface loopback 0Verifying iBGP
ip address 10.100.1.1 255.255.255.255
router bgp 11
neighbor 10.100.1.2 remote-as 11
neighbor 10.100.1.2 update-source loopback0
iBGP neighbors use the same messages and neighbor states as eBGP peers.
show ip bgp summary
show ip bgp neighbors 10.100.1.2
show ip bgp 181.0.0.0/8
show ip bgp 181.0.0.0/8 longer-prefixes
E2# show ip bgp 181.0.0.0/8 longer-prefixes
BGP table version is 125, local router ID is 10.100.1.2
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
* > i 181.0.0.0/8 1.1.1.1 0 100 0 1 2 111 112 i
Understanding Next-Hop Reachability Issues with iBGP
With IGPs, the IP routes added to the IP routing table list a next-hop IP address.
With few exceptions, the next-hop IP address routes exist in a connected subnet.
With iBGP, the next-hop addresses may not be not in connected subnets; the nexthop addresses were not even IP addresses on a neighboring router (ex: nexthop is IP of loopback interface of the iBGP neighbor).
! IP 1.1.1.1 is set on loopback int of the neighbor and that network is not directly connecter to router E1
E1# show ip bgp 181.0.0.0/8 longer-prefixes
Network Next Hop Metric LocPrf Weight Path
*> 181.0.0.0/8 1.1.1.1 0 1 2 111 112 i
E1# show ip bgp 181.0.0.0/8
BGP routing table entry for 181.0.0.0/8, version 181
Paths: (1 available, best #1, table Default-IP-Routing-Table)
1.1.1.1 from 10.100.1.1 (11.11.11.11)
Phrase “1.1.1.1 from 10.100.1.1 (11.11.11.11)” - lists the next hop (1.1.1.1) of the route, the neighbor from which the route was learned (10.100.1.1 or E1) and the neighbor’s BGP RID (11.11.11.11).
BGP advertises these particular IP addresses as the next-hop IP addresses because of a default behavior for BGP.
By default, when a router advertises a route using eBGP, the advertising router lists its own update-source IP address as the next-hop address of the route. In other words, the next-hop IP address is the IP address of the eBGP neighbor.
However, when advertising a route to an iBGP peer, the advertising router (by default) does not change the next-hop address.
- For eBGP, the next hop is always the IP address of the neighbor specified in the neighbor command.
- For iBGP, the protocol states that the next hop advertised by EBGP should be carried into IBGP.
The IP routing process can use routes whose next-hop addresses are not in connected subnets as long as each router has an IP route that matches the next-hop IP address (the router performs a recursive route table lookup).
It is needed that each router can reach the next-hop address listed in the BGP routes. Two main options exist to ensure reachability to these next-hop addresses:
a) Create IP routes so that each router can reach these next-hop addresses that exist in other ASNs.
b) Change the default iBGP behavior with the neighbor next-hop-self command.
For a) solution two easily implemented solutions exist to add routes for these nonconnected next-hop IP addresses:
- add static routes,
- use an IGP between the Enterprise and the ISPs for the sole purpose of advertising these next-hop addresses.
For b) solution - changes the iBGP configuration so that a router changes the next-hop IP address on iBGP-advertised routes.
neighbor <neighbor-ip> next-hop-self
Avoiding Routing Loops when Forwarding Toward the Internet
The lack of knowledge about the best route for subnets, particularly on the routers internal to the Enterprise, causes routing loop. To avoid this problem, internal routers, such as Core1 and Core2, need to know the best BGP routes.
Two solutions exist to help these internal routers learn the routes:
■ Run BGP on at least some of the routers internal to the Enterprise (such as Core1 and Core2).
■ Redistribute BGP routes into the IGP (not recommended).
Both solutions solve the problem by giving some of the internal routers the same bestpath information already known to the Internet-connected routers.
Note: Other BGP features, namely BGP Confederations and BGP Route Reflectors, exist as well. However, these more advanced features are outside the scope of CCNP Route.
To let the internal routers in the Enterprise learn the best BGP routes, one obvious solution is to just run BGP on these routers as well.
The implementation choice of what routers need to be iBGP peers with each other (create full mesh).
When a router learns routes from an iBGP peer, that router does not advertise the same routes to another iBGP peer.
This particular iBGP behavior helps prevent BGP routing loops.
IGP Redistribution and BGP Synchronization
You can also redistribute BGP routes into the IGP to solve the routing loop problem. This solution prevents the routing loop by giving the internal Enterprise routers knowledge of the best exit point for each known Internet destination.
Redistribution of BGP routes into an IGP is generally not recommended.
Redistributing the number of routes in the full Internet BGP table could crash the IGP routing protocols.
BGP consumes less memory and uses less CPU for a large number of routes as compared to the equivalent number of routes advertised by an IGP, particularly when compared to OSPF. So using the iBGP mesh may cause internal routers to learn all the same routes but without risk to the IGP.
BGP feature - synchronization or sync - the iBGP-learned routes must be synchronized with IGP-learned routes for the same prefix before they can be used.
The synchronization features tells a BGP router the following:
- Do not consider an iBGP-learned route as “best” unless the exact prefix was learned via an IGP and is currently in the IP routing table.
The BGP synchronization rule states that a BGP router should not use, or advertise to an external neighbor, a route learned by IBGP, unless that route is local or is learned from the IGP.
Later IOS versions default to disable synchronization because most sites avoid redistributing routes from BGP into an IGP when using BGP for Internet routes, instead preferring iBGP meshes (or alternatives) to avoid these routing black holes. The setting is applied to the entire BGP process, with the synchronization command enabling synchronization and the command (default) disabling it.
The modern Internet has too many routes in the BGP table to consider redistributing them into IGPs. The best practice is to not redistribute BGP into the IGP, but instead use IBGP on all routers in the transit path. In this case, synchronization is not needed. Therefore, it is now off by default in the Cisco IOS (12.2(8)T and later).
no synchronizationBGP can be used for other purposes as well, including the implementation of Multiprotocol Label Switching (MPLS). Redistribution from BGP into an IGP when using BGP for MPLS is reasonable and commonly done.
Route Filtering and Clearing BGP Peers
BGP allows the filtering of BGP Update messages on any BGP router. The router can filter updates per neighbor for both inbound and outbound Updates on any BGP router.
After adding a new BGP filter to a router’s configuration, the BGP neighbor relationships must be reset or cleared to cause the filter to take effect.
The IOS BGP clear command tells the router specifically how to reset the neighborship.
BGP Filtering Overview
BGP filtering works generally like IGP filtering, particularly like EIGRP. Similar to EIGRP, BGP Updates can be filtered on any router, without the restrictions that exist for OSPF with various area design issues.
There are 2 ways to clear BGP session WITHOUT resetting the TCP session between 2 BGP peers (term called 'soft reset'):
- soft-reconfiguration: stores all received (inbound) routing policy updates without modification in a table so that when a new filter is applied, the router use this table to calculate the changes without resetting the TCP session. Memory intensive method and is not recommended.
- route-refresh: allow a BGP router to request a remote peer resend its BGP Adj-RIB-Out. This allows the BGP router to reapply the inbound policy and requires no extra memory on the local router.
The biggest conceptual differences between BGP and IGP:
- EIGRP focuses on matching the prefix/length
- BGP can also match the prefix/length but can also match the large set of BGP Path Attributes (PA).
The biggest configuration difference between BGP and IGP filtering, beside the details of matching BGP PAs, has to do with the fact that the filters must apply to specific neighbors with BGP.
BGP configuration does not allow filtering of all inbound or outbound updates. Instead, the BGP filtering configuration enables filters per neighbor (using a neighbor command), referencing the type of BGP filter, the filter number or name, and the direction (in or out).
BGP Filtering Tools
! Match - Prefix, with WC maskInbound and Outbound BGP Filtering on Prefix/Length
neighbor distribute-list (standard ACL)
access-list, ip access-list
!
! Prefix and prefix length, with WC mask for each
neighbor distribute-list (extendedACL)
access-list, ip access-list
!
! Exact or “first N”bits of prefix, plus range of prefix lengths
neighbor prefix-list
ip prefix-list
!
! AS_PATH contents; all NLRI whose AS_PATHs are matched considered to be a match
neighbor filter-list
ip as-path access-list
!
! Prefix, prefix length, AS_PATH, and/or any other PA matchable within a BGP route map
neighbor <route-map>
route-map
When the eBGP connections to the various ISPs come up, the Enterprise BGP routers advertise all the best routes in each router’s BGP table over the eBGP connection. As a result, the ISPs could learn a best route that causes one ISP to send packets to the Enterprise, with the Enterprise then forwarding the packet out to another ISP.
In such a case, the Enterprise AS would be acting as a transit AS; in other words, an AS through which packets go through, rather than being the destination or source of the packet.
The Enterprise engineers can, and probably should, make an effort to filter inappropriate routes sent to the ISP over the eBGP peer connections with the goal of preventing the Enterprise AS from becoming a transit AS.
Additionally, the Enterprise can filter all private IP address ranges, in case any such address ranges get into the Enterprise BGP router’s BGP table.
Typically, an Enterprise would use outbound filtering on its eBGP neighborships, filtering all routes except for the known public prefixes that need to be advertised into the Internet.
AS11 E1 <--eBGP----> AS1 (1.1.1.1) <-----|
| |
iBGP AS2
| |
AS11 E2 <--eBGP----> AS3 (3.3.3.3) <------|
|
AS4 (192.135.250.0/28)
E1# show ip bgp neighbor 1.1.1.1 advertised-routesclear ip bgp 1.1.1.1 - perform a hard reset of that neighbor connection, which brings down the TCP connection, and removes all BGP table entries associated with that neighbor.
*> 128.107.0.0/19 0.0.0.0 32768 i
*>i192.135.250.0/28 10.100.1.2 0 100 0 3 4 i
Total number of prefixes 2
E1(config)#ip prefix-list only-public permit 128.107.0.0/19
E1(config)#router bgp 11
E1(config-router)#neighbor 1.1.1.1 prefix-list only-public out
!
! filtering not working even applied to neighbor
E1# show ip bgp neighbor 1.1.1.1 advertised-routes
*> 128.107.0.0/19 0.0.0.0 32768 i
*>i192.135.250.0/28 10.100.1.2 0 100 0 3 4 i
!
! it is needed to clear BGP session
clear ip bgp 1.1.1.1
*Aug 17 20:19:51.763: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Down User reset
*Aug 17 20:19:52.763: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
!
E1# show ip bgp neighbor 1.1.1.1 advertised-routes
*> 128.107.0.0/19 0.0.0.0 32768 i
Total number of prefixes 1
This same filtering action could have been performed with several other configuration options:
- using the neighbor distribute-list,
- neighbor route-map commands.
! First option – ACL 101 as a distribute-list
access-list 101 permit ip host 128.107.0.0 host 255.255.224.0
router bgp 11
neighbor 1.1.1.1 distribute-list 101 out
! Second option: Same prefix list, referenced by a route map
ip prefix-list only-public seq 5 permit 128.107.0.0/19
!
route-map only-public-rmap permit 10
match ip address prefix-list only-public
!
router bgp 11
neighbor 1.1.1.1 route-map only-public-rmap out
Clearing BGP Neighbors
IOS does not cause a newly configured BGP filter to take effect until the neighbor relationship is cleared.
The neighborship can be cleared in several ways:
- reloading the router,
- administratively disabling and re-enabling the BGP neighborship using the neighbor shutdown and no neighbor shutdown configuration commands.
However, IOS supports several options on the clear ip bgp exec command for the specific purpose of resetting BGP connections.
Command Hard/Soft One/All Neighbors Direction (in or out)The clear ip bgp <neighbor-id> soft in command, the older command of the two, works only if the configuration includes the neighbor <neighbor-id> soft-reconfiguration inbound BGP configuration command for this same neighbor.
clear ip bgp * Hard all both
clear ip bgp <neighbor-id> Hard one both
clear ip bgp <neighbor-id> out Soft one out
clear ip bgp <neighbor-id> soft out Soft one out
clear ip bgp <neighbor-id> in Soft one in
clear ip bgp <neighbor-id> soft in Soft one in
clear ip bgp * soft Soft all both
clear ip bgp <neighbor-id> soft Soft one both
This configuration command causes the router to retain the received BGP Updates from that neighbor. This consumes extra memory on the router, but it gives the router a copy of the original pre-filter Update received from that neighbor.
Using that information, the c clear ip bgp <neighbor-id> soft in - tells IOS to reapply the inbound filter to the cached received Update, updating the local router’s BGP table.
The newer version of the clear ip bgp command, namely the clear ip bgp <neighbor-id> in command (without the soft keyword), removes the requirement for the neighbor <neighbor-id> soft-reconfiguration inbound configuration command. Instead, the router uses a newer BGP feature, the route refresh feature, which essentially allows a BGP router to ask its neighbor to re-send its full BGP Update.
The clear ip bgp <neighbor-id> in command tells the local router to use route refresh feature to ask the neighbor to re-send its BGP Update, and then the local router can apply its current inbound BGP filters, updating its BGP table.
E1# show ip bgp neighbor 1.1.1.1Displaying the Results of BGP Filtering
Neighbor capabilities:
Route refresh: advertised and received(new)
To verify and troubleshoot filtering configurations, you need to see both the before and after results of the filter.
show ip bgp neighbor received-routes - requires the configuration of the BGP subcommand neighbor soft-reconfiguration inbound.
E1# show ip bgp neighbors 1.1.1.1 received-routes
% Inbound soft reconfiguration not enabled on 1.1.1.1