IN
TE
R
N
AL
U
SE
O
N
LY
<Course
BGP
Troubleshooting
Title>
AL
U
SE
O
N
LY
BGP Troubleshooting
N
Common Sources of BGP Peering Problems
R
BGP rides on top of TCP/IP, hence TCP/IP connectivity is crucial in BGP operations. If a BGP session
does not come up the first thing, you should check whether two peers can reach each other using
the session IP address.
TE
If IP reachability is verified, then BGP misconfiguration can lead to the BGP session—stays in Active
or Connect state.
If authentication is configured, an mismatched key will disrupt TCP and so BGP communication.
IN
And last, but not least, incorrectly configured firewall filters blocking BGP TCP port 179 prevent BGP
communication as well.
Hardware and Software Problems
No hardware or software problems are intentionally introduced In the exam. Nevertheless, if you
suspect that the problem is related to hardware or software, notify your proctor immediately.
2
www.juniper.net
AL
U
SE
O
N
LY
BGP Troubleshooting
N
Monitoring BGP Sessions
R
To start BGP monitoring, use the show bgp summary command. The example on the slide shows
two BGP sessions that stay down: one is in Idle state and another is in Active state.
TE
If a session stays in Idle state, BGP cannot try to establish the session. Possible reasons can be IP
address allocation or TTL on multihop EBGP session.
IN
If a session stays in Active or Connect state, bidirectional BGP communication is not successful.
Numerous reasons can make BGP bounce in these states. Among them are IP reachability, BGP
parameters misconfiguration, authentication, and firewall filters.
www.juniper.net
3
AL
U
SE
O
N
LY
BGP Troubleshooting
N
IP Connectivity Between two Peers
R
To verify IP connectivity using the session IP address, use ping utility:
lab@R1> ping 172.27.255.3 source 172.27.255.1
TE
If the ping fails, check IP routing:
lab@R1> show route 172.27.255.3
Check BGP Configuration Parameters
IN
Verify the parameter settings using the show protocols bgp group command:
[edit]
lab@R1# show protocols bgp group IBGP
type internal;
local-address 172.27.255.1;
authentication-key "$9$I56hyKX7V4aUM8aUjH5TRhS"; ## SECRET-DATA
export NHS;
neighbor 172.27.255.3;
neighbor 172.27.255.4;
Continued on next page.
4
www.juniper.net
BGP Troubleshooting
Verify Authentication Settings
Check the authentication settings:
LY
lab@R1> show bgp neighbor 172.27.255.3
Peer: 172.27.255.3 AS 3895077211 Local: 172.27.255.1 AS 3895077211
Type: Internal
State: Active
Flags: <>
Last State: Idle
Last Event: Start
Last Error: None
Export: [ NHS ]
Options: <Preference LocalAddress AuthKey LogUpDown AddressFamily Refresh>
Authentication key is configured
Address families configured: inet-unicast inet6-labeled-unicast
Local Address: 172.27.255.1 Holdtime: 90 Preference: 170
NLRI inet6-labeled-unicast: ExplicitNull
Number of flaps: 0
Monitor the syslog messages File
O
N
Consider temporarily disabling the authentication to eliminate the potential problem.
Syslog can provide an invaluable source of information for troubleshooting.
Check Firewall Filters
U
SE
lab@R4> show log messages | match NOTIFICATION
Jul 29 00:05:29 R4 rpd[1068]: bgp_rt_maxprefixes_check_common:6856: NOTIFICATION
sent to 2008:4498:0:1::2 (External AS 65432): code 6 (Cease) subcode 1 (Maximum
Number of Prefixes Reached) AFI: 2 SAFI: 1 prefix limit 12
Jul 29 00:06:01 R4 rpd[1068]: bgp_pp_recv:2961: NOTIFICATION sent to
2008:4498:0:1::2+64490 (proto): code 2 (Open Message Error) subcode 5 (authentication
failure), Reason: no group for 2008:4498:0:1::2+64490 (proto) from AS 65432 found
(peer idled due to prefix-limit violation), dropping him
AL
In the exam, you might be asked to configure firewall filters. Check the BGP session status after the
filters are implemented to make sure that the filters do not block BGP communication.
N
Use traceoptions
If you still cannot find the source of problem with BGP, use traceoptions to debug BGP sessions.
IN
TE
R
lab@R4> show log bgp-trace.log
Feb 11 12:52:31.750571 BGP RECV 201.201.0.1+179 -> 10.0.3.4+3291
Feb 11 12:52:31.750622 BGP RECV message type 1 (Open) length 45
Feb 11 12:52:31.750668 BGP RECV version 4 as 65011 holdtime 90 id 201.201.0.1 parmlen
16
Feb 11 12:52:31.750692 BGP RECV MP capability AFI=1, SAFI=1
Feb 11 12:52:31.750707 BGP RECV Refresh capability, code=128
Feb 11 12:52:31.750718 BGP RECV Refresh capability, code=2
Feb 11 12:52:31.751108 bgp_process_open: NOTIFICATION sent to 201.201.0.1 (External
AS 65010): code 2 (Open Message Error) subcode 2 (bad peer AS number), Reason: peer
201.201.0.1 (External AS 65010) claims 65011, 65010 configured
Feb 11 12:52:31.751156 bgp_send: sending 21 bytes to 201.201.0.1 (External AS 65010)
Feb 11 12:52:31.751175
Feb 11 12:52:31.751175 BGP SEND 10.0.3.4+3291 -> 201.201.0.1+179
Feb 11 12:52:31.751194 BGP SEND message type 3 (Notification) length 21
Feb 11 12:52:31.751208 BGP SEND Notification code 2 (Open Message Error) subcode 2
(bad peer AS number)
www.juniper.net
5
AL
U
SE
O
N
LY
BGP Troubleshooting
N
EBGP Configuration Specifics
R
Recall that EBGP sessions take TTL value of 1 by default, hence for a loopback-to-loopback peering
session, multihop configuration is mandatory.
TE
Watch for mismatched peer AS configuration.
EBGP Troubleshooting Specifics
IN
EBGP sessions are often harder to troubleshoot because you cannot usually look at the peer router
configuration. Use traceoptions if you cannot find a source of problem by checking your router
configuration. You can also monitor the control traffic using the monitor traffic interface
interface_name command.
6
www.juniper.net
AL
U
SE
O
N
LY
BGP Troubleshooting
N
Route Reflection Specifics
TE
R
IBGP sessions in a network designed with route reflection are the same sessions used in regular full
mesh domain. But note the route reflection specifics: Client routers must peer only with reflectors,
they can optionally peer with each other within the same cluster, and they must be fully meshed
within the same cluster if a reflector is configured with no-client-reflect.
IN
In turn, route reflectors must be fully meshed with each other in addition to peering with clients in
the cluster.
www.juniper.net
Confederation Specifics
Be careful with CBGP sessions configuration. The sessions are EBGP-like sessions but they are
established within a single confederation AS, usually using loopback peering on top of underlying IGP
infrastructure. Watch out for multihop, peer-as and local-address settings. Double check
the confederation configuration in routing-options.
7
AL
U
SE
O
N
LY
BGP Troubleshooting
N
BGP Routing Problems
R
The second category of BGP problems is routing problems. If a BGP session is established
successfully but routers or hosts cannot exchange with traffic, it can be related to either routing
issues or forwarding problems.
TE
Most probably the connectivity problems are related to routing issues. BGP is the protocol by which
routing exchanges are completely controlled by an administrative policy. Hence, check your routing
policies.
IN
Forwarding problems are either related to incorrectly applied firewall filters or physical hardware or
software problems. Note, though, that the exam contains no intentional hardware or software
problems.
8
www.juniper.net
AL
U
SE
O
N
LY
BGP Troubleshooting
N
Route Injection into BGP
TE
R
Recall that BGP does not advertise routes automatically at the originating point. An administrative
policy is required to inject routes into BGP. If you do not see the expected routes in BGP
advertisements, watch for misconfigured policy.
IN
BGP Policy Defaults
www.juniper.net
Remember BGP default policies. The default import policy accepts all routes if BGP can resolve the
received BGP next hop. The default export policy advertised the best and active BGP routes. If the
BGP route is shadowed by a preferred IGP route, it is set inactive and BGP stops advertising it. You
can use the advertise-inactive statement to make BGP advertise the best—but not active—
BGP routes.
Continued on next page.
9
BGP Troubleshooting
Policy Misconfiguration Results
A misconfigured policy can prevent routes from being received or sent. Watch for policy application
points: protocol, group, or neighbor. Recall that the more specific application overrides the less
specific ones. Use show route advertising protocol and show route
receive-protocol commands to verify BGP route exchanges.
lab@R1> show route advertising-protocol bgp 172.27.0.34 172.27/16
lab@R2> show route receive-protocol bgp 172.27.255.3 35/8
LY
inet.0: 918 destinations, 954 routes (913 active, 0 holddown, 6 hidden)
Prefix Nexthop
MED
Lclpref
AS path
* 172.27.0.0/16
Self
I
IN
TE
R
N
AL
U
SE
O
N
inet.0: 917 destinations, 2636 routes (912 active, 0 holddown, 1700 hidden)
Prefix Nexthop
MED
Lclpref
AS path
* 35.0.0.0/8
172.27.0.34
100
1342930876 8918 237 I
10
www.juniper.net
AL
U
SE
O
N
LY
BGP Troubleshooting
N
Hidden Routes
R
BGP marks routes as hidden if it either cannot resolve the received BGP next hop or the routes are
filtered out with an import policy. Use the show route hidden command to check whether you
have any hidden routes.
TE
lab@R1> show route hidden
IN
inet.0: 918 destinations, 997 routes (913 active, 0 holddown, 6 hidden)
+ = Active Route, - = Last Active, * = Both
12.16.126.192/26
65.114.168.192/26
[BGP
AS
> to
[BGP
AS
> to
] 10:17:45, localpref 100
path: 1342930876 8918 10578 14325 ?
172.27.0.34 via ge-0/0/2.0
] 10:17:45, localpref 100
path: 1342930876 8918 10886 7082 I
172.27.0.34 via ge-0/0/2.0
Use the show route resolution unresolved command to check if any routes are hidden
because BGP cannot resolve their next hop.
www.juniper.net
11
N
BGP Next Hop
AL
U
SE
O
N
LY
BGP Troubleshooting
TE
R
Recall that BGP next hop must be reachable in order BGP to accept and process an update. For
regular IP routing both inet.0 and inet.3 tables are consulted for BGP IPv4 next hop reachability
(inet6.0 and inet6.3 tables for BGP IPv6 next hop reachability). Note that in VPN scenarios and
6PE, only the tables populated by MPLS protocols—inet.3 and inet6.3—are used.
Recall that IBGP does not change BGP next hop by default. You must either apply a next-hop-self
policy or use IGP passive interface.
IN
Watch for BGP next-hop-self policy on route reflectors. Make sure that reflectors only change the next
hop on EBGP-learned routes to avoid suboptimal routing.
BGP Next Hop Double Recursion Problem
Note that if BGP next hop is resolved using a route received in the same BGP update as the next hop,
the route is not used and marked as hidden. This situation can lead to race conditions where, to use
the route, the next hop must be resolved, and for the next hop to be resolved, the route must exist in
the routing table.
This situation can arise if the received route is the more specific one that router already has—for
example, if the router is located in the OSPF stub area.
12
www.juniper.net
AL
U
SE
O
N
LY
BGP Troubleshooting
N
Are BGP Routes in the Routing Table?
R
Check if BGP routes are put into the routing table.
lab@R1> show route protocol bgp 35/8 exact
TE
inet.0: 918 destinations, 959 routes (912 active, 0 holddown, 6 hidden)
+ = Active Route, - = Last Active, * = Both
IN
35.0.0.0/8
www.juniper.net
*[BGP/170] 3d 07:36:48, localpref 100
AS path: 1342930876 8918 237 I
> to 172.27.0.34 via ge-0/0/2.0
Continued on next page.
13
BGP Troubleshooting
Are Routes Advertised By a Peer?
To verify that routes are advertised by the BGP peer, use the show route
advertising-protocol bgp command.
lab@R1> show route advertising-protocol bgp 172.27.255.3 35/8
inet.0: 918 destinations, 954 routes (913 active, 0 holddown, 6 hidden)
Prefix Nexthop
MED
Lclpref
AS path
* 35.0.0.0/8
Self
100
1342930876 8918 237 I
Are Routes Being Received?
LY
If you do not see that routes are advertised and you expect them should be double check your export
policy.
To verify that routes are received, use the show route receive-protocol bgp command.
O
N
lab@R3> show route receive-protocol bgp 172.27.255.1 35/8
inet.0: 911 destinations, 1789 routes (910 active, 0 holddown, 1 hidden)
Prefix Nexthop
MED
Lclpref
AS path
* 35.0.0.0/8
172.27.255.1
100
1342930876 8918 237 I
IN
TE
R
N
AL
U
Continued on next page.
SE
If routes are advertised by a peer but are not received at the local router, check for hidden routes. If
a route is found in the list of hidden routes, ensure that the BGP next hop is reachable, otherwise if
the next hop is reachable but the route is hidden, double check your import policy.
14
www.juniper.net
BGP Troubleshooting
Does the Problem Still Exist?
To further troubleshoot the issue, monitor the details of BGP exchanges using traceoptions.
LY
[edit protocols bgp]
lab@R1# show group T1
type external;
traceoptions {
file bgp-trace.log;
flag update detail;
}
import from-T1;
export to-T1;
peer-as 1342930876;
neighbor 172.27.0.34;
IN
TE
R
N
AL
U
SE
O
N
lab@R1> show log bgp-trace.log | last
Aug 1 08:24:45.925733 BGP RECV 172.27.0.34+179 -> 172.27.0.33+53617
Aug 1 08:24:45.925753 BGP RECV message type 2 (Update) length 78
Aug 1 08:24:45.925769 BGP RECV Update PDU length 78
Aug 1 08:24:45.925784 BGP RECV flags 0x40 code Origin(1): IGP
Aug 1 08:24:45.925802 BGP RECV flags 0x40 code ASPath(2) length 6: 1342930876
Aug 1 08:24:45.925817 BGP RECV flags 0x90 code MP_reach(14): AFI/SAFI 2/1
Aug 1 08:24:45.925836 BGP RECV nhop ::172.27.0.34 len 32
Aug 1 08:24:45.925853 BGP RECV ::/0
Aug 1 08:24:45.926028 bgp_nexthop_sanity: peer 172.27.0.34 (External AS 1342930876)
next hop ::172.27.0.34 unexpectedly remote, ignoring routes in this update
Aug 1 08:24:45.926064 bgp_rcv_nlri: ::/0
Aug 1 08:24:45.926095
Aug 1 08:24:45.926095 BGP RECV 172.27.0.34+179 -> 172.27.0.33+53617
Aug 1 08:24:45.926114 BGP RECV message type 2 (Update) length 23
Aug 1 08:24:45.926129 BGP RECV End of RIB: AFI 1 SAFI 1
Aug 1 08:24:45.926162
Aug 1 08:24:45.926162 BGP RECV 172.27.0.34+179 -> 172.27.0.33+53617
Aug 1 08:24:45.926185 BGP RECV message type 2 (Update) length 30
Aug 1 08:24:45.926200 BGP RECV Update PDU length 30
Aug 1 08:24:45.926217 BGP RECV flags 0x90 code MP_unreach(15): AFI/SAFI 2/1
Aug 1 08:24:45.926233 BGP RECV End of RIB: AFI 2 SAFI 1
Aug 1 08:24:45.926271 bgp_read_v4_message: done with 172.27.0.34 (External AS
1342930876) received 2617 octets 40 updates 80 routes
www.juniper.net
15
AL
U
SE
O
N
LY
BGP Troubleshooting
N
Is Routing OK?
R
If the examination shows that routing works properly but connectivity problems still exist, the
problem might be related to the firewall settings.
TE
Is the Packet Path Optimal?
IN
An incorrectly applied policy can influence the path that packets take to a destination. For example,
next-hop-self policy on route reflectors can send the packets first to the route reflector instead of to
the originating IBGP peer directly. Use traceroute to make sure that traffic follows either IGP
shortest path or traffic-engineered MPLS LSP, as required.
16
www.juniper.net
AL
U
SE
O
N
LY
BGP Troubleshooting
N
Important CLI Troubleshooting Commands
R
The slide shows some important operational mode commands useful for BGP troubleshooting. Note
that taking a look at the configuration often simplifies troubleshooting significantly.
TE
Debugging BGP
IN
For complex problems, use traceoptions.
www.juniper.net
17
AL
U
SE
O
N
LY
BGP Troubleshooting
N
The Best Way to Save Time
R
Try to avoid self-induced errors while configuring BGP tasks. You can run out of time troubleshooting
multiple problems.
TE
Follow Logical Steps
If you must troubleshoot, follow the logical steps and be consistent.
IN
If You Get Stuck
If you are caught off-guard by an unfamiliar topic, do not let it absorb too much time. Move on, then
perhaps you can return to the task later to complete it.
18
www.juniper.net