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 <[email protected]> Sent: Monday, January 13, 2020 3:25 PM To: Harivishnu Abhilash <[email protected]> Cc: [email protected] Subject: [EXTERNAL] Re: Re: [c-nsp] Central Services Topology - Design question On Mon, 13 Jan 2020 at 13:07, Harivishnu Abhilash <[email protected]> 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. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
