cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1146
Views
3
Helpful
5
Replies

LISP Pub/Sub Migration for Existing Campus Implementation

anthony.wild
Level 1
Level 1

Hello,

I'm going to do my best to describe this so bear with me. We have an existing SDA campus deployment... roughly 6 large "facilities" as independent fabrics that connect to a central site via IP Transit (BGP). That central site is the distribution/fusion layer with Catalyst 9606 switches which then egress into shared services (ACI) , WAN, out to internet firewall, etc.

My question is, is there any sort of reduction in administrative or technical burden if we were to change the way that those campus facilities interface with the 9606, such as LISP Pub/Sub? What does that look like.... IE) making the central site a fabric site, adding CP/B role to the 9606s, and then setting up an SD-Access transit between the individual fabric sites and the central site in lieu of a IP/BGP based one?

I'm also aware of some of the other forum posts in which folks are advocating towards LISP Pub/Sub as it is the "innovation focus" for Cisco so if that too is a qualitative reason to consider moving... it would be great to understand.

Thanks all!

1 Accepted Solution

Accepted Solutions

jedolphi
Cisco Employee
Cisco Employee

Hi Anthony, to do this question justice you might need to deep dive into the design and strategy with you Cisco sales or services representative, there’s a lot to explore here given you already have operational SD-Access Fabric Sites.

LISP Pub/Sub is where our feature dev will be focused moving forward (as opposed to LISP/BGP). However as of this writing there is no mechanism to migrate existing Fabric Sites from LISP/BGP to LISP Pub/Sub. Without committing to any ETA (talk to your sales rep please), we have an internal beta of a LISP/BGP to LISP Pub/Sub migration guided workflow which MAY become generally available sometime during next calendar year. Until that workflow exists your existing production Fabric Sites will need to stay on LISP/BGP, unless you want to completely de-configure and re-configure them.

More generally, what you are suggesting I think is an SD-Access Transit where there is a hub site (9600s) connected to the outside world with IP Transit and spoke sites connected to the hub site with SDA Transit. This is a valid design and other customer have done it. The design natively preserves inter-site VN and SGT preservation, reduces the number of Border Node EBGP peerings, handoffs, manual VRF extensions.

View solution in original post

5 Replies 5

u will need to introduce TCPs, to consider WAN circuits abilities &... depending on your HUB's legacy deployment its migration may cost to u. prepare your CapEX other words :0)

Thanks! I should mention that the buildings are roughly 600-1000 meters away from each other. No WAN circuits involved, all private campus fiber.

jedolphi
Cisco Employee
Cisco Employee

Hi Anthony, to do this question justice you might need to deep dive into the design and strategy with you Cisco sales or services representative, there’s a lot to explore here given you already have operational SD-Access Fabric Sites.

LISP Pub/Sub is where our feature dev will be focused moving forward (as opposed to LISP/BGP). However as of this writing there is no mechanism to migrate existing Fabric Sites from LISP/BGP to LISP Pub/Sub. Without committing to any ETA (talk to your sales rep please), we have an internal beta of a LISP/BGP to LISP Pub/Sub migration guided workflow which MAY become generally available sometime during next calendar year. Until that workflow exists your existing production Fabric Sites will need to stay on LISP/BGP, unless you want to completely de-configure and re-configure them.

More generally, what you are suggesting I think is an SD-Access Transit where there is a hub site (9600s) connected to the outside world with IP Transit and spoke sites connected to the hub site with SDA Transit. This is a valid design and other customer have done it. The design natively preserves inter-site VN and SGT preservation, reduces the number of Border Node EBGP peerings, handoffs, manual VRF extensions.

Thank you!

As a follow up, does this then completely preempt the ability to then create an IP Based transit at the local fabric level? The sites are manufacturing facilities which maintain the Perdue enterprise reference architecture for ICS/Controls networks. We achieve this by creating an IP Based peering on the border node to a Cisco FTD industrial firewall where the manufacturing gateways and iDMZ resides, and then cabling back from the firewall to the switch to propagate those industrial networks at Layer 2 via the L2VN feature to the various connected extended nodes downstream in the network and on the plant floor.

jedolphi
Cisco Employee
Cisco Employee

Hi Anthony,

Each Fabric Site can be concurrently connected to 0 or 1 SD-Access Transits and 0 to many IP Transits. Typically, in the most general sense (not specific to your scenario!), reducing the number of IP Transits is considered attractive because it's less EBGP peers and VRFs to maintain in the non-SD-Access network.

I might also mention, just in case you weren't aware, the LISP architecture used in a Fabric Site must be the same LISP architecture used in an SD-Access Transit, so you would not be able to connect a LISP/BGP Fabric Site to a LISP Pub/Sub SD-Access Transit.

HTH, Jerome