Classification:Confidential Hi,
Thanks for the response. "Now the problem with this approach is that if you have >1 spokes in the same PE," 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. Thanks -----Original Message----- From: Saku Ytti <[email protected]> Sent: Monday, January 13, 2020 10:58 AM To: Harivishnu Abhilash <[email protected]> Cc: [email protected] Subject: [EXTERNAL] Re: [c-nsp] Central Services Topology - Design question Hey, > Question: Have also seen comments in forum like. The best practice for this > Hub and Spoke is to use TWO VRF in Hub site - "From-Spoke" and "To-Spoke" This is immaterial implementation detail. Some shops do this, because their automation system abstracts VRF into set of import/export statements and clients share set and hubs share different set. Also if you have hub and spoke in the same PE, you're going to need another name, if not, single name is fine, but may be more difficult to automate as name does not imply config. ipv4 vrf hubs route-target export 42:hubs route-target import 42:spokes ipv4 vrf spokes route-target export 42:spokes route-target import 42:hubs Now the problem with this approach is that if you have >1 spokes in the same PE, they are able to communicate to each other. To workaround this, you'll need 'half duplex VRF', where ingress and egress RIB/FIB are different. Packets coming from spokes look at FibA, packets going to spokes look at FibB. FibA has only route to hubs, FibA has only routes to spokes. ip vrf spokesIn route-target import 42:hubs ip vrf spokesOut route-target export 42:spokes ip vrf hubs route-target export 42:hubs route-target import 42:spokes PE1: int Spoke1 ip vrf forwarding spokesIn downstream spokesOut int Spoke2 ip vrf forwarding spokesIn downstream spokesOut int Hub1 ip vrf hubs int Hub2 ip vrf hubs -- ++ytti This email is classified as Confidential 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/
