Message-
From: Saku Ytti
Sent: Tuesday, January 14, 2020 10:04 AM
To: Harivishnu Abhilash
Cc: cisco-nsp@puck.nether.net
Subject: [EXTERNAL] Re: Re: Re: [c-nsp] Central Services Topology - Design
question
On Tue, 14 Jan 2020 at 04:00, Harivishnu Abhilash
wrote:
> Thanks. As long as SPO
On Tue, 14 Jan 2020 at 04:00, Harivishnu Abhilash
wrote:
> 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
. My initial concern was of hair-pinning of
SPOKE TO SPOKE TRAFFIC from the HUB VRF.
Ta,
-Original Message-
From: Saku Ytti
Sent: Monday, January 13, 2020 3:25 PM
To: Harivishnu Abhilash
Cc: cisco-nsp@puck.nether.net
Subject: [EXTERNAL] Re: Re: [c-nsp] Central Services Topology
Ah, and don't forget "additive" as it was crucial in not removing an rt, but
rather, adding another rt to the already present rt.
A nice way of having multiple extend community attributes (rt's) to be able
to match on.
-Aaron
___
cisco-nsp mailing
When I started sharing some routes from one vrf to another vrf during my
deployment of cgnat, I came to understand that a vrf in my mind seemed to be
less about the name you give it, and more about the RT's you import and
export to accomplished the desired routing.
Further to that point, one day
On Mon, 13 Jan 2020 at 13:07, Harivishnu Abhilash
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
having any Spoke VRF.
Thanks
-Original Message-
From: Saku Ytti
Sent: Monday, January 13, 2020 10:58 AM
To: Harivishnu Abhilash
Cc: cisco-nsp@puck.nether.net
Subject: [EXTERNAL] Re: [c-nsp] Central Services Topology - Design question
Hey,
> Question: Have also seen comments in f
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
Classification:Public
Hi Team,
Have a basic question on Traditional Central Services Topology in MPLS VPN
Network in SP.. We want all the traffic between to be filtered by firewall
hooked to HUB PE.
Basically thought to go ahead with below (Basic and standard !) import-export
policy.
*
