Dealing With Backdoor Links on VOS Devices
By Radu Pavaloiu and Dinesh Kumar
Dealing With Backdoor Links on VOS Devices
The purpose of this article is to show how to configure VOS devices to send customer traffic using the SD-WAN network in the case of a backdoor connectivity between the customer’s sites. Running the OSPF protocol between SD-WAN VOS appliances and the customer’s routers presents a special interest, as OSPF prioritizes intra-area routes over inter-area and external routes for the same prefix. The VOS used in the testbed is 21.2.2 release.Figure 1 shows the topology used in this article.
Figure 1. OSPF between PE (VOS) devices and customer’s routers
For now, let’s just ignore the sham link in the above picture. To propagate the customer routes from site to site, OSPF is redistributed into MP-iBGP and vice versa on the VOS appliances. The downside of this is that all OSPF routes become external routes on the remote VOS appliance when the routes are redistributed back into OSPF. As a result, all OSPF routes that traverse the SD-WAN network would be less preferable than the routes that do not traverse the SD-WAN but are sent via an intersite link (backdoor link) from one OSPF site to another. R5 will prefer the intra-area (backdoor link) LSA vs the external LSA, and will build the routing table accordingly: admin@R5-cli> show route routing-instance Service-VNF-VR 192.168.14.0/24 exactRoutes for Routing instance : Service-VNF-VR AFI: ipv4 SAFI: unicast [+] - Active Route Routing entry for 192.168.14.0 (mask 255.255.255.0) [+] Known via 'OSPF', distance 30, metric 11, type iA, forward metric 11 Redistributing via OSPF Last update from 192.168.45.1 12m9s ago Routing Descriptor Blocks: * 192.168.45.1 , via vni-0/1.0 12m9s agoNow, checking on R5 the “router” LSA (type 1) advertised by R4:
admin@R5-cli> show ospf database router adv-router 44.44.44.44 detail OSPF Router with ID (55.55.55.55) Instance ID (3037) Area 0.0.0.0; LSA type: router; LSA ID ADV Router Sequence Age (secs) Checksum ------ ---------- -------- --------- -------- 44.44.44.44 44.44.44.44 0x80000008 111 0x00005587 Age: 111 secs; Sequence number: 0x80000008; Checksum: 0x00005587 Bits: E, B Links: 3 Router links: 1. Link ID: 192.168.45.6; Link data: 192.168.45.6; Type: Transit Num. of TOS: 0; metric: 1 2. Link ID: 192.168.45.2; Link data: 192.168.45.1; Type: Transit Num. of TOS: 0; metric: 10 3. Link ID: 192.168.14.0; Link data: 255.255.255.0; Type: Stub Num. of TOS: 0; metric: 1The same is equally true from R4 perspective:
admin@R4-cli> show route routing-instance Service-VNF-VR 192.168.15.0/24 exact Routes for Routing instance : Service-VNF-VR AFI: ipv4 SAFI: unicast [+] - Active Route Routing entry for 192.168.15.0 (mask 255.255.255.0) [+] Known via 'OSPF', distance 30, metric 11, type iA, forward metric 11 Redistributing via OSPF Last update from 192.168.45.2 14m14s ago Routing Descriptor Blocks: * 192.168.45.2 , via vni-0/1.0 14m14s agoWe start to send traffic between the sites:
gns3@Host1C2:~$ ip a s ens4 3: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 0c:86:9d:19:02:01 brd ff:ff:ff:ff:ff:ff inet 192.168.14.2/24 brd 192.168.14.255 scope global noprefixroute ens4 valid_lft forever preferred_lft forever inet6 fe80::95ad:3c3f:4ddd:ab5/64 scope link noprefixroute valid_lft forever preferred_lft forever gns3@Host1C2:~$ ping 192.168.15.2 -c 1 PING 192.168.15.2 (192.168.15.2) 56(84) bytes of data. 64 bytes from 192.168.15.2: icmp_seq=1 ttl=62 time=1.45 ms --- 192.168.15.2 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.452/1.452/1.452/0.000 msAs the traffic is not going over the SD-WAN network, but on the backdoor link there is no “icmp” session observed on the SD-WAN appliances:
admin@Branch-4-cli> show orgs org Customer2 sessions brief VSN VSN SESS DESTINATION SOURCE DESTINATION ID VID ID SOURCE IP IP PORT PORT PROTOCOL NATTED SDWAN APPLICATION --------------------------------------------------------------------------------------------------- 0 2 1 11.0.0.10 11.0.0.0 1154 1234 6 No No -The solution for this scenario is to emulate an OSPF intra-area link between the SD-WAN appliances over the SD-WAN network which results in prefixes being advertised as iA instead of E2 between the two respective sites. Basically, this is similar with the OSPF shamlink feature coming from the MPLS L3VPN world. shamlink feature is supported in the VOS. Now, let’s move to the configuration side. The first step is to create 2 tvi on the branches (4.4.4.4 on Branch-4 and 5.5.5.5 on Branch-5) and add those to the LAN-VR and Orgs-Limit. These tvi addresses must be advertised in MP-BGP between the sites and as a result there will be reachability between them. Only Branch-4 is being shown but same operation will have to be performed on the remote Branch. These tvi will be used as support to build the shamlink between the sites.
Figure2. tvi interface configuration
Figure3. tvi added to the LAN-VR interfaces
Figure 4. tvi added to the Organization Limits
Figure 9. tvi ips added to the OSPF process
Now, the communication between the sites should be possible and treated equally (OSPF iA routes) over both the backdoor link and the SD-WAN shamlink. However, for preferring one of them the OSPF cost of it should be lesser than the other one. For this reason, the OPSF backdoor links cost is increased artificially to be higher than the virtual link one.
Figure 10. R4 backdoor link cost change
Let’s move now to the verification task. All the verification will be done only on the Site-4/Branch-4 side. A similar process could be performed on the other site. As it can be seen on the bellow excerpt Branch-4 has two OSPF neighbors: one to the local LAN router and the second one with Branch-5 over the shamlink.
admin@Branch-4-cli> show ospf neighbor brief
State codes: atmpt - attempt, exchg - exchange, exst - exchange start,
load - loading, 2-way - two-way, full - full
Op codes: gdown - going down, gup - going up
Intf address Interface State Neighbor ID Pri Op
------------ --------- ----a- ----------- --- --
192.168.45.5 vni-0/2.0 full 44.44.44.44 1 up
[ok][2023-05-29 03:25:28]
admin@Branch-4-cli>
admin@Branch-4-cli> show ospf sham-links brief
LOCAL REMOTE
OSPF END END OPERATIONAL LINK
INDEX AREA ID POINT POINT STATUS STATE ID METRIC
------------------------------------------------------------------------------
75000 0.0.0.0 4.4.4.4 5.5.5.5 Up Point-to-Point 75000 5
[ok][2023-05-29 03:26:11]
admin@Branch-4-cli>
Now we’ll check the route 192.168.15/24 from Site-4 perspective. – R4 is pointing to Branch-4 SD-WAN appliance:
admin@R4-cli> show route routing-instance Service-VNF-VR 192.168.15.0/24 exact Routes for Routing instance : Service-VNF-VR AFI: ipv4 SAFI: unicast [+] - Active Route Routing entry for 192.168.15.0 (mask 255.255.255.0) [+] Known via 'OSPF', distance 30, metric 4, type iA, forward metric 4 Redistributing via OSPF Last update from 192.168.45.5 40m43s ago Routing Descriptor Blocks: * 192.168.45.5 , via vni-0/0.0 40m43s ago – Branch-4 is pointing to Branch-5 over the shamlink: admin@Branch-4-cli> show route routing-instance Customer2-LAN-VR 192.168.15.0/24 exact Routes for Routing instance : Customer2-LAN-VR AFI: ipv4 SAFI: unicast [+] - Active Route Routing entry for 192.168.15.0 (mask 255.255.255.0) [+] Known via 'BGP', Preference(admin distance 200, Redistributing via BGP )Last update from 10.0.0.36 2d21h28m16s ago Routing Descriptor Blocks: * 10.0.0.36 , via Indirect(Branch-5) 2d21h28m16s ago [ok][2023-05-29 03:44:25] admin@Branch-4-cli>– and finally Branch-5 is pointing to R5:
admin@Branch-5-cli> show route routing-instance Customer2-LAN-VR 192.168.15.0/24 exact Routes for Routing instance : Customer2-LAN-VR AFI: ipv4 SAFI: unicast [+] - Active Route Routing entry for 192.168.15.0 (mask 255.255.255.0) [+] Known via 'OSPF', Preference(admin distance 30, metric 2, type iA, forward metric 2, scalable group tag 32572, Redistributing via OSPF )Last update from 192.168.45.9 5d4h29m18s ago Routing Descriptor Blocks: * 192.168.45.9 , via vni-0/2.0() 5d4h29m18s ago [ok][2023-05-29 03:45:33] admin@Branch-5-cli>We’ll start again the ICMP test, probing if the traffic is now going over SD-WAN network. – Branch-4 appliance
admin@Branch-4-cli> show orgs org Customer2 sessions brief VSN VSN SESS DESTINATION SOURCE DESTINATION ID VID ID SOURCE IP IP PORT PORT PROTOCOL NATTED SDWAN APPLICATION --------------------------------------------------------------------------------------------------------- 0 2 1 11.0.0.10 11.0.0.0 1154 1234 6 No No - 0 2 2 192.168.14.2 192.168.15.2 2346 2346 1 No No icmp/(predef)– Branch-5 appliance
admin@Branch-5-cli> show orgs org Customer2 sessions brief VSN VSN SESS DESTINATION SOURCE DESTINATION ID VID ID SOURCE IP IP PORT PORT PROTOCOL NATTED SDWAN APPLICATION --------------------------------------------------------------------------------------------------------- 0 2 1 11.0.0.12 11.0.0.0 1025 1234 6 No No - 0 2 2 192.168.14.2 192.168.15.2 2346 2346 1 No No icmp/(predef)The above is a clear indication that traffic is flowing over the SD-WAN network. The backdoor link will be used only in case if all SD-WAN paths will fail.
