Wired Intelligent Edge

Hi all, first of all I must admit I'm not a BGP/OSPF or VRF expert at all...this thread is just my very first and timid step into a unknown territory so be patient and sympathetic with me.

I have a networking scenario which is probably typically found on some Small DC where Customers networks are segregated and multi-tenancy is deployed.

I'm going to design a network where some VLANs (<25) shall require strict segmenation (so those will not land to a Layer 3 Core with IP Routing and ACL deployed <-- provided that this is an usual way to deploy a network where one don't want to involve Firewall in the picture leaving it a border role) and where some other VLANs (<20) will act as DC background for management and services purposes. Next Hop to WAN (and Co-located Campus Network) + Internet is going to be a Cluster of Firewalls (Forcepoint in Active/Active HA).

I've some very big doubts about the proper way to follow to deploy the scenario above: would I let DC services VLANs routed by a Core and the Core uplinked to FW thorugh a dedicated Transit VLAN...and let DC segregated VLANs to be transported directly to FW through a highly tagged uplink...in this I feel a big asymmetry...OR...drums beat...finally and correctly entering in the world of VRF (Virtual Routing and Forwarding)? if so...how? and what's about ACL or Route Policying (say a DC services VLAN doesn't need to be seen by a particular DC segregated VLAN and vice versa)?

Or...if the proposed scenario resembles one of a typical little hosting company that own a DC and that is dealing with Service+Customers dedicated VLAN (or Zones) connecting to some wide area networks (those of its Customers via a lot of Firewall's managed VPN) plus traditional public Internet...well...if so...would be great to understand the basic A-B-C to deploy such type of network.

Thanks for any lesson!

As you described, we can approach the solution with multiple ways.

If we let all the VLAN's exposed directly to Firewall, then there is no need of VRF's, so you can configure ACL's and route policies on the firewall. With this aproach, traffic between each VLAN/east-west has to transit via firewall which is not optimal.

If we configure one VRF for 20+ VLANs, and one transit vlan towards Firewall for each VRF, will help to segment nicely and have  interVlan traffic routed within the Core/Agg (which is more optimal way). If you plan to configure ACLs between the VLANs with in VRF you can do it as well but I would pref to leave the security function to a stateful Firewall than a Switch, so its best to group VLANs in to a VRF with the vLANs that is not required any ACLs, then configure a transit vlan for each VRFs and configure Stateful ACLs in Firewall.

Reg route-policies,may need more details on the requirement to advise it right. if you have multiple gateways connected to Switch and redirect depends on the specific destination, we've to do this on Core/Agg switch.

Hope this helps

---

@rbhupath wrote:

As you described, we can approach the solution with multiple ways.

Great!

---

@rbhupath wrote: If we let all the VLAN's exposed directly to Firewall, then there is no need of VRF's, so you can configure ACL's and route policies on the firewall. With this aproach, traffic between each VLAN/east-west has to transit via firewall which is not optimal.

---

Exactly...I absolutely agree with you. That way no IP routing will ever happen on the internal side (a Core will be used as a simple Layer 2 device) and the border Firewall will de-facto act as the policy enforcer and, more important, the router...all flows are transported with VLANs' tags up to one (via "uplink(s) tagged with VLANs" in ArubaOS-Switch/ProCurve jargons also known as "Trunk port(s)" in ArubaOS-CX/Cisco jargons) ore more uplinks up to Firewall's internal network facing interfaces...I would avoid this approach because Firewall will become a SPoF and also a bottleneck for East-West desired/allowed traffic (especially in comparison to North-South light traffic flows involving internal networks and WAN VPN connected or Internet destinations).

---

@rbhupath wrote: If we configure one VRF for 20+ VLANs, and one transit vlan towards Firewall for each VRF, will help to segment nicely and have  interVlan traffic routed within the Core/Agg (which is more optimal way). If you plan to configure ACLs between the VLANs with in VRF you can do it as well but I would pref to leave the security function to a stateful Firewall than a Switch, so its best to group VLANs in to a VRF with the vLANs that is not required any ACLs, then configure a transit vlan for each VRFs and configure Stateful ACLs in Firewall.

I agree with you 100%...our embrional idea is to define some VLANs (and corresponding IP Addressing space) dedicated to management/backend DC services purposes and those will be conveniently grouped in one or more VRFs used for Datacenter backend services (let me call them VRF Backend 1 bound to a group of VLANs requiring a inter-VLAN routing with no ACLs, VRF Backend 2 bound to another group of VLANs requiring a inter-VLAN routing with no ACLs and so on...) and some others VLANs dedicated specifically to Customers and Customers only (let me call them VRF Customer 1 bound to one only VLAN Customer 1, the same for VRF Customer 2 and so on...up to VRF Customer n)...so the approach of setting up a Transit VLAN for each VRF would fit nicely...but here a couple of questions (I hope to show you my doubts with these two questions):

1. Suppose we are going to use an ArubaOS-CX based solution on our next-to-be deployed Core - and I specify that because those series provide (single or LAG) Routed port(s) in comparison to ArubaOS-Switch based series that don't - how those Transit VLANs should be deployed to Firewall? IIRC to simluate a Routed Port on ArubaOS-Switch based switch an interface could be made tagged (or untagged if there is just one Transit VLAN instead of more) member of a /30 or /31 SVI and it is then uplinked to Firewall where a port should be configured accordingly...Transit done...clearly having more Transit VLANs will force to use uplink port tagged on those multiple Transit VLANs but that can happen using the very same physical uplink...that's what could happen on AOS-Switch...giving the usage of ArubaOS-CX should we use the same approach or should instead use more elegant Routed port(s)? in other terms what's the best method to uplink those Transit VLANs (say we have one for each VRF) to Firewall considering there we have a pretty limited number of physical ports dedicated to internal networks? I'm not able to image n Uplinks for n VRFs...in other terms...can we share a single uplink or we need to have (physically) more than one?
2. Will "VRF Route Leaking" feature play a potential role? will not using VRF Route Leaking partially break the VRF concepts permitting traffic routing (leaked) between some specific VRFs? probably we will use route leaking to access some VRFs by traversing East-West staying on the internal Core without relaying on availability of border Firewall and its Access policies...I see this approach as a sort of emergency lane availability in case of emergency to access particular zones no matter what is happening "northbound"...or to provide some "Global" services to Customer VRFs (e.g. access to a Backed VRF which provides some general services like Name Servers, NTP and so on...). Does it make sense?

---

@rbhupath wrote: Reg route-policies,may need more details on the requirement to advise it right. if you have multiple gateways connected to Switch and redirect depends on the specific destination, we've to do this on Core/Agg switch.

Hope this helps

---

Hope to have understood that last note correctly (did you refer to implementing PBR?)...we are going to have basically one dedicated Firewall Cluster (not sure if it will support multi-tenancy where each tenant would represent a Customer or not) and I'm pretty much sure it is not going to have unlimited number of internal facing ports.

---

@rbhupath wrote: Hope this helps

---

Definitely, your is an amazing help for a VRF starter and I would share with you more details about the transition we're planning and the complexity/challenges it involves.

Thank you a lot! Davide.

---

---

@rbhupath wrote: If we let all the VLAN's exposed directly to Firewall, then there is no need of VRF's, so you can configure ACL's and route policies on the firewall. With this aproach, traffic between each VLAN/east-west has to transit via firewall which is not optimal.

---

Exactly...I absolutely agree with you. That way no IP routing will ever happen on the internal side (a Core will be used as a simple Layer 2 device) and the border Firewall will de-facto act as the policy enforcer and, more important, the router...all flows are transported with VLANs' tags up to one (via "uplink(s) tagged with VLANs" in ArubaOS-Switch/ProCurve jargons also known as "Trunk port(s)" in ArubaOS-CX/Cisco jargons) ore more uplinks up to Firewall's internal network facing interfaces...I would avoid this approach because Firewall will become a SPoF and also a bottleneck for East-West desired/allowed traffic (especially in comparison to North-South light traffic flows involving internal networks and WAN VPN connected or Internet destinations).

 

---

@rbhupath wrote: If we configure one VRF for 20+ VLANs, and one transit vlan towards Firewall for each VRF, will help to segment nicely and have  interVlan traffic routed within the Core/Agg (which is more optimal way). If you plan to configure ACLs between the VLANs with in VRF you can do it as well but I would pref to leave the security function to a stateful Firewall than a Switch, so its best to group VLANs in to a VRF with the vLANs that is not required any ACLs, then configure a transit vlan for each VRFs and configure Stateful ACLs in Firewall.

I agree with you 100%...our embrional idea is to define some VLANs (and corresponding IP Addressing space) dedicated to management/backend DC services purposes and those will be conveniently grouped in one or more VRFs used for Datacenter backend services (let me call them VRF Backend 1 bound to a group of VLANs requiring a inter-VLAN routing with no ACLs, VRF Backend 2 bound to another group of VLANs requiring a inter-VLAN routing with no ACLs and so on...) and some others VLANs dedicated specifically to Customers and Customers only (let me call them VRF Customer 1 bound to one only VLAN Customer 1, the same for VRF Customer 2 and so on...up to VRF Customer n)...so the approach of setting up a Transit VLAN for each VRF would fit nicely...but here a couple of questions (I hope to show you my doubts with these two questions):

 

1. Suppose we are going to use an ArubaOS-CX based solution on our next-to-be deployed Core - and I specify that because those series provide (single or LAG) Routed port(s) in comparison to ArubaOS-Switch based series that don't - how those Transit VLANs should be deployed to Firewall? IIRC to simluate a Routed Port on ArubaOS-Switch based switch an interface could be made tagged (or untagged if there is just one Transit VLAN instead of more) member of a /30 or /31 SVI and it is then uplinked to Firewall where a port should be configured accordingly...Transit done...clearly having more Transit VLANs will force to use uplink port tagged on those multiple Transit VLANs but that can happen using the very same physical uplink...that's what could happen on AOS-Switch...giving the usage of ArubaOS-CX should we use the same approach or should instead use more elegant Routed port(s)? in other terms what's the best method to uplink those Transit VLANs (say we have one for each VRF) to Firewall considering there we have a pretty limited number of physical ports dedicated to internal networks? I'm not able to image n Uplinks for n VRFs...in other terms...can we share a single uplink or we need to have (physically) more than one?
   
   @@rbhupath: In both AOS-CX Switch or ArubaOS-Sw, Use just one or a LAG interface as L2-Trunk towards Firewall, and carry multiple Tagged VLANs. and configure each Transit VLAN in thier own VRF as needed.
   
   
2. Will "VRF Route Leaking" feature play a potential role? will not using VRF Route Leaking partially break the VRF concepts permitting traffic routing (leaked) between some specific VRFs? probably we will use route leaking to access some VRFs by traversing East-West staying on the internal Core without relaying on availability of border Firewall and its Access policies...I see this approach as a sort of emergency lane availability in case of emergency to access particular zones no matter what is happening "northbound"...or to provide some "Global" services to Customer VRFs (e.g. access to a Backed VRF which provides some general services like Name Servers, NTP and so on...). Does it make sense?
   
   @@rbhupath: Agree,We should be able to use route-leak in such cases, ut VRF route leak is not possible between default VRF to custom VRFs. but I would still recommend Firewall to allow inter VRF traffic to have better control.

---

@rbhupath wrote: Reg route-policies,may need more details on the requirement to advise it right. if you have multiple gateways connected to Switch and redirect depends on the specific destination, we've to do this on Core/Agg switch.

Hope this helps

---

Hope to have understood that last note correctly (did you refer to implementing PBR?)...we are going to have basically one dedicated Firewall Cluster (not sure if it will support multi-tenancy where each tenant would represent a Customer or not) and I'm pretty much sure it is not going to have unlimited number of internal facing ports.

@@rbhupath: Thats right I was talking about PBR. we dont need to have multiple internal ports on firewall, it should work as long as firewall support multple logical interfaces for each VRF.

 

---

@rbhupath wrote: Hope this helps

---

Definitely, your is an amazing help for a VRF starter and I would share with you more details about the transition we're planning and the complexity/challenges it involves.

 

Thank you a lot! Davide.

Hi Reddy,

sorry for delay (very busy days)...just one question...when you wrote:

In both AOS-CX Switch or ArubaOS-Sw, Use just one or a LAG interface as L2-Trunk towards Firewall, and carry multiple Tagged VLANs. and configure each Transit VLAN in thier own VRF as needed.

you exactly mean that each VRF should have its Transit VLAN to next hop gateway...and each route of last resort (to that gateway) should be placed globally (I don't think) or within that VRF?

In both AOS-CX Switch or ArubaOS-Sw, Use just one or a LAG interface as L2-Trunk towards Firewall, and carry multiple Tagged VLANs. and configure each Transit VLAN in thier own VRF as needed.

@Reddy@ - Thats right

you exactly mean that each VRF should have its Transit VLAN to next hop gateway...and each route of last resort (to that gateway) should be placed globally (I don't think) or within that VRF?

@Reddy@ - Within that VRF.

Thanks Reddy!

You helped me a lot and I'm now starting to have a more clear idea of how to plan the whole thing bit-by-bit (the more I dig into the more I discover that correctly planning the entire IP addressing space - VLAN SVI, VRF - is going to be a very important part of the project).

Davide.