Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
3076
Views
1
Helpful
6
Replies

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

Go to solution
Martin Kyrc
Level 3
Level 3

‎05-21-2019 04:36 AM

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"

 

 

 

 

Labels:
0 Helpful
1 Accepted Solution

Accepted Solutions

Go to solution
tzarski
Cisco Employee
Cisco Employee
In response to Martin Kyrc

‎05-23-2019 04:29 AM

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

0 Helpful
6 Replies 6

Go to solution
tzarski
Cisco Employee
Cisco Employee

‎05-23-2019 02:05 AM - edited ‎05-23-2019 02:07 AM

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?

0 Helpful

Go to solution
Martin Kyrc
Level 3
Level 3
In response to tzarski

‎05-23-2019 03:26 AM

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

 

0 Helpful

Go to solution
tzarski
Cisco Employee
Cisco Employee
In response to Martin Kyrc

‎05-23-2019 04:29 AM

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.

0 Helpful

Go to solution
Martin Kyrc
Level 3
Level 3
In response to tzarski

‎05-23-2019 05:31 AM

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

 

martin

Go to solution
apfeil
Level 1
Level 1

‎06-16-2023 09:56 AM

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?

0 Helpful

Go to solution
tzarski
Cisco Employee
Cisco Employee
In response to apfeil

‎06-19-2023 02:28 AM

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

0 Helpful
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Customers Also Viewed These Support Documents