Dealing with Backdoor Links on VOS Devices

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 exact
Routes 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 ago
Now, 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: 1
The 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 ago
We 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 ms
As 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.  

Powered by BetterDocs