SC Labs | Networking notes (CCNA R/S, CCNA Sec, CCNP R/S, VMWare): CCNP Route

BGP
- 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 commands
bgp> 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 configuration
no bgp enforce-first-as

peer x.x.x.x next-hop-local
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.

1) Soft-reconfiguration inbound does not automatically update the bgp table.
#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 bgp
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#

BGP Local Pref
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: 6553620
ip bgp-community new-format
! new-format applied
Community: 100:20

By default, the community attributes are not sent to the neighbor.

! send communities to BGP peer
neighbor 10.10.13.1 send-community

Some communities are standard, some communities are extended.
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

Pages

CCNP Route - BGP part 6: Case Studies, Labs, FAQs