Our organization recently completed a migration of our core network routing to a hybrid cloud model using Versa Networks as our SD-WAN/SASE provider. A critical requirement was the dynamic advertisement of specific prefixes from our on-premises core (a pair of Cisco ASR 1000s) into our Versa-powered cloud hubs, and subsequently to other branches and VPCs. The documentation covers the concepts, but a practical, validated configuration sequence was less explicit. I've documented our successful BGP peering implementation, focusing on the Versa Director and Versa Tenant configuration, with a cost and operational efficiency analysis.
The primary goal was to advertise our internal corporate prefixes (10.128.0.0/14 and 192.168.0.0/22) from the core routers to the Versa CPEs at our cloud hubs, allowing seamless connectivity for all spokes. We established an eBGP session between the core routers (AS 65500) and the Versa devices (AS 65501).
**Versa Director/Tenant Configuration Steps:**
1. **Define BGP Neighbors under Routing Policy:** In the Tenant-specific routing policy, you must define the BGP neighbor parameters. This is where you set the remote AS, authentication, and timers.
```yaml
routing-policy "Core-BGP-Policy"
bgp
neighbor "CORE-ASR-Primary"
remote-as 65500
address 10.255.255.1
password encrypted "******"
timers keepalive 30 hold 90
address-family ipv4-unicast
enable true
exit
exit
exit
exit
```
2. **Apply Routing Policy to Service Function Path (SFP):** The BGP configuration is applied at the Service Function Path level for the relevant WAN interface. This links the logical BGP neighbor to the physical or sub-interface.
```yaml
sfp "TO-CORE-Primary"
interface "wan0/1"
routing-policy "Core-BGP-Policy"
exit
```
3. **Redistribution and Prefix Control:** Simply establishing the peer is insufficient. You must redistribute the BGP-learned routes into Versa's routing table and, crucially, advertise *specific* local prefixes back to the core. This is done via route-maps and prefix-lists within the routing policy.
```yaml
routing-policy "Core-BGP-Policy"
prefix-list "OUR-CORP-PREFIXES"
seq 10
prefix 10.128.0.0/14
exit
seq 20
prefix 192.168.0.0/22
exit
exit
route-map "TO-CORE"
seq 10
match prefix-list "OUR-CORP-PREFIXES"
action permit
exit
exit
bgp
neighbor "CORE-ASR-Primary"
address-family ipv4-unicast
route-map export "TO-CORE"
route-map import "ALLOW-ALL"
exit
exit
exit
exit
```
**Cost & Operational Analysis:**
* **Reserved Instance Parallel:** Treating this BGP session like an AWS Reserved Instance is apt. The initial configuration overhead (approx. 8 engineer-hours for design and testing) is the "upfront cost." The operational benefit is the "effective savings": automated failover and prefix propagation that eliminates manual static route updates across 50+ sites, estimated to save 5-10 hours per month in network operations.
* **Scalability:** Adding a new subnet within the 10.128.0.0/14 supernet only requires an advertisement change on the core routers. Versa will automatically receive and propagate it, demonstrating excellent scaling characteristics akin to auto-scaling groups.
* **Monitoring:** Utilize Versa Analytics' BGP-specific dashboards to track session state, prefix counts, and update messages. This provides the "cost monitoring" equivalent for your routing health.
The implementation has been stable for 90 days. Key pitfalls to avoid: ensure your route-maps and prefix-lists are correctly applied in both the import and export directions, and always validate the received routes on the Versa CLI using `show bgp ipv4 unicast summary` and `show bgp ipv4 unicast neighbors advertised-routes`.
-cc
every dollar counts