Over the top (OTT) - wireless client subnet advertisement

[dr_wpg]

Hi - I'm currently planning to deploy an SDA fabric and want to integrate my wireless infra through an OTT deployment. 

Currently reviewing BRKEWN-2020 and it makes mention that the border advertises Wireless client subnets to the fabric. 

What does this actually entail? Will this import these subnet routes as map-cache entries to invoke a LISP lookup? Does this mean I will need to select the checkbox to import known routes (anywhere/internal border) or can I configure external borders during Layer 3 handoff workflow? 

[jalejand]

That step is only optional, very optional.

If you want fabric users (wired or FEW-enabled) to reach the OTT clients, they will need to go outside the fabric to reach them (going to the controller itself), meaning the traffic will pass through the border in their respective VRFs, for that reason the border needs a route out to the OTT subnet (which could be easily replaced with a default route)

You can still inject the OTT subnet into LISP as you mention, creating borders with the internal capability (import known routes)  if you want the exit point to be a particular border in case you have more than 1, however, if your deployment consists in 1 border with external capability (default for all routes) or borders which are supposed to be mirrored/load balance traffic, then you dont need to import anything.

Regards

[dr_wpg]

Thanks Jalejand, so I see two options: 1. Traditional routing, 2. Rely on LISP map-cache. 

I'd rather go with option 1 - normal routing out through VRF's. 

My OTT subnets gateway will be in the border GRT as the WLC's will be directly connected, so will I need to to route-leak my OTT subnets to my other VN's if hosts in my overlay want to reach my OTT subnets? 

[jalejand · Accepted solution]

Lets clarify something:

I'd rather go with option 1 - normal routing out through VRF's.

Traffic to and from APs are handled differently in fabric.

• When APs sends traffic out to the WLC, they don't use LISP (as there is no map-cache 0.0.0.0/0 entry on instance-id 4097), they rely on traditional routing table.
• When traffic comes from outside destined to the APs, the traffic hits a Border then it encapsulates that traffic to the AP in VXLAN (as APs are registered on the CP and there is a map-cache for the AP subnet to dictate this)

Fabric Overlay will always use LISP/map-cache/VXLAN

If the OTTs are in GRT in Border and clients on a fabric VRF, you will need a fusion router to leak these routes, yes.
The traffic flow will be the following:

• OTT Client - AP - Edge - Underlay/RIB - Border - WLC - Border - Fusion GRT [Leak] Fusion VRF - Border VRF - Edge VRF - Fabric Client
• Fabric Client - Edge VRF - Border VRF - Fusion VRF[Leak]Fusion GRT - Border - WLC - Border - Overlay/Map-Cache - Edge AP - OTT Client

[dr_wpg]

Thanks Jalejand - makes sense to implement route-leaking to the VRF's to enable connectivity to the OTT subnets. 

As an alternative, I could just configure the OTT mgmt subnet in GRT and then client subnet/SVI in border VRF right? This will negate the need to route-leak?

[jalejand]

That would work too!
Basically leaking on the WLC, being the mgmt interface for capwap in GRT and the client GW on a fabrc VRF

[dr_wpg]

Really appreciate your help Jalejand! Thank you