8. Verification of the routing configuration
The configurations are completed, it is time to verify the configurations are done correctly or not.
8.1 Verify the effective route on Azure VNets
Let’s check the effective route on Azure VNets SG-VNET1 and SG-VNET2, this will help to confirm can the SG-VNET1 and SG-VNET2 learnt the Spoke1 site LAN subnet 10.11.1.0/24. To do this, go to virtual machine, VNet1-Linux1, select Networking, and then click on the Network Interface, which is called vnet1-linux1589 in this example. Once arrived at the network interface, click “Effective routes” on the left side menu:
The third row is the route of 10.11.1.0/24, with source “Virtual network gateway” and next hop 10.209.0.10. Actually, 10.209.0.10 is the GE2 IP address of the SD-WAN Edge Azure-SG-Edge1. This confirms the SG-VNET1 route table is able to learnt the Spoke1 site LAN prefix 10.11.1.0/24 successfully (from the VNet peering and Route Server).
The same procedure needs to be done at SG-VNET2 virtual machine VNet2-Linux1:
Again, the third row is 10.11.1.0/24 which is the Spoke1 site LAN prefix. The above confirmed, in both VNet, they can learn the 10.11.1.0/24 from the Route Server SG-Transit-RouteServer through the VNet peering. The next hop of 10.209.0.10 shows the Route Server will not change the next hop when advertise the routes, the next hop is maintained as 10.209.0.10 which is the Azure-SG-Edge1 GE2 IP address.
8.2 Verify the BGP status at Azure-SG-Edge1 and Azure-SG-Edge2
Let’s check the BGP status of Azure-SG-Edge1:
From the “Show BGP Summary” output, Azure-SG-Edge1 established eBGP peer with 10.209.1.4 and 10.209.1.5 (they are the IP address of the Route Server) successfully. The “Show BGP Table” output confirms Azure-SG-Edge1 is able to learnt routes 10.210.0.0/17 (SG-VNET1 address space) and 10.210.128.0/17 (SG-VNET2 address space).
Let’s take a look at Azure-SG-Edge2:
Azure-SG-Edge2 also forms two eBGP peers with 10.209.1.4 and 10.209.1.5. It also learns 10.210.0.0/17 and 10.210.128.0/17 from the Route Server, the difference is the AS Path gets two additional AS number 65123. This confirms the AS number prepend is working at Azure-SG-Edge2.
Next, take a look at the route table of the Spoke1 site, that is SD-WAN Edge RT-Spoke1:
Pay attention to the two routes 10.210.0.0/17 and 10.210.128.0/17. Both routes are learnt from both Azure-SG-Edge1 and Azure-SG-Edge2. The route on top is with next hop Azure-SG-Edge1 (when multiple same prefix routes appear in the route table, the one on top is the one being used), this is because the AS Path information is carried over. As a result, RT-Spoke1 will prefer Azure-SG-Edge1 as next hop instead of Azure-SG-Edge2, it is because the AS Path is shorter when the route is learnt from Azure-SG-Edge1.