BGP troubleshooting is most effective when the engineer separates the protocol into stages: transport reachability, neighbor session establishment, received and advertised prefixes, policy, best-path selection, and installation in the routing table. Jumping directly to route-map edits before identifying the failed stage creates more problems than it solves.<\/p>\n
Within network security platforms<\/a>, FortiGate combines dynamic routing with firewall policy, IPsec, SD-WAN, and security inspection. That integration is powerful, but it also means a routing symptom can originate outside BGP itself.<\/p>\n The operational objective is to prove where the prefix disappears and why, using the control plane and forwarding plane as separate sources of evidence.<\/p>\n A BGP session depends on IP reachability to the neighbor address. Verify interface state, addressing, routing to the peer, source interface or update source, and any intermediate policy before interpreting BGP state.<\/p>\n If the neighbor uses a loopback or multihop relationship, confirm that the recursive route to that address is stable. A session that flaps because the route to the peer itself changes can look like a protocol problem.<\/p>\n Routing diagnostics<\/a> should begin below the routing protocol whenever basic reachability is uncertain.<\/p>\n Established means the BGP finite-state machine completed and the peers can exchange updates. States such as Active or Connect indicate that the session has not reached that point, and repeated transitions suggest transport, configuration, authentication, or reachability issues.<\/p>\n Compare local and remote AS numbers, neighbor addresses, password settings, address families, and timers. Do not assume the remote configuration matches because the local configuration looks correct.<\/p>\n BGP policy<\/a> becomes relevant only after the neighbor relationship is healthy enough to exchange routes.<\/p>\n A missing route can be absent because the neighbor never advertised it or because the FortiGate rejected it. Inspect received routes and policy behavior before changing local preference or administrative distance.<\/p>\n Inbound route maps, prefix lists, community matches, maximum-prefix controls, and address-family settings can filter a route before it reaches the local BGP table.<\/p>\n BGP communities<\/a> are especially useful to inspect when route acceptance depends on upstream tagging.<\/p>\n A prefix can exist in the BGP table but still not be installed in the main routing table because another route has a better administrative distance, recursive next-hop resolution fails, or the selected BGP path is not usable.<\/p>\n Check the BGP best path and then verify the FortiGate routing table. The two views answer different questions: BGP decides its preferred path; the routing table decides which protocol contribution is installed for forwarding.<\/p>\n Routing tables<\/a> are the point where protocol intent becomes system-wide forwarding preference.<\/p>\n If the local route exists but the remote peer does not learn it, confirm that the prefix is eligible for origination and that outbound policy permits it. Network statements, redistribution, aggregation, route maps, prefix lists, and community policy can all affect advertisement.<\/p>\n Route redistribution deserves special caution because a prefix can cross protocol boundaries and return with changed attributes. Tagging and direction-specific filters help prevent feedback loops.<\/p>\n Route redistribution<\/a> should be documented as a deliberate boundary, not scattered across routers.<\/p>\n Fortinet documents route flap as a common BGP troubleshooting condition. A flapping route may originate from a failing interface, unstable tunnel, peer process restart, recursive next-hop change, or policy that repeatedly withdraws and reinstalls reachability.<\/p>\n Correlate BGP events with interface logs, VPN state, SD-WAN health, and device resource conditions. Clearing BGP can refresh state, but repeated resets should not replace root-cause analysis.<\/p>\n FortiGate HA<\/a> can add another timing dimension when sessions restart or routes converge during failover.<\/p>\n A valid route does not guarantee that traffic will pass. Firewall policy, NAT, local-in policy, session state, IPsec selectors, and asymmetric return paths can all break connectivity after BGP has done its job.<\/p>\n Use packet flow diagnostics and session inspection to see what FortiGate does with the actual traffic. This prevents the routing team from changing a healthy protocol to solve a firewall problem.<\/p>\n Session troubleshooting<\/a> is the natural next step once routing has been proven.<\/p>\n When BGP routes and SD-WAN coexist, the route determines which destinations are reachable while SD-WAN rules can influence which eligible member carries application traffic. Health checks can remove a path from steering even when BGP remains established.<\/p>\n Troubleshooting should record both the routing table and the SD-WAN rule decision for the affected flow. Otherwise operators can misinterpret a healthy BGP path that is intentionally excluded by an SLA rule.<\/p>\nConfirm transport before BGP<\/h3>\n
Read the neighbor state precisely<\/h3>\n
Prove whether the prefix was received<\/h3>\n
Separate the BGP table from the routing table<\/h3>\n
Inspect outbound advertisement separately<\/h3>\n
Treat flapping as a system symptom<\/h3>\n
Check policy and forwarding after route installation<\/h3>\n
Include SD-WAN in the path decision<\/h3>\n