Task 2 - Verify Routing
| Goal | Verify overlay routing |
| Task | Log into Fortigates and check BGP routing |
| Verify task completion | You should see full exchange of routing information |
Check BGP Routing
Check FortiGate routing.
- Useful CLI Commands
get router info routing-table bgp get router info routing-table all get router info bgp summary get router info bgp neighbors <neighbor IP> received-routes get router info bgp neighbors <neighbor IP> advertised-routes get router info routing-table details <prefix>- As we can see below, we are installing the routes from the remote FortiGates. We see 10.15.0.0/24 will traverse tunnel FGT-1 (us-central1) and 10.16.0.0/24 will traverse tunnel FGT-2 (us-east1). This is the ideal scenario since traffic will be forwarded to the FortiGate directly in the region where the subnets are configured. This eliminates inter-regional routing on GCP’s network, during normal operation, saving the customer network costs.
rmt-fgt # get router info routing-table bgp Routing table for VRF=0 B 10.15.0.0/24 [200/100] via 10.17.1.2 (recursive via FGT-1 tunnel 35.225.97.223), 00:24:28, [1/0] B 10.16.0.0/24 [200/100] via 10.17.2.2 (recursive via FGT-2 tunnel 34.74.104.177), 00:23:28, [1/0]- Let’s verify that we are receiving both routes from both peers. This is important, because in the event that one of the remote FortiGates goes down, the resources in GCP will still be reachable.
rmt-fgt # get router info bgp neighbors 10.17.1.2 received-routes VRF 0 BGP table version is 2, local router ID is 192.168.101.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight RouteTag Path *>i10.15.0.0/24 10.17.1.2 100 100 0 0 65100 ? <-/-> *>i10.16.0.0/24 10.17.1.2 333 100 0 0 65100 ? <-/-> Total number of prefixes 2 rmt-fgt # get router info bgp neighbors 10.17.2.2 received-routes VRF 0 BGP table version is 2, local router ID is 192.168.101.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight RouteTag Path *>i10.15.0.0/24 10.17.2.2 333 100 0 0 65100 ? <-/-> *>i10.16.0.0/24 10.17.2.2 100 100 0 0 65100 ? <-/-> Total number of prefixes 2- As we can see from the above output, we are getting both routes from both peers. We are preferring the route with the lower metric as expected.
Check BGP Routing in NCC by navigating to Network Connectivity Center > select your hub name > ROUTES
Info
You will not see any routes until you select a Region from the dropdown menu.
- Let’s check us-central1 (Iowa) region first.
We can see the route learned from the local FortiGate (fgt1) has a lower numerical priority. According to this link, route priority is treated like MED, meaning that the lowest numerical value is preferred.
Let’s check us-east1 (South Carolina) region next.
- In this case, the lower numerical priority value is assigned to the route learned from the local FortiGate (fgt2).
Info
In our environment, we are using SNAT in the FortiGate Policy, meaning that traffic will always return to the FortiGate from which it was recieved. However, in some situations, that is not desirable. As we have seen, the route priorities causing the local FortiGate to be preferred should prevent asymmetrical routing when both devices are up.
Discussion
In this task, we verified the end-to-end routing of our overlay network. We inspected the BGP routing tables on both the remote FortiGate and within the GCP Network Connectivity Center. This confirmed that:
- The remote FortiGate learned routes to both GCP regions (
us-central1andus-east1) from both GCP FortiGates. - The remote FortiGate correctly chose the most efficient path (lowest metric) for each destination.
- The GCP NCC Hub also learned the route to our on-premises network (
192.168.100.0/24) from both FortiGate spokes, preferring the path through the local FortiGate in each region to prevent unnecessary inter-regional traffic.
This confirms our overlay is not only working but is also configured for optimal, cost-effective routing.
Chapter Summary
This chapter was focused on building and verifying the secure overlay network.
- Task 1: FortiGate BGP over IPsec: We established secure IPsec tunnels between the remote FortiGate and the two regional GCP FortiGates. Over these tunnels, we configured iBGP sessions, allowing the devices to dynamically advertise and learn routes from each other.
- Task 2: Verify Routing: We then thoroughly validated our configuration by examining the routing tables. We confirmed that all FortiGates had learned the necessary routes, that redundant paths were available for failover, and that traffic was intelligently routed over the most efficient path during normal operations.
With the overlay built and verified, our hybrid network is now fully connected and secured.