Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
29 Cards in this Set
- Front
- Back
ASN - public |
1 to 64511 |
|
ASN - Private |
range of 64512 to 65535 a feature allows the stripping of private AS numbers out of the AS_PATH list before the routes are propagated to a BGP peer. When a private AS number is allocated to the customer network, the BGP updates from the customer network to ISP will have the private AS number in its AS_PATH list. When the ISP propagates its network information to the global BGP table (Internet), it should not propagate the AS_PATH with the private AS number of the customer to the Internet. To help the ISP remove the private AS number from its AS_PATH list, use the Cisco IOS remove-private-as command. To remove the private AS number, use the neighbor x.x.x.x remove-private-as router configuration command. The neighbor x.x.x.x remove-private-as per-neighbor configuration command forces BGP to drop the private AS numbers. You can configure this command for external BGP neighbors. When the outbound update contains a sequence of private AS numbers, this sequence is dropped.
The following conditions apply: *You can only use this solution with external BGP (eBGP) peers. * If the update has only private AS numbers in the AS_PATH, BGP removes these numbers. * If the AS_PATH includes both private and public AS numbers, BGP doesn't remove the private AS numbers. This situation is considered a configuration error. * If the AS_PATH contains the AS number of the eBGP neighbor, BGP does not remove the private AS number. * If the AS_PATH contains confederations, BGP removes the private AS numbers only if they come after the confederation portion of the AS_PATH. |
|
show ip bgp sum |
provides info about memory consmption |
|
neighbor |
causes the router to keep a copy of the received Updates from the specified neighbor. (IOS keeps a copy of sent Updates automatically.) With these Updates available, BGP can simply reapply the changed filtering policy to the Update without closing the neighbor connection. |
|
soft-reconfiguration inbound --- 1 |
the router must apply a copy of the bgp path b4, and after any local policies are applied.
If soft-reconfiguration inbound is configured, the router stores a copy of all unprocessed updates received by its peers for future use, otherwise this table is discarded after putting the routes in Loc-RIB. BGP soft-reconfiguration inbound can be configured by following command:
neighbor 192.0.2.1 soft-reconfiguration inbound #show ip bgp neighbors x.x.x.x received-routes |
|
soft-reconfiguration inbound --- 2 |
If the soft-reconfiguration inbound is not configured for a neighbor, an error is displayed when we try to view the received-routes. This is just because the Adj-RIB-In table is discarded after processing the routes from it and building the Loc-RIB. #show ip bgp neighbors 192.0.2.5 received-routes% Inbound soft reconfiguration not enabled on 192.0.2.5
#show ip bgp neighbors x.x.x.x routes
|
|
Reset BGP sessions |
1. Hard reset: dropping and re-establishing TCP session to our peers. |
|
Reset BGP sessions -- Hard reset |
Hard Reset #clear ip bgp 192.0.2.1 |
|
Reset BGP sessions -- Dynamic Soft REset |
Dynamic route refresh features: * Does not require pre-configuration.* Does not require additional memory for storing routing update information.
To perform dynamic route refresh to apply inbound policies, use the following command: #clear ip bgp 192.0.2.1 in*Mar 1 02:34:04.491: BGP: 192.0.2.1 sending REFRESH_REQ(5) for afi/safi: 1/1 *Mar 1 02:34:04.495: BGP: 192.0.2.1 send message type 5, length (incl. header) 23 or #clear ip bgp 192.0.2.1 soft in *Mar 1 02:34:40.471: BGP: 192.0.2.1 sending REFRESH_REQ(5) for afi/safi: 1/1 *Mar 1 02:34:40.475: BGP: 192.0.2.1 send message type 5, length (incl. header) 23 |
|
Reset GBP sessions --- \Soft Reset |
To reset the BGP using Soft Reset using Stored Information, the following commands can be used:#clear ip bgp 192.0.2.1 soft in or #clear ip bgp 192.0.2.1 in |
|
How BGP routes are propagated into BGP table |
The process:
Adj-RIB-In —> Loc-RIB —> Adj-RIB-Out Adj-RIB-In: The Adj-RIBs-In contains unprocessed routing information that has been advertised to the local BGP speaker by its peers. Loc-RIB: The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process.
|
|
what is implicit withdraw ? |
BGP routers and route reflectors (RRs) propagate only their best path over their sessions. The advertisement of a prefix replaces the previous announcement of that prefix. The implicit withdraw can achieve better scaling, but at the cost of path diversity. |
|
Path hiding |
Path hiding can prevent efficient use of BGP multipath, prevent hitless planned maintenance, and can lead to MED oscillations and suboptimal hot-potato routing. Upon nexthop failures, path hiding also inhibits fast and local recovery because the network has to wait for BGP control plane convergence to restore traffic |
|
BGP Additional Path feature (add-path) and path diversity |
The BGP Additional Paths feature provides a way for multiple paths for the same prefix to be advertised without the new paths implicitly replacing the previous paths. Thus, path diversity is achieved instead of path hiding. |
|
hot-potato routing |
In order to minimize internal transport costs, transit ISPs try to forward packets to the closest exit point (according to Interior Gateway Protocol [IGP] cost). This behavior is known as hot-potato routing passing traffic off to another autonomous system as quickly as possible, thus using their network for wide-area transit.
|
|
BGP Well-Known Mandatory Attributes
|
AS_PATH
NEXT_HOP ORIGIN |
|
BGP Well-Known Discretionary Attributes
|
LOCAL_PREF
ATOMIC_AGGREGATE |
|
BGP Optional Transitive Attributes
|
AGGREGATOR
COMMUNITY |
|
BGP Optional Non-Transitive Attributes
|
MULTI_EXIT_DISC (MED)
ORIGINATOR_ID CLUSTER LIST MULTIPROTOCOL Reachable NLRI MULTIPROTOCOL Unreachable NLRI |
|
BGP Path Selection Mnemonic
|
N Next hop: reachable?
W WEIGHT (bigger) L LOCAL_PREF (bigger) L Locally injected routes A AS_PATH length (smaller) O ORIGIN(pref over I,I over E,E over ?) M MED (smaller) N Neighbor type(prefer eBGP over iBGP) I IGP meric to NEXT_HOP (smaller) |
|
Dynamic Inbound Soft Reset (route refresh)
|
Requests complete refresh of the ADJ-RIB-OUT
is the most preferred method, it requires the route refresh capability. Simply said, this feature lets your router request its BGP neighbor to send its prefixes again. |
|
Soft reset
|
BGP Soft Reset feature provides automatic support for dynamic soft reset of inbound BGP routing table updates that is not dependent upon stored routing table update information. The new method requires no preconfiguration (as with the neighbor soft-reconfiguration command) and requires much less memory than the previous soft reset method for inbound routing table updates
uses extra prefix info stored locally |
|
hard reset
|
It kills the TCP session with your BGP neighbor which forces it to restart and as a result you’ll receive all prefixes from your neighbor again. It works, but it’s cruel…
Tears down peering session and deletes prefixes from the peer |
|
Enhanced Route Refresh
|
The BGP Enhanced Route Refresh feature provides a way for Border Gateway Protocol (BGP) to find route inconsistencies, and in that unlikely event, to synchronize BGP peers without a hard reset. The feature is enabled by default; there are two optional timers.
|
|
BGP state - idle 1
|
the initial state of a BGP connection. The BGP speaker is waiting for a start event, generally either the establishment of a TCP connection or the re-establishment of a previous connection. Once the connection is established, BGP moves to the next state.
|
|
BGP state - Connect 2
|
If the TCP connection completes, BGP will move to the OpenSent stage if the connection does not complete, BGP goes to Active.
|
|
BGP state - Active 3
|
Active indicates that the BGP speaker is continuing to create a peer relationship with the remote router. If this is successful, the BGP state goes to OpenSent. You'll occasionally see a BGP connection flap between Active and Connect. This indicates an issue with the physical cable itself, or with the configuration.
|
|
BGP state - OpenSent
|
indicates that the BGP speaker has received an Open message from the peer. BGP will determine whether the peer is in the same AS (iBGP) or a different AS (eBGP) in this state.
|
|
BGP state - OpenConfirm
|
the BGP speaker is waiting for a keepalive message. If one is received, the state moves to Established, and the neighbor relationship is complete. It is in the Established state that update packets are actually exchanged.
|