Mailing List Archive

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
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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 <saku@ytti.fi>
Sent: Monday, January 13, 2020 10:58 AM
To: Harivishnu Abhilash <Harivishnu.Abhilash@mannai.com.qa>
Cc: cisco-nsp@puck.nether.net
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 cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Mon, 13 Jan 2020 at 13:07, Harivishnu Abhilash
<Harivishnu.Abhilash@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
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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 I typo'd a vrf name, and was stunned to
realize that everything was still working! ...came to realize that the vrf
name doesn't matter, since mp-ibgp doesn't advertised anything of the
name... simply the rd, rt stuff matters.

To Saku's point, if you have local and separate vrf's, I'm pretty sure I had
to use an auto-export command in juniper to allow that local route sharing.

-Aaron

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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 list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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@ytti.fi>
Sent: Monday, January 13, 2020 3:25 PM
To: Harivishnu Abhilash <Harivishnu.Abhilash@mannai.com.qa>
Cc: cisco-nsp@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@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.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Tue, 14 Jan 2020 at 04:00, Harivishnu Abhilash
<Harivishnu.Abhilash@mannai.com.qa> 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 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.

You addressed your concern perfectly, as long as you do not use
table-label solution, the packet will go all the way to the CE,
however you still need to maintain configuration in CE which forces
packet to FW instead of returning back to PE.
So once you have the config, double check the VPN label is pointing
out to CE, and you're golden.


--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Classification:Confidential

Thanks ! That was the answer I was looking to get confirmation on :). I have some static route which will be using aggregate Label (VRF Table label)...
So we may need to force all the prefixes (including the static ) to use per prefix label.

Ta,

-----Original Message-----
From: Saku Ytti <saku@ytti.fi>
Sent: Tuesday, January 14, 2020 10:04 AM
To: Harivishnu Abhilash <Harivishnu.Abhilash@mannai.com.qa>
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 <Harivishnu.Abhilash@mannai.com.qa> 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 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.

You addressed your concern perfectly, as long as you do not use table-label solution, the packet will go all the way to the CE, however you still need to maintain configuration in CE which forces packet to FW instead of returning back to PE.
So once you have the config, double check the VPN label is pointing out to CE, and you're golden.


--
++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 cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/