[c-nsp] Central Services Topology - Design question

Harivishnu Abhilash Harivishnu.Abhilash at mannai.com.qa
Mon Jan 13 20:59:54 EST 2020


Classification:Public

Thanks. As long as SPOKES won't import other SPOKES, Exported RT values - This (even if we have SPOKE VRF's in same PE) should NOT cause SPOKE-SPOKE traffic to bypass the HUB right ? From the SPOKE perspective the routes imports will be / should be from the HUB VRF only. My initial concern was of hair-pinning of SPOKE TO SPOKE TRAFFIC  from the HUB VRF.  

Ta,




-----Original Message-----
From: Saku Ytti <saku at ytti.fi> 
Sent: Monday, January 13, 2020 3:25 PM
To: Harivishnu Abhilash <Harivishnu.Abhilash at mannai.com.qa>
Cc: cisco-nsp at puck.nether.net
Subject: [EXTERNAL] Re: Re: [c-nsp] Central Services Topology - Design question

On Mon, 13 Jan 2020 at 13:07, Harivishnu Abhilash <Harivishnu.Abhilash at mannai.com.qa> wrote:

> You recon, this can be an issue only if > 1 Spoke in SAME PE. ?  In my case, spokes will be in different PE. Also HUB sites won't be having any Spoke VRF.

Then you can get away from using half-duplex VRF and do it the simple/easy way. But in many cases these tend to change over time, and if you later get 2nd spoke in any given PE, you're going to have an issue. At least communicate this limitation clearly to your PM and such that once the shit hits the fan, you can show that the limitation was communicated.

--
  ++ytti

This email is classified as Public by Harivishnu Abhilash
Disclaimer: This electronic message and all contents contain information from Mannai Corporation which may be privileged, confidential or otherwise protected from discloser. The information is intended to be for the addressee only. If you are not addressee, any disclosure, copy, distribution or use of the contents of this message is prohibited. If you have received this electronic message in error please notify the sender immediately and destroy the original and all copies.


More information about the cisco-nsp mailing list