vlan communication only to vrf gateway

[PeterK]

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.

[PeterK]

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.

[PeterK]

Hi Ludovico,

this sounds pretty good, thanks for this input. We’re currently planning to use DVR. From my point of view, it should not be required to configure this in addition on the dvr-leaf devices, right? Because all L3 config is done on the dvr-controller devices.

[Miguel-Angel_RO]

Peter,

I’m not sure to catch it all but…

What I used to do is that I put the interface of the necessary VLANs in a specific VRF without giving an IP address to the interface. The idea is to “isolate” those VLANs (typically DMZ) in a VRF in case of human error giving an IP to the interface.

The FW will have an IP in this VLAN and will be the default gateway for this VLAN.

No inter-VLAN communication is possible, intra-VLAN communication is possible and all the traffic goes through the FW.

I think I’m meeting all the requirements

Regards

Mig

[Ludovico_Steven · Accepted solution]

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.

[PeterK]

Hey Sandro,

thanks for your reply. But this ACL-Style does not really scale. Of course, it possible, but by adding new vlans to this vrf the number of ACL entries will grow up potency (hope this is the right word).

I checked a few guides about the VOSS accept-policies but I didn’t found a good solution for me or I don’t understand it in the right way.