This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Accept
Reject
Help
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

vlan communication only to vrf gateway

vlan communication only to vrf gateway

Go to solution
PeterK
Contributor III

‎03-20-2020 09:16 AM

Hello,

is there a way to have multiple vlans in a vrf, which can only communicate to the gateway of a vrf (firewall)?

explain:

  • communication in vlan should be possible (no private vlan)
  • communication between vlans in vrf should not be possible
  • communication from vlans to vlans in a other vrf or grt should be possible via default gateway of vrf (firewall)

I’ve lot of services which should not be able to communicate with other services except a few central services. Putting every service in a own VRF does not scale.

 

How can can I realize this? 

 

Thank you.

0 Kudos
1 ACCEPTED SOLUTION

Go to solution
Ludovico_Steven
Extreme Employee

‎03-24-2020 11:49 AM

I just recently had the same design request, and I have been validating a solution based on VSP and FabricConnect SPB. VSPs have a special type of ACLs called inVSN which basically allow applying an ACL not just to a port or a VLAN but can be applied to a VSN service I-SID and this can be specified either in the ingress or egress direction of traffic entering leaving the Fabric. The ACL I-SID can be either a L2 I-SID or a L3 I-SID.

So the approach consists of creating a VRF and turning that into a L3VSN (ipvpn) by assigning a L3 I-SID to that VRF. Then on every VSP in the fabric which has this VRF, we can apply the same identical ACL configuration; this is the ACL config I’m using, which has 3 ACEs:

filter acl 1 type inVsn matchType uniOnly

filter acl 1 name Red-L3VSN-PBR

filter acl i-sid 1 3000002

filter acl ace          1 1 name "No-PBR-from-FW"

filter acl ace action   1 1 permit count

filter acl ace ethernet 1 1 src-mac eq 94:9b:2c??49:01

filter acl ace          1 1 enable

filter acl ace          1 2 name "No-PBR-for-IPMC"

filter acl ace action   1 2 permit count

filter acl ace ethernet 1 2 ether-type eq ip

filter acl ace ip       1 2 dst-ip mask 224.0.0.0 31.255.255.255

filter acl ace          1 2 enable

filter acl ace          1 3 name "Rest-force-PBR-to-FW"

filter acl ace action   1 3 permit redirect-next-hop 192.168.99.254 vrf red unreachable deny count

filter acl ace ethernet 1 3 ether-type eq ip

filter acl ace          1 3 enable

 

The ACE of interest is the last one, which has an action of redirect-next-hop.

Basically any traffic entering the VRF to be IP routed, will be redirected to IP 192.168.99.254, which is my Firewall. The nice thing of this rule is that it is scalable, I can have 1 subnet in my VRF or 100 subnets, the same ACL config still works.

Of course if I want this to work across any VSP in the Fabric, we need all VSPs to be able to ARP for 192.168.99.254; so the solution here is to place the Firewall interface on a L2VSN which reaches out to all VSPs and is terminated with an IP interface on the same VRF we are applying the above ACL filters to.

Now, to the other ACEs 1 & 2; I don’t need/want the redirect to also happen for traffic returning from the Firewall, so I’m matching the Firewall MAC in ACE1 and coming out. Putting a hard MAC in there is not very nice, but I did not find anything better..

And if you are doing ACL redirect-next-hop with VSPs you need to make sure that you are only doing that for IP unicast frames (which can be routed on the VSP), otherwise the VSP does actually fire them off as well to the redirect-next-hop.... So ACE2 matches IP Multicast packets and comes out.

However I’m seeing that the “unreachable deny” option is not working with 8.1.1.0 GA; basically, if the Firewall goes down, we want all IP routing in the VRF to be denied, but what I’m seeing is that local IP routing then resumes. There is a bug open for this, so am waiting to re-test this once we have that fix. Can then share a deck of the setup.

View solution in original post

0 Kudos
10 REPLIES 10

Go to solution
Miguel-Angel_RO
Valued Contributor II

‎03-26-2020 11:14 AM

Peter, from my pint of view, the best option is to put the FW as default gateway for the different VLANs.

I don’t have another solution for you for the moment.

Mig

0 Kudos

Go to solution
PeterK
Contributor III

‎03-26-2020 10:24 AM

Peter,

As mentionned I put the VLAN interface in the VRF just in cas of...If somebody configure an IP address by mistake, this will be in a dedicated VRF.

On the other hand you want the firewall to be the default gateway for your clients but you don’t want the FW to be in the same broadcast domain as the clients…This seems quite difficult.

How are you going to manage ARP and DHCP ?

Mig

 

Hi Mig,

I think, we have a missunderstanding. I will not have the firewall as gateway for the clients directly. Firewall should be gateway for the vrf where the client-vlans are stored in. clients will have vlan-ip-interface of vrf as gateway. But I will not, that clients of different vlans inside the vrf be able to communicate with each other.

0 Kudos

Go to solution
Miguel-Angel_RO
Valued Contributor II

‎03-25-2020 09:11 AM

Hi Mig,

thanks for your reply. FW have IP in Enddevice-VLANs is not what I want. Of course you can do this in small enviroments but in bigger Installations this is a no-go for me because every broadcast hit the firewall and stresses the cpu in addition to the normal unicast traffic.

Why will you add the vlan-interface (without a IP configured) to a VRF when a Firewall have a IP and is doing the forwarding. This makes currently no sense for me.


Peter,

As mentionned I put the VLAN interface in the VRF just in cas of...If somebody configure an IP address by mistake, this will be in a dedicated VRF.

On the other hand you want the firewall to be the default gateway for your clients but you don’t want the FW to be in the same broadcast domain as the clients…This seems quite difficult.

How are you going to manage ARP and DHCP ?

Mig

0 Kudos

Go to solution
Ludovico_Steven
Extreme Employee

‎03-25-2020 08:05 AM

Well, yes, the L3 config is done on the DVR Controllers, but both the DVR Controllers and the DVR Leaf nodes will be able to IP route between the DVR subnets, without going through any Firewall.

The ACL config suggested can be applied to a DVR Leaf as well, but there is no way to create a separate IP interface (non-DVR) on the Leaf to be able to ARP for the redirect-next-hop IP; and the Firewall cannot be a DVR Host, because we only support hosts only on DVR VLANs, not IP routers or anything sending traffic from non-local DVR IP subnet.

In this case it would be simpler to have the VLANs as L2 only on the Leaf nodes and take them to the Firewall via L2, the Firewall of course now has as many IPs as there are VLANs.. and you won’t be needing any DVR for these VLANs..

Or else, you still keep the VLANs as L2 on the Leaf nodes, but you terminate these VLANs on an IP interface on the Controller (platform VLAN + IP + VRRP) and on the Controller you apply the same ACL config except that the I-SID you match in the ACL will be the L2 I-SID of the VLAN (not the L3 I-SID of the VRF) and the action will be again to re-direct to the Firewall IP. So now your Firewall only needs 1 IP interface to cover all VLANs, but you now need to create an inVSN ACL for every VLAN.

0 Kudos
GTM-P2G8KFN