BGP Troubleshooting

Troubleshooting BGP – The
Backbone of the Internet
Dheeraj Gera HTTS Engineer Routing Protocols

BRKRST-3320
NETWORK IS DOWN
MYTH
Vs
FACT
BRKRST-3320 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 4
Our eyes are always the same size from birth, but nose and ears never stop
growing.
It takes sixty seconds to trace a call.
Agenda
Troubleshooting Root Cause

steps Path Control analysis
Generic Troubleshooting Steps
BRKRST-3320
BGP peer establishment
Following are the states BGP peer go through to form the neighborship
• Idle State : Release all resources and wait for BGP input event.
• Connect State : Waiting for a TCP connection to be established.
• Active State : Trying to initiate a TCP connection with neighbor.
• Open Sent State : TCP session established and open message sent.
• Open Confirm State: Open message received from neighbor.
• Established State: Keepalive message received from neighbor.
Connect/
Active
TCP session
Yes completed No
Open
Sent
No
Open message
Yes Idle
reply received
Open
No
Confirm
Keepalive
Yes Received
Establish
ed
BGP message Types
è Open Message
è Update Message
è Keepalive Message
è Notification Message*
è Route-Refresh message
*Next page shows the common error code along with subcode which helps us in identifying the issue.
BGP message Types
Notification Message : Sniffer capture
Error Code Error Error Sub-code Subcode Detail RFC
For reference 1 Connection not synchronised 4271
1 Message Header Error 2 Bad Message length 4271
only 3 Bad Message Type 4271
1 Unsupported version number 4271
2 Bad peer AS 4271
3 Bad BGP Identifier 4271
2 Open Message Error 4 Unsupprted optional parameters 4271
5 Authentication failure 4271
6 Unacceptable Hold Time 4271
7 Unsupported capability 5492
1 Malformed attribute list 4271
2 Unrecognised well-known attribute 4271
3 Missing well-known attribute 4271
4 Attribute flag error 4271
5 Attribute length error 4271
3 Update Message error 6 Invalid origin attribute 4271
7 AS routing loop 4271
8 Invalid Next-Hop attribute 4271
9 Optional attribute error 4271
10 Invalid network field 4271
11 Malformed AS_Path 4271
4 Hold-Timer Expired 0 4271
1 Receive unexpected message in open sent state 6608
5 Finite state machine error 2 Receive unexpected message in open confirm state 6608
3 Receive unexpected message in Established state 6608
1 Maximum number of prefixes reached 4486
2 Administrative shutdown 4486
3 Peer De-configured 4486
4 Administrative reset 4486
6 Cease 4486
5 Connection rejected
6 Other configuration changed 4486
7 Connection collision resolution 4486
8 Out of resources 4486
7313
7 Route Refresh Message error 1 Invalid Message length
Troubleshooting Steps
Ø BGP neighbor not coming up

o Need to ensure the connectivity between the peers from physical layer to transport layer.
Ø Is neighbor flapping
ü At regular interval
o Timers getting expired.
ü Not regular interval
o Hard to isolate and could be due to any issue in the physical path.
BGP Neighbor not coming up:

èCheck the output of “Show ip bgp summary” to verify the neighbor state and the time it is in that state.
R103# sh ip bgp summary

BGP router identifier 66.66.66.67, local AS number 700
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
20.0.0.1 4 700 0 0 1 0 0 00:08:23 Idle
èCheck the output of “show logs” on both neighbors to look for the error code and sub-code.
%BGP-3-NOTIFICATION: sent to neighbor 20.0.0.1 4/0 (hold time expired) 0 bytes
%BGP-5-NBR_RESET: Neighbor 20.0.0.1 reset (BGP Notification sent)
èCheck the output of “Show ip bgp neighbor <neighbor’s Ip address> form both neighbors
R103#sh ip bgp neighbors 20.0.0.1 | in state|route|reset|link
BGP neighbor is 20.0.0.1, remote AS 700, internal link
BGP state = Idle
Address tracking is enabled, the RIB does not have a route to 20.0.0.1
Last reset 00:21:30, due to BGP protocol initialization
Interface associated: (none) (peering address NOT in same link)
R101#sh ip bgp neighbors 20.0.0.2 | in state|route|reset|link

BGP neighbor is 20.0.0.2, remote AS 700, local AS 700, internal link
BGP state = Active
Address tracking is enabled, the RIB does have a route to 20.0.0.2
Last reset 00:21:45, due to Active open failed
Interface associated: (none) (peering address in same link)
èEnsure that we have the route for the neighbor.

Success rate is 0 percent (0/5)
R103#sh ip route 20.0.0.1
% Network not in table
R101#sh ip route 20.0.0.2

Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Ethernet0/2
Route metric is 0, traffic share count is 1
èIn this case, it clearly indicates, that the issue is on the device R103 as it doesn’t have the
route to destination.
è On checking further, we were able to confirm that the link connected was shut.
è However, now we have the route and are able to ping, still neighborship is down. What
next?
Able to ping the neighbor IP successfully:
R103#ping 20.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
èEnsures, we have the route in routing table and CEF entry exist for the neighbor.
è Still BGP state is Idle

BGP neighbor is 20.0.0.2, remote AS 700, local AS 700, internal link
BGP state = Idle
Do log neighbor state changes (via global configuration)
Last reset never
Interface associated: (none) (peering address NOT in same link)
èThe error points an issue with the connected link. Need to verify the configuration if the link
used is same or not.
neighbor 20.0.0.1 update-source Loopback0
è Verified loopback interface was already shut thus causing the issue.
è Once the statement was removed the BGP neighborship was restored.
R101#sh tcp brief
TCB Local Address Foreign Address (state)
F2797DB0 20.0.0.1.20982 20.0.0.2.179 ESTAB
R103#sh ip bgp neighbors 20.0.0.1 | in state|link|reset|route

BGP neighbor is 20.0.0.1, remote AS 700, internal link
BGP version 4, remote router ID 11.11.11.11
BGP state = Established, up for 00:01:01
Last reset 01:55:57, due to BGP protocol initialization
Interface associated: (none) (peering address in same link)
è If the BGP neighborship is flapping between connect idle and active, following command
outputs can help as to why TCP session is not getting established.
è IBGP neighbor will show TTL=255 and EBGP will show TTL=1 by default.
R101#sh tcp tcb F2797DB0 | in TTL|Prec|host|state

Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
Local host: 20.0.0.1, Local port: 20982
Foreign host: 20.0.0.2, Foreign port: 179
IP Precedence value : 6
è Once we change it to EBGP neighbor, then following is the output seen confirming TTL
value of 1 is sent
R101#sh tcp tcb F5236608 | in TTL|Prec|host|state
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 20.0.0.1, Local port: 61757
Foreign host: 20.0.0.2, Foreign port: 179
IP Precedence value : 6
BGP neighbor flapping at regular intervals:
When it is flapping at fixed interval and interval is BGP hold down time always then mostly it is due to MTU
issue in the path
è Check the tcp max segment data for the neighbor and verify if path mtu discovery is enabled.
è Path MTU discovery if enabled doesn’t allow packets to be fragmented between the BGP neighbor
below max data segment.
è Ensure that the path between the neighbors must have the MTU above the max data segment size.
è If not, then we have to manually configure tcp adjust-mss command on all the involved interfaces.
è Ensure ICMP traffic is not blocked along the path.
R103#sh ip bgp neighbor 20.0.0.1 | in tcp|segment

Transport(tcp) path-mtu-discovery is enabled
Datagrams (max data segment is 1436 bytes):
BGP neighbor flapping not at regular intervals:
Reasons:
è Physical layer connectivity in the path.
è Due to queue drop on router.
è BGP control packets getting dropped while going from router port to router CPU.
è In this case also, we must ensure that we are able to ping the destination IP.
è Check for any drops on the router by running “show interface” command.
è Check for any CPU spikes on the router via command ”show proc cpu sorted | ex 0.0”
è Check for any memory issues on the router via commands:
o Show memory statistics
o Show memory processor allocating-process totals
èMost of the times flap occur for few minutes and then the session is restored.
è In these scenarios we can make use of “EEM script” to collect the logs.
event manager applet BGP_DOWN

event syslog pattern "%BGP-3-NOTIFICATION: sent to neighbor 20.0.0.1 4/0 (hold time expired)*"
action 1.0 syslog msg "EEM_SCRIPT_TRIGGERED"
action 1.1 cli command "show proc cpu sort | append flash:BGP_DOWN.txt"
action 1.2 cli command "show clock | append flash:BGP_DOWN.txt"
action 1.3 cli command "show mem stat | append flash:BGP_DOWN.txt"
action 1.4 cli command "show ip bgp neighbor 20.0.0.1 | append flash:BGP_DOWN.txt"
action 1.5 cli command "show memory processor allocating-process totals | append
flash:BGP_DOWN.txt"
If the issue is related to high CPU on the device due to BGP, following are the processes seen.
Process Name Description
BGP Open BGP peer establishment
BGP I/O Queuing and processing of BGP packets
BGP Scanner èCheck next_hop reachability

èCheck conditional advertisement
èPerforms route dampening
èIn L3VPN, it imports / exports routes into particular VRF
BGP Router èCalculates best BGP path and processes any route churn.
è Establishes peer and interacts with RIB.
èBGP Scanner is the process which runs once per minute to validate whether the next hop is
reachable for the prefixes in the BGP routing table and thus may consume more time for more prefixes.
è BGP router process is directly related with the BGP convergence or the time BGP process takes from
peer establishment to installing the routes in the routing table.
Commands helpful in troubleshooting BGP.
è Show ip bgp summary R101#ping 20.0.0.2 size 1500 df-bit
è Show ip bgp neighbor <neighbor_ip> Type escape sequence to abort.

Sending 5, 1500-byte ICMP Echos to 20.0.0.2, timeout is 2
è Show tcp brief seconds:
Packet sent with the DF bit set
è Show tcp tcb <tcb#>
!!!!!
è Show proc cpu sort | ex 0.0 Success rate is 100 percent (5/5), round-trip min/avg/max =
1/1/1 ms
è Show memory statistics
R101#traceroute 20.0.0.2 port 179 ttl 1 1
è Show ip route <next_hop>
Type escape sequence to abort.
è Using extended ping Tracing the route to 20.0.0.2
VRF info: (vrf in name/id, vrf out name/id)
è Using extended traceroute to verify port
179 is open 1 20.0.0.2 1 msec * 1 msec
Q&A
Received following log on the device:
%BGP-3-NOTIFICATION: sent to neighbor 20.0.0.1 passive 2/2 (peer in wrong AS) 2 bytes 012C
Q&A
Received following log on the device:
%BGP-3-NOTIFICATION: sent to neighbor 20.0.0.1 passive 2/2 (peer in wrong AS) 2 bytes 012C
è We have specified wrong AS while configuring “neighbor remote-as command”
router bgp 300 router bgp 300

neighbor 20.0.0.2 remote-as 300 neighbor 20.0.0.1 remote-as 100
Q&A
After we reach more than 1000 prefixes our BGP neighbor flaps and it keeps on
flapping every three minutes until we reduce the number of prefixes.
Q&A
After we reach more than 1000 prefixes our BGP neighbor flaps and it keeps on
flapping every three minutes until we reduce the number of prefixes.
èPath MTUD(Maximum transmission Unit discovery) feature is enabled on both ends of the neighbor, however
layer 2 in path is having MTU configured less.
R103#sh ip bgp neighbor 20.0.0.1 | in

tcp|segment
Transport(tcp) path-mtu-discovery is
enabled
Datagrams (max data segment is 1436 bytes):
èVerify across the path that all the interfaces have the mtu to support the data segment via checking the output of
“show ip interface <interface name>”
èPath MTU discovery determined incorrect max data size for TCP BGP session.
èCheck for any access-list blocking the ICMP traffic in the path.
PATH CONTROL
BRKRST-3320
BGP RIB
• Once the neighborship is up, next thing is to add the prefixes learnt from the
neighbor into the database.
Incoming BGP Outgoing BGP
Updates Updates
BGP
BGP BGP Adj-RIBs-
Adj-RIBs-In Loc-RIB Out
Incoming BGP Decision Outgoing

Policy Process Policy
Routing information Database(RIB) consist of three parts:

Adj-RIBs-In: Stores unprocessed routing information that has been learned from the updates
received from peers.
Loc-RIB: Contains the routes that BGP speaker has selected by applying its local routing policies to
routes contained in Adj-RIBs-In. These routes next-hop must be reachable via router.
Adj-RIBs-Out: Contains the routes that BGP speaker advertises to its peer after applying any
outbound policy.
Path Control
• When BGP should be run in our environment is not a mystery, however we must
consider various factors before putting it into picture.
• It is used when we are multihomed to multiple ISP’s or even same ISP when we
want to have a better control of what path our traffic will take.
For Reference only
Attribute Class RFC Application
ORIGIN Well-known mandatory 4271 Policy
AS_PATH Well-known mandatory 4271 Policy, loop detection
NEXT_HOP Well-known mandatory 4271 Policy
LOCAL_PREF Well-known discretionary 4271 Policy
ATOMIC_AGGREGATE Well-known discretionary 4271 Address aggregation
AGGREGATOR Optional transitive 4271 Address aggregation
COMMUNITIES Optional transitive 1997 Scaling
EXTENDED COMMUNITY Optional transitive 4360 Scaling
MULTI EXIT DISC Optional nontransitive 4271 Policy
ORIGINATOR_ID Optional nontransitive 4456 Scaling, loop detection, policy
CLUSTER_LIST Optional nontransitive 4456 Scaling, loop detection, policy
AS4_PATH Optional transitive 6793 Scaling, policy

AS4_AGGREGATOR Optional transitive 6793 Scaling, address aggregation
MULTIPROTOCOL Optional nontransitive 4760 Multiprotocol BGP
REACHABLE NLRI
MULTIPROTOCOL Optional nontransitive 4760 Multiprotocol BGP

UNREACHABLE NLRI
Path Control
Path Attribute Impact
WEIGHT <Higher is better> Outbound path control
LOCAL_PREFERENCE <Higher is better> Outbound path control
METRIC to IGP next-hop <lower is better> Outbound path control
AS_PATH< Lower is preferred> Inbound path control
MED <Lower is preferred> Inbound path control
Origin IGP>EGP>Incomplete
Note: Before evaluating any attribute, NEXT_HOP must be reachable.
Route Refresh
Note: whenever we are changing the path preference via use of any attributes, we must either have patience
for it take into effect or make use of the following command:
clear ip bgp * soft
Following messages are generated
It marks refersh start-of-RIB from the output of “show ip bgp neighbor” command.
Route Refresh
Route Refresh
Do we get multiple update messages for different prefixes?
è The answer is yes and no.
è Below debug logs show that if prefixes share same attributes, they are clubbed under one update.
BGP: nbr_topo global 35.0.0.2 IPv4 Unicast:base (0xF27CB680:1) rcvd Refresh Start-of-RIB
BGP: nbr_topo global 35.0.0.2 IPv4 Unicast:base (0xF27CB680:1) refresh_epoch is 2
BGP(0): 35.0.0.2 rcvd UPDATE w/ attr: nexthop 35.0.0.2, origin ?, localpref 500, metric 0
BGP(0): 35.0.0.2 rcvd 54.54.54.54/32...duplicate ignored
BGP(0): 35.0.0.2 rcvd UPDATE w/ attr: nexthop 35.0.0.2, origin ?, localpref 200, metric 0
BGP: nbr_topo global 35.0.0.2 IPv4 Unicast:base (0xF27CB680:1) rcvd Refresh End-of-RIB
Q&A
• I want to chose ISP A rather than ISP B for connecting to internet and would like
to choose ISP B only for connecting to specific Server.
EBGP
R101
ISPA
AS 300
EBGP
ISPB R103
Q&A
• I want to chose ISP A rather than ISP B for connecting to internet and would like to choose ISP B only
for connecting to specific Server.
è LOCAL_PREF can be chosen in this scenario.
Route-map can be used to set the local preference value. And we can apply the route-map in the inbound direction for the
EBGP neighbor.
EBGP
Local_Pref =200
R101
ISPA
AS 300
Local_Pref =100
EBGP
ISPB R103
Root Cause Analysis
BRKRST-3320
Issue 1: RIB failure routes are seen
è In this scenario, we are seeing RIB failure in the output of “Show Ip bgp”.
Topology Involved
EBGP
10.0.0.0/30
AS 100 R100 R101
10.0.0.128/30 20.0.0.0/24 AS 300
10.0.0.32/30
EBGP
AS 200 R102 R103
Probable cause of the issue:
- Route is being learned via IGP/connected routes and not redistributed into BGP
or the tables are not synced.
It can be confirmed via the following command:
R100#sh ip bgp rib-failure
Network Next Hop RIB-failure RIB-NH Matches
10.0.0.0/30 10.0.0.2 Higher admin distance n/a
R100#sh ip route 10.0.0.0 255.255.255.252

Routing entry for 10.0.0.0/30
Known via "connected", distance 0, metric 0
(connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Ethernet0/0
Route metric is 0, traffic share count is 1
Configuration on the routers in the topology
R101#sh run | sec bgp
router bgp 300
bgp log-neighbor-changes
router bgp 200
network 0.0.0.0
network 10.0.0.0 mask 255.255.255.252
network 2.2.2.2 mask 255.255.255.255
network 11.11.11.11 mask
neighbor 10.0.0.34 remote-as 300
255.255.255.255
network 20.0.0.0 mask 255.255.255.0

router bgp 100
è Now if we add the statement either network or redistribute, the rib failure will not
be seen.
Modified configuration of router R100

router bgp 100
redistribute connected
Excerpts to confirm that rib failure has been removed:
Network Next Hop Metric LocPrf Weight Path

*> 0.0.0.0 10.0.0.2 0 300 200 i
*> 1.1.1.1/32 0.0.0.0 0 32768 ?
*> 2.2.2.2/32 10.0.0.130 0 0 200 i
* 3.3.3.3/32 10.0.0.130 0 200 300 i
*> 10.0.0.2 0 300 i
*> 10.0.0.0/30 0.0.0.0 0 32768 ?
* 10.0.0.130 0 200 300 i
* 10.0.0.2 0 0 300 i
Issue 2: Traffic not coming from preferred path
è When we are multihomed to single ISP, we often want to prefer one path for one
set of prefixes and the other path for other set of prefixes.
è We can change the path, traffic will take while leaving our AS by making use of
various path attributes, but most of the times local_pref takes care of the same.
è But the path taken by the remote side to reach our AS needs some further
attention.
è We’ll
discuss a scenario where MED is used, however still the path chosen by
remote side is not the preferred one.
Topology Involved:
AS 100
EBGP 35.0.0.0/30
10.0.0.0/30
R100 R101
R105
10.0.0.128/30 20.0.0.0/24 IBGP
AS 300
AS 200
10.0.0.32/30 Server IP:
EBGP 55.55.55.55
R102 R103 66.66.66.66
è We want to prefer that anyone who wants to connect to our Servers with IP
address 55.55.55.55 and 66.66.66.66 prefer the path via AS 200 rather than AS
100.
è Ifthe user who wants to connect to server is behind AS100, it will prefer the path
connecting straight to AS 300 due to AS_PATH attribute.
è To make this work we have to make use of the following statement on R100
bgp bestpath as-path ignore
èAlong with this to provide preference to metric , we have to use the following
statement on R100
bgp always-compare-med
è In
this case, customer was advertising the metric from his router R101 with a
value of 300 for the prefix and R102 with a prefix value of 100. However R100
was ignoring the metric because it comes after AS_path attribute in the
preference.
Excerpts to confirm:
R100#sh ip bgp 55.55.55.55

BGP routing table entry for 55.55.55.55/32, version 249
Paths: (2 available, best #1, table default)
300
10.0.0.2 from 10.0.0.2 (11.11.11.11)
Origin incomplete, metric 300, localpref 100, valid, external, best
200 300
10.0.0.130 from 10.0.0.130 (22.22.22.22)
Origin incomplete, metric 100, localpref 100, valid, external
è After making the changes on the Router R100, we can see that the preferred
path has changed and is due to metric.
router bgp 100 R100#sh ip bgp 55.55.55.55
bgp always-compare-med BGP routing table entry for 55.55.55.55/32, version 196
bgp bestpath as-path ignore Paths: (2 available, best #2, table default)
neighbor 10.0.0.2 remote-as 300 300
neighbor 10.0.0.130 remote-as 200 10.0.0.2 from 10.0.0.2 (11.11.11.11)
Origin incomplete, metric 300, localpref 100, valid,
external
200 300
10.0.0.130 from 10.0.0.130 (22.22.22.22)
Origin incomplete, metric 100, localpref 100, valid,
external, best
Note: The command used in this scenario to compare MULTI EXIT DISC(MED) is
“bgp always-compare-med”
è It compares metric value from different AS and prefer the path with lowest
metric.
There is one more command for comparing MED
“bgp deterministic-med”
èRoutes from the same autonomous system are grouped together and med is
compared within the group.
èThe best entries of each group are compared based on the preference criteria
other than MED.
Issue 3: Routes not learned from peer across MP-BGP cloud
Virtual Routing Forwarding(VRF):

èIt is used to segregate customer specific routes from the global routing table and to segregate the same
it make use of Route distinguisher known as RD.
Main Use case: L3VPN MPLS
RT behaviour between two PE routers:

è When we configure vrf's on router PE1 and router PE2 and use MPLS to export the RT's value amongst
them. Then routes that are exported via PE2 will be accepted via PE1 if we have the import statement for
the specific RT's.
• After making use of vrf the prefix 7.7.7.7/32 with RD 2:2 is seen as
2:2:7.7.7.7/32
Which makes it unique form other customer having prefix of 1:1:7.7.7.7/32
What is MP-BGP and its role in MPLS L3VPN setup?
MP-BGP or multiprotocol BGP is an extension to BGP that allows different
address families to be distributed in parallel. In L3VPN, we need different address-
family for vrf and a different address-family for forming neighborship internally.
Sniffer capture showing negotiation of MP-BGP capability for ipv4 unicast
Customer Scenario:
Routes from customer A1 are not getting advertised to the remote peer across the MPLS cloud on customer A2.
Topology:
Customer A1 ISP Cloud Customer A2
Considering customer configuration is good and he is forming BGP

neighborship with the PE router. Let’s have a look at the PE configuration:
router bgp 200
router bgp 200 bgp log-neighbor-changes
bgp log-neighbor-changes neighbor 10.0.0.33 remote-as 200
neighbor 20.0.0.1 remote-as 200 !
! address-family vpnv4
address-family vpnv4 neighbor 10.0.0.33 activate
neighbor 20.0.0.1 activate neighbor 10.0.0.33 send-community
neighbor 20.0.0.1 send- both
community both exit-address-family
exit-address-family !
! address-family ipv4 vrf A
address-family ipv4 vrf A neighbor 10.0.0.1 remote-as 700
neighbor 27.0.0.2 remote-as 700 neighbor 10.0.0.1 activate
neighbor 27.0.0.2 activate exit-address-family
exit-address-family
VRF configuration on the respective PE routers:
vrf definition A vrf definition A

rd 1:1 rd 2:2
! !
address-family ipv4 address-family ipv4
route-target export 100:4 route-target export 40:40
route-target import 40:40 route-target export 100:2
route-target import 100:1 route-target import 10283:281815000
exit-address-family exit-address-family
Confirming that routes advertised by remote peers are not received on CE routers
A1#sh ip bgp vpnv4 vrf A 7.7.7.7/32 A2#sh ip bgp vpnv4 vrf A 1.1.1.1/32
% Network not in table % Network not in table
Further confirming that the routes are advertised by PE routers:

PE1#sh ip bgp vpnv4 vrf A neighbor 10.0.0.1 advertised-routes
Route Distinguisher: 1:1 (default for vrf A)
*>i 7.7.7.7/32 10.0.0.33 0 100 0 700 ?
*>i 27.0.0.0/30 10.0.0.33 0 100 0 700 ?
PE2#sh ip bgp vpnv4 vrf A neighbors 27.0.0.2 advertised-routes

Route Distinguisher: 2:2 (default for vrf A)
*>i 1.1.1.1/32 20.0.0.1 0 100 0 700 ?
*>i 10.0.0.0/30 20.0.0.1 0 100 0 700 ?
Customer A1 ISP Cloud Customer A2
AS 700 AS 200 AS 700
The issue we are facing is that we are receiving the prefix with AS_path 200_700, which
contains the AS path customer A2 is running. It can be confirmed via following debug log:
BGP(0): 27.0.0.1 rcv UPDATE w/ attr: nexthop 27.0.0.1, origin ?, originator 0.0.0.0, merged path 200 700,
AS_PATH ,
community , extended community , SSA attribute
BGP(0): 27.0.0.1 rcv UPDATE about 10.0.0.0/30 -- DENIED due to: AS-PATH contains our own AS;
To resolve the issue, we need the following command on the PE

routers BGP configuration for the customer vrf.
Neighbor <neighbor_ip> as-override
A1#sh ip bgp vpnv4 vrf A 1.1.1.1/32 A2 #sh ip bgp vpnv4 vrf A 7.7.7.7
BGP routing table entry for 1:1.1.1.1/32, BGP routing table entry for 7.7.7.7/32,
version 13 version 12
Paths: (1 available, best #1, table A) Paths: (1 available, best #1, table A)
200 200 200 200
27.0.0.1 (via vrf A) from 27.0.0.1 10.0.0.2 (via vrf A) from 10.0.0.2
(2.2.2.2) (11.11.11.11)
Origin incomplete, localpref 100, Origin incomplete, localpref 100,
valid, external, best valid, external, best
Q& A
In the following call flow customer in vrf A wants to learn the prefixes
advertised by customer in vrf B?
Global Routing
Prefixes in vrf A table Prefixes in vrf B
1.2.3.4/32 10.0.0.0/30 2.3.4.5/32
R100 R101
AS200 AS200
vrf definition A vrf definition B
rd 200:2 rd 200:1
! !
address-family ipv4 address-family ipv4
exit-address-family exit-address-family
Q& A
In the following call flow customer in vrf A wants to learn the prefixes
advertised by customer in vrf B?
Global Routing
Prefixes in vrf A table Prefixes in vrf B
1.2.3.4/32 10.0.0.0/30 2.3.4.5/32
R100 R101
AS200 AS200
Need to enable address-family vpnv4 on both the routers and send-community to exchange the
same on both sides.
Router bgp 200
Address-family vpnv4
Neighbor 10.0.0.2 send-community
Issue 4: BGP local-as not working
What is Local AS and when is it used?
èOne customer X having his own AS acquired a different company Y which is
having a different AS of their own. The requirement is to move them under one
autonomous system without impacting business.
è During the transit phase before completely merging into one, we can make use
of local-as feature which allows customer Y to use customer’s X AS number
while sending BGP updates.
Customer Scenario:
Want to exclude the internal AS number and advertise only local AS to the
customer
Topology Involved:
Customer X Customer Y CE router
Configuration for ISP X
router bgp 100
Configuration on CE router bgp log-neighbor-changes
router bgp 200 network 10.0.0.0 mask 255.255.255.252
Configuration for ISP Y acquired by ISP X
router bgp 300

neighbor 10.0.0.33 local-as 100
è After configuring local-AS the CE router is advertising the actual AS as well as local-AS in its AS_PATH
sequence.
Show ip bgp
* 20.0.0.0/24 10.0.0.34 0 0 100 300 ?
*> 10.0.0.129 0 100 300 ?
èNeed to make the following change to make it work:
“neighbor 10.0.0.33 local-as 100 no prepend replace-as”
Show ip bgp
*> 20.0.0.0/24 10.0.0.34 0 0 100 ?
* 10.0.0.129 0 100 300 ?
è Autonomous system 300 is removed while advertising the routes out.
LOCAL-AS in IBGP
èSupport of LOCAL-AS in IBGP was introduced from 15.3(3)M.
èOne good use of Local-AS is required when we want to form IBGP neighbor with the acquired AS to
carry out local_pref attribute for manipulating the outbound traffic.
R101
RR(AS200)
11.11.11.11
R105
R100 100.100.100.100
Local AS 700
AS200
Prefix advertised with local_pref: 500
AS700
è 54.54.54.54
R103
AS700
66.66.66.67
LOCAL-AS in IBGP
Configuration on R105 Configuration on R100

router bgp 200 router bgp 700
neighbor 35.0.0.1 route-map LOCAL out
!
route-map LOCAL permit 10 Configuration on Router R103
match ip address local router bgp 700
set local-preference 500 neighbor 20.0.0.1 remote-as 700
LOCAL-AS in IBGP
RR Configuration
router bgp 200
!
address-family ipv4
redistribute connected
neighbor 10.0.0.1 activate
neighbor 10.0.0.1 route-reflector-client
LOCAL-AS in IBGP
• Now we are sending few prefixes with local_preference as 500 and that is
getting across the EBGP neighbor and the decisions are made based on
highest local_pref across the EBGP cloud.
R103#show ip bgp 54.54.54.54
BGP routing table entry for 54.54.54.54/32, version 448
Paths: (1 available, best #1, table default)
Local
35.0.0.2 (metric 20) from 20.0.0.1 (11.11.11.11)
Origin incomplete, metric 0, localpref 500, valid, internal, best
Originator: 100.100.100.100, Cluster list: 11.11.11.11
MYTH
Vs
FACT
We need to configure “ebgp multihop” command if we are
forming EBGP neighborship between two directly connected
neighbors over loopback address.
We need to configure “ebgp multihop” command if we
are forming EBGP neighborship between two directly
connected neighbors over loopback address.
EBGP Multihop is used to increase the TTL count from 1 to the number required. However, if
we disable the connected-check parameter by using command “neighbor disable-connected-
check”. Neighborship will come up with TTL count of 1.
If the IGP and BGP tables are not sync we can see RIB
failures.
We will be able to learn the prefixes from the remote-site
across MPLS cloud in the same AS by making use of
neighbor allow-as in
Queries !!!
Q&A
Cisco Spark
Ask Questions, Get Answers, Continue the Experience
Use Cisco Spark to communicate with the Speaker and fellow

participants after the session
Download the Cisco Spark app from iTunes or Google Play

1. Go to the Cisco Live Melbourne 2017 Mobile app
2. Find this session
3. Click the Spark button under Speakers in the session description
4. Enter the room, room name = BRKRST-3320
5. Join the conversation!
The Spark Room will be open for 2 weeks after Cisco Live
© 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 80
Complete Your Online Session Evaluation
Give us your feedback and receive a
Cisco Live 2017 Cap by completing the
overall event evaluation and 5 session
evaluations.
All evaluations can be completed via

the Cisco Live Mobile App.
Caps can be collected Friday 10 March Learn online with Cisco Live!
at Registration. Visit us online after the conference
for full access to session videos and
presentations.
www.CiscoLiveAPAC.com
Thank you

BGP Troubleshooting

Uploaded by

Copyright:

Available Formats

BGP Troubleshooting

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BGP Troubleshooting

Uploaded by

Copyright:

Available Formats

Troubleshooting BGP – The

Backbone of the Internet

Dheeraj Gera HTTS Engineer Routing Protocols

Troubleshooting Root Cause

Notification Message : Sniffer capture

Ø BGP neighbor not coming up

BGP Neighbor not coming up:

R103# sh ip bgp summary

R101#sh ip bgp neighbors 20.0.0.2 | in state|route|reset|link

èEnsure that we have the route for the neighbor.

R101#sh ip route 20.0.0.2

è Still BGP state is Idle

R103#sh ip bgp neighbors 20.0.0.1 | in state|link|reset|route

R101#sh tcp tcb F2797DB0 | in TTL|Prec|host|state

R103#sh ip bgp neighbor 20.0.0.1 | in tcp|segment

event manager applet BGP_DOWN

BGP Open BGP peer establishment

BGP I/O Queuing and processing of BGP packets

BGP Scanner èCheck next_hop reachability

è Show ip bgp neighbor <neighbor_ip> Type escape sequence to abort.

è We have specified wrong AS while configuring “neighbor remote-as command”

router bgp 300 router bgp 300

R103#sh ip bgp neighbor 20.0.0.1 | in

Incoming BGP Decision Outgoing

Routing information Database(RIB) consist of three parts:

AS4_PATH Optional transitive 6793 Scaling, policy

MULTIPROTOCOL Optional nontransitive 4760 Multiprotocol BGP

LOCAL_PREFERENCE <Higher is better> Outbound path control

METRIC to IGP next-hop <lower is better> Outbound path control

AS_PATH< Lower is preferred> Inbound path control

MED <Lower is preferred> Inbound path control

Note: Before evaluating any attribute, NEXT_HOP must be reachable.

AS 100 R100 R101

10.0.0.128/30 20.0.0.0/24 AS 300

R100#sh ip route 10.0.0.0 255.255.255.252

R100#sh run | sec bgp

R100#sh run | sec bgp

Excerpts to confirm that rib failure has been removed:

Network Next Hop Metric LocPrf Weight Path

R100#sh ip bgp 55.55.55.55

Virtual Routing Forwarding(VRF):

Main Use case: L3VPN MPLS

RT behaviour between two PE routers:

Sniffer capture showing negotiation of MP-BGP capability for ipv4 unicast

Customer A1 ISP Cloud Customer A2

Considering customer configuration is good and he is forming BGP

VRF configuration on the respective PE routers:

vrf definition A vrf definition A

Further confirming that the routes are advertised by PE routers:

PE2#sh ip bgp vpnv4 vrf A neighbors 27.0.0.2 advertised-routes

Customer A1 ISP Cloud Customer A2

AS 700 AS 200 AS 700

To resolve the issue, we need the following command on the PE

Customer X Customer Y CE router

Configuration for ISP Y acquired by ISP X

router bgp 300

* 20.0.0.0/24 10.0.0.34 0 0 100 300 ?

*> 10.0.0.129 0 100 300 ?

èNeed to make the following change to make it work: