Solved: SD-WAN hub and spoke - default route to "spoke"

Martin Kyrc · ‎05-21-2019

Hello,

I'm fighting with SD-WAN control-connection policies. I can change full-mesh to hub-and-spoke, but spokes have no default route (no route to other spokes/branches over hub/HQ).

My simple topology:

- two vEdges in HQ (my spoke)

- (in this scenario) two vEdges as Branches (my Hubs)

- transport: mpls and internet

- service: VPN10 and VPN20

- HQ and Branches have full-mesh connection with all transports

common config (lists):

 lists
  vpn-list VPN10
   vpn 10
  !
  vpn-list VPN20
   vpn 20
  !
  tloc-list TLOC-HQ-INET
   tloc 10.238.162.224 color public-internet encap ipsec
   tloc 10.238.162.225 color public-internet encap ipsec
  !
  tloc-list TLOC-HQ-MPLS
   tloc 10.238.162.224 color mpls encap ipsec
   tloc 10.238.162.225 color mpls encap ipsec
  !
  tloc-list TLOC-HQ-INET-MPLS
   tloc 10.238.162.224 color public-internet encap ipsec
   tloc 10.238.162.225 color public-internet encap ipsec
   tloc 10.238.162.224 color mpls encap ipsec
   tloc 10.238.162.225 color mpls encap ipsec
  !
  site-list ALL
   site-id 1-20
  !
  site-list HQ
   site-id 1
  !
  site-list Branch_B
   site-id 4
   site-id 7
  !

scenario1: VPN10 hub-and-spoke, VPN20 full-mesh

seq10: for VPN10 use only HQ INET and MPLS TLOCs
seq11: for VPN20 to HQ transport use only INET
seq12: for VPN20 to other Branches use for transport INET only
seq21: without allowing tloc, is OMP disabled in whole sd-wan topology (because default action is reject)
in other word:
- VPN10: hub-and-spoke using inet or mpls
- VPN20: full-mesh using inet only

policy
 control-policy scenario1
  sequence 10
   match route
    site-list HQ
    vpn-list VPN10
   !
   action accept
    set
     tloc-list TLOC-HQ-INET-MPLS
    !
   !
  !
  sequence 11
   match route
    site-list HQ
    vpn-list VPN20
   !
   action accept
    set
     tloc-list TLOC-HQ-INET
    !
   !
  !
  sequence 12
   match route
    site-list Branch_B
    vpn-list VPN20
   !
   action accept
    set
     tloc-list TLOC-HQ-INET
    !
   !
  !
  sequence 21
   match tloc
    site-list ALL
   !
   action accept
   !
  !
  default-action reject
 !
!
apply-policy
 site-list Branch_B
  control-policy scenario1 out
 !
!

scenario2: VPN10 hub-and-spoke (without change), VPN20 hub-and-spoke (change)

seq10: for VPN10 use only HQ INET and MPLS TLOCs
seq11: for VPN20 to HQ transport use only INET
seq21: without allowing tloc, is OMP disabled in whol sd-wan topology (because default action is reject)
in other word:
- VPN10: hub-and-spoke using inet or mpls
- VPN20: hub-and-spoke using inet only

policy
 control-policy scenario2
  sequence 10
   match route
    site-list HQ
    vpn-list VPN10
   !
   action accept
    set
     tloc-list TLOC-HQ-INET-MPLS
    !
   !
  !
  sequence 11
   match route
    site-list HQ
    vpn-list VPN20
   !
   action accept
    set
     tloc-list TLOC-HQ-INET
    !
   !
  !
  sequence 21
   match tloc
    site-list ALL
   !
   action accept
   !
  !
  default-action reject
 !
!
apply-policy
 site-list Branch_B
  control-policy scenario2 out
 !
!

issue for VPN20 in this scenario #2:

HQ has route to both Branches (4 and 7)
Br4: has route to HQ (and local networks)
Br7: has route to HQ (and local networks)
issue: no default route to "HQ" from branches

VPN10 is ok, because:

VPN10 has default route to HQ, because default route exists on HQ and is redistributed using OSPF to branches
I'm not sure why, because no "default route" is configured on HQ vEdges

routing config on HQ (VPN10 and VPN20):

VPN20 has only loopback "networks" /32
VPN10 has also "/24" network between vEdge11 and vEdge12 located in HQ (ge0/3)

vEdge11# sh run vpn 10
vpn 10
 router
  ospf
   default-information originate always
   timers spf 200 1000 10000
   redistribute omp
   area 0
    interface ge0/3
    exit
    interface loopback10
    exit
   exit
  !
 !
 interface ge0/3
  description corplan_net
  ip address 10.101.11.2/24
  no shutdown
 !
 interface loopback10
  description corpwifi_net
  ip address 10.101.10.2/32
  no shutdown
 !
 omp
  advertise ospf external
 !
!
vEdge11# sh run vpn 20
vpn 20
 router
  ospf
   default-information originate always
   timers spf 200 1000 10000
   redistribute omp
   area 0
    interface loopback20
    exit
   exit
  !
 !
 interface loopback20
  description ipt_net
  ip address 10.101.20.2/32
  no shutdown
 !
 omp
  advertise ospf external
 !
!

QUESTION #1

is it possible using control-policy inject "default route" to "spokes"?
if not, how can I in this simple scenario inject default route for VPN20 from "hub" to routing protocol (OSPF) in location "HQ"? all networks in HQ are "loopback /32 interfaces". I think correct config is change spokes to e.g. "nssa"

QUESTION #2

is this "hub-and-spoke" topology configuration based with control-policy correct?
I found lot of "topology designs" but every is a bit different and I'm not sure which one is "design recommended"

tzarski · ‎05-23-2019

Yes, indeed. If you don't have any LAN on hubs for VPN20 then only way to originate default route is via static default route. You don't see such design very often as normally hubs are used to route to legacy or local networks/DC via service VPN BGP.

Another way to solve your routing problem would be to originate a summary route instead of default route. You could use "vpn 20 omp advertise aggregate 10.0.0.0/8 [aggregate-only]" on the hub routers.

View solution in original post

tzarski · ‎05-23-2019

Hi Martin,

Control policy is used for route manipulation and cannot originate any route. There are several ways you could use to originate default route from hub to spokes (like redistribute default route received from hub LAN side or originate static default route on hub and redistribute it into OMP). Do you have a simple diagram with system-ip's and site-id's which are used in your test policy?

Martin Kyrc · ‎05-23-2019

Thanks for reply,

below are my site diagrams for VPN20:

Site #1 (HQ)

                Lo20                            Lo20
                10.101.20.2/32        10.101.20.3/32
                +--------------+   +--------------+
                |VE11          |   |VE12          |
                |10.238.162.224|   |10.238.162.225|
                +-+--------+---+   +-+----+-------+
                  |        |         |    |
    MPLS          |        |         |    |
    --------------+------------------+    |
                           |              |     Inet
                        ---+--------------+-----------

Branches:

- have connectivity to MPLS and Inet

Site #4

+--------------+
|VE41          |
|10.238.162.228|
+--------------+
Lo20
10.104.20.1/32

Site #7

+--------------+
|VE71          |
|10.238.162.231|
+--------------+
Lo20
10.107.20.1/32

"Control policy is used for route manipulation and cannot originate any route" - thanks, now it's clear for me.

My issue:

In my scenario no "default route" exists on the hub and that's the issue. In other words I have only two possibilities:

#1 create/originate default GW on the hub (e.g. static) and redistribute it to omp

#2 redistribute default gw received from LAN (in my case not possible) and redistribute it into omp

Last words... for VPN10 is situation a bit different (for hub-and-spoke topology). I have small LAN between VE11 and VE12 (10.101.11.0/24) for VPN10 and there "exists" default route redistributed into omp.

vEdge11# sh ip route vpn 10 | i ge0/3
10     0.0.0.0/0           ospf             E2        ge0/3       10.101.11.3      -        -                -                -      F,S
10     10.101.10.3/32      ospf             IA        ge0/3       10.101.11.3      -        -                -                -      F,S
10     10.101.11.0/24      ospf             IA        ge0/3       -                -        -                -                -      -
10     10.101.11.0/24      connected        -         ge0/3       -                -        -                -                -      F,S

vEdge12# sh ip route vpn 10 | i ge0/3
10     10.101.10.2/32      ospf             IA        ge0/3       10.101.11.2      -        -                -                -      F,S
10     10.101.11.0/24      ospf             IA        ge0/3       -                -        -                -                -      -
10     10.101.11.0/24      connected        -         ge0/3       -                -        -                -                -      F,S

On the branches exists routing to "hub" (for VPN10):

vEdge71# sh ip route vpn 10 | i 0.0.0.0
10     0.0.0.0/0           omp              -         -           -                -        10.238.162.224   mpls             ipsec  F,S
10     0.0.0.0/0           omp              -         -           -                -        10.238.162.224   public-internet  ipsec  F,S
10     0.0.0.0/0           omp              -         -           -                -        10.238.162.225   mpls             ipsec  F,S
10     0.0.0.0/0           omp              -         -           -                -        10.238.162.225   public-internet  ipsec  F,S

Martin

tzarski · ‎05-23-2019

Yes, indeed. If you don't have any LAN on hubs for VPN20 then only way to originate default route is via static default route. You don't see such design very often as normally hubs are used to route to legacy or local networks/DC via service VPN BGP.

Another way to solve your routing problem would be to originate a summary route instead of default route. You could use "vpn 20 omp advertise aggregate 10.0.0.0/8 [aggregate-only]" on the hub routers.

Martin Kyrc · ‎05-23-2019

Thanks a lot. I forgot "omp advertise aggregate". This is an solution in my case (except redistribution of default gw).

martin

apfeil · ‎06-16-2023

For advertising an aggregate to the spokes, would that configuration be completed on the hubs vpn configuration for omp or would that be placed on the spokes?

tzarski · ‎06-19-2023

You would need to configure that aggregate on the hub routers.