- 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
BGP Aliases
conf t
alias exec rou sh run | s router
alias exec ro sh run | s router
alias exec router sh run | s router
alias exec bgp sh ip bgp
alias exec bgps sh ip bgp summary
!
Labs
- CCNP Route: BGP Lab - eBGP, iBGP, next-hop-self, update-source, communities
- CCNP Route: BGP Lab - multihop and maximum-paths
http://packetlife.net/blog/2008/sep/19/bgp-route-aggregation-part-1/
Troubleshooting When BGP Routes Are Not Advertised
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/19345-bgp-noad.html
BGP Case Studies
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html
BGP: Frequently Asked Questions
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/5816-bgpfaq-5816.html
Test IPv4 BGP full table
http://evilrouters.net/2009/08/21/getting-bgp-routes-into-dynamips-with-video/
BGP Info
http://www.traceroute.org/#BGP%20Info
BGP RIB failure
The BGP routes that are not used due to higher administrative distance
are still advertised to all BGP peers (contrary to what most other
distance-vector routing protocols do), unless you configure bgp suppress-inactive (introducted in 12.2T and 12.0(26)S).
BGP route is in RIB-FAILURE if router already has a static route that collides with the EBGP route and thus the BGP
route cannot be inserted in the IP routing table (as the static route
has administrative distance 1).
- show ip bgp rib-failure
- The BGP routes that are not used due to higher administrative distance are still advertised to all BGP peers (contrary to what most other distance-vector routing protocols do), unless you configure bgp suppress-inactive (introducted in 12.2T and 12.0(26)S).
Custom BGP commandsbgp> enforce-first-as - enforcing the first AS path of a route received from an eBGP peer to be the same as the configured remote autonomous system.
Used in Internet Exchange platforms where the RS will become "transparent", i.e., the BGP announcements received from RS by participants of IX will contain the same BGP attributes AS_PATH, Next-Hop and MED as received via direct peering. Reduction of the AS list in AS_PATH attribute may lead to an increase of traffic via IX to prefixes received via RS.
! Disable first-as check in your BGP configurationpeer x.x.x.x next-hop-local
no bgp enforce-first-as
peer x.x.x.x advertise-community
peer x.x.x.x advertise-ext-community
neighbor> next-hop-self - configure the router as the next hop for a BGP-speaking neighbor or peer group.
- with eBGP, if R1 (AS1) anounce PREF1 prefix with nexthop which is not in routing table of R2 (eBGP neighbor), R2 will not route packets to PREF1.
neighbor R2x.x.x.x next-hop-self is needed, puting R1 as nexthop for PREF1
(What if the external peer you are advertising - doesn't have an entry to get to that next-hop? What if the next hop is a private IP address? If you can't get to the next hop, what good does the detail do you? )
As result puting next-hop-self: reducing CPU utilization on the router drastically and the sluggish behavior experienced earlier no longer occurring.
A default route is never going to be used to establish a BGP session (iBGP/eBGP)”
See more at: http://www.costiser.ro/2013/01/22/quiz-4/#sthash.kvUWG9Z0.dpuf
Route Refresh vs Soft Reconfiguration
from http://ccieblog.co.uk/bgp/route-refresh-capability-vs-soft-reconfiguration
When adjusting inbound policies with BGP, you must request that updates are re-sent from our peer. Remember that BGP UPDATES are incremental, meaning after the initial exchange of complete routing information, we only receive changes. So we need a way of telling our peer to send us a BGP UPDATE message with all the NLRI so that we can re-run everything through the new filter. There are various ways of doing this, either:
- A hard reset – dropping/re-establishing TCP sessions to our peer, forcing all NLRI to be sent again
- A soft reset – uses the route-refresh capability to request all NLRI be sent again
- Or a soft-reconfiguration – storing all unedited, unfiltered NLRI sent from our neighbor, in a separate table so that we can run it through our new filter locally.
#clear ip bgp soft in will do the trick.
2) Without soft-reconfiguration, clear ip bgp 1.1.1.1 soft will not have any effect.
3) 'Show ip bgp ' should say "Inbound soft reconfiguration allowed" if you have soft-reco configured on the neighbor.
Basically soft-reco stores all of your neighbor updates in memory and applies it when you issue the "clear ip bgp soft" which is why soft-reco consumes a lot of memory.
Routers running Cisco IOS software releases prior to Release 12.1 do not support the route refresh capability and must clear the BGP session using the neighbor soft-reconfiguration command.
Clearing the BGP session using the neighbor soft-reconfiguration command has a negative effect on network operations and should only be used as a last resort.
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-cr-book/bgp-m1.html#wp2269702887
Read BGP Command output
- prefix without explicit subnet mask is /24 (10.0.207.0 = 10.0.207.0/24)
- Locally Originated paths have Weight=32768, Transit Paths Weight=0
- Locally Originated paths have Next_Hop=0.0.0.0, Transit Paths have Next_Hop=Neighbor_IP
- 10.0.206.2 from 10.0.206.2 (8.8.8.8) =
Path 10.0.206.2/24 is reachable via Nexthop_IP known from Router-IP (RID)
- another example ebgp to ibgp without next-hop-self: 193.0.0.1 (inaccessible) from 10.0.192.1 (2.2.2.2)
Router-A# sh ip bgpBGP Local Pref
BGP table version is 7, local router ID is 3.3.3.3
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 10.0.192.1 0 100 0 65000 i
*> 8.8.8.0/24 10.0.206.2 0 0 65501 i
*> 10.0.192.0 0.0.0.0 0 32768 ?
*> 10.0.199.0 0.0.0.0 0 32768 ?
* 10.0.206.0 10.0.206.2 0 0 65501 ?
*> 0.0.0.0 0 32768 ?
* 10.0.207.0 10.0.206.2 0 0 65501 ?
*> 10.0.199.2 100 32768 ?
Router-A# sh ip bgp 10.0.207.0
BGP routing table entry for 10.0.207.0/24, version 6
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0x820
Advertised to update-groups:
1 2
65501, (received & used)
10.0.206.2=next_hop_ip from 10.0.206.2=Neighbor_IP (8.8.8.8 =RID)
Origin incomplete, metric 0, localpref 100, valid, external
Local
10.0.199.2 from 0.0.0.0 (3.3.3.3)
Origin incomplete, metric 100, localpref 100, weight 32768, valid, sourced, best
Router-A#
L_PREF is ignored is neighbor is eBGP.
L_PREF=100 if neighbor is iBGP
L_PREF is not set if neighbor is eBGP or locally originated route
A path without LOCAL_PREF is considered to have had the value set with the bgp default local-preference command, or to have a value of 100 by default.
R1#sh ip bgp
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 0.0.0.0 0 32768 ?
* i2.2.2.0/24 10.0.34.4 0 100 0 2 i
*> 10.0.12.2 0 0 2 i
BGP IGP metric
MED=0 if neighbor is iBGP or locally originated route
MED is received in BGP updates from neighbor.
MED is not set if neighbor is eBGP:
Paths received with no MED are assigned a MED of 0, unless you have enabled bgp bestpath med missing-as-worst .
If you have enabled bgp bestpath med missing-as-worst , the paths are assigned a MED of 4,294,967,294.
R2#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
* i1.1.1.0/24 10.0.34.3 0 100 0 13 ?
*> 10.0.12.1 0 0 13 ?
*> 2.2.2.0/24 0.0.0.0 0 32768 i
* i3.3.3.0/24 10.0.34.3 0 100 0 13 i
*> 10.0.12.1 0 13 i
*>i4.4.4.0/24 10.0.24.4 0 100 0 i
* i5.5.5.0/24 10.0.34.3 1234 100 0 13 i
*> 10.0.12.1 12345 0 13 i
MED vs metric
#show ip bgp 1.1.1.1
*Some text cleared here*
192.168.1.1 (metric 700) from 192.168.1.1 (192.168.1.1)
Origin IGP, Metric 1700, localpref 100, valid, internal, best
(metric 700) - IGP metric to reach next-hop.
Metric 1700 - MED
192.168.1.1 from 192.168.1.1 (192.168.1.1)
next-hop, address of router that gave you update, ID of that router.
BGP communities
While communities themselves do not alter the BGP decision making process, communities can be used as flags in order to mark a set of routes. Upstream service provider routers can then use these flags to apply specific routing polices (for example, local preference) within their network.
The neighbor x.x.x.x send-community instructs the bgp process to send the community values to the bgp peers.
The community attribute is a transitive, optional attribute in the range of 0 to 4,294,967,200. The community attribute is a way to group destinations in a certain community and apply routing decisions according to those communities. The routing decisions are accept, prefer, and redistribute, among others.
You can use route maps to set the community attributes. The route map set command has this syntax:
set community community-number [additive] [well-known-community]A few predefined, well known communities for use in this command are:
- no-export—Do not advertise to eBGP peers. Keep this route within an AS.
- no-advertise—Do not advertise this route to any peer, internal or external.
- internet—Advertise this route to the Internet community. Any router belongs to this community.
- local-as—Use in confederation scenarios to prevent the transmit of packets outside the local AS.
In Cisco IOS Software Release 12.0 and later, you can configure communities in three different formats: decimal, hexadecimal, and AA:NN. By default, Cisco IOS Software uses the older decimal format. In order to configure and display in AA:NN, issue the ip bgp-community new-format global configuration command. The first part of AA:NN represents the AS number, and the second part represents a 2-byte number.
Community: 6553620By default, the community attributes are not sent to the neighbor.
ip bgp-community new-format
! new-format applied
Community: 100:20
! send communities to BGP peerSome communities are standard, some communities are extended.
neighbor 10.10.13.1 send-community
When you are dealing with "regular" BGP (IPv4 address family), in 99.9% cases you will send just standard communities. There are some communities, like for example "BGP Cost Community" that are extended. In that case, you will either send just extended or both.
When you are configuring MPLS VPNs using MP-BGP, extended communities are sent by default and this cannot be disabled. If you want to use standard communities to control the behavior of VPNv4 routes, then you would send both.
BGP aggregate-address
BGP select "network" > "aggregate-address"
R3 <---> R4
Network
ip route 5.5.0.0 255.255.0.0 Null0
router bgp 4
no synchronization
network 5.5.0.0 mask 255.255.0.0
aggregate-address 5.5.0.0 255.255.0.0
redistribute ospf 1 <--- prefix 5.5.6.0/24 imported via OSPF
R3#sh ip bgp 5.5.0.0
BGP routing table entry for 5.5.0.0/16, version 14
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
Advertised to update-groups:
2
4
34.34.34.4 from 34.34.34.4 (10.10.0.1)
Origin IGP, metric 0, localpref 100, valid, external, best
R3#
Aggregate-address
! ip route 5.5.0.0 255.255.0.0 Null0 <-commented
router bgp 4
no synchronization
network 5.5.0.0 mask 255.255.0.0
aggregate-address 5.5.0.0 255.255.0.0
redistribute ospf 1 <--- prefix 5.5.6.0/24 imported via OSPF
R3#sh ip bgp 5.5.0.0
BGP routing table entry for 5.5.0.0/16, version 4
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
Advertised to update-groups:
2
4, (aggregated by 4 10.10.0.1)
34.34.34.4 from 34.34.34.4 (10.10.0.1)
Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, best
R3#
”
A default route is never going to be used to establish a BGP session
(iBGP/eBGP)” - See more at:
http://www.costiser.ro/2013/01/22/quiz-4/#sthash.kvUWG9Z0.dpuf
”
A default route is never going to be used to establish a BGP session
(iBGP/eBGP)” - See more at:
http://www.costiser.ro/2013/01/22/quiz-4/#sthash.kvUWG9Z0.dpuf