cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Passing off VRF's to an MX

Here to help

Passing off VRF's to an MX

Hey all,

 

Hopefully this question hasn't already been asked but looking for some insight / advice on the following. I am being tasked with installing a pair of Meraki firewalls in high availability at a client site, and we are going to be using the clients switching infrastructure for our hosts on the network, and the firewalls themselves will live at the campus edge. 

 

The client uses almost no Layer 2 and are running almost solely with VRF's to segment traffic. They mentioned that they wish to create as many VRF's as necessary to mirror our VLAN scheme we presently use in other sites (CORP, IOT, Surveillance). 

 

I have little to no understanding as to how I should be configuring the firewalls to support this passoff of VRF's to the Meraki MX. On the MX I see I can create virtual interfaces tied to VLAN IDs so am I still to configure that in this scenario? Then do I just ensure that the client connects an Ethernet handoff configured for the CORP VRF they create  to an access port on the MX configured for the CORP VLAN? When I create a VLAN virtual interface it automatically adds that route to that configured subnet to the route table so I don't think I need to do any static routing either to get this to work I wouldnt think. 

 

Also side note, if my thinking above is correct, does this also mean I could technically use a single ethernet handoff to a port on the MX I configure as a trunk to carry all the VLANs? Or will this not work because with VRF's traffic will not have a VLAN tag when it enters the trunk from the clients Layer 3? 

 

Any tips or recommendations are greatly appreciated. 

14 REPLIES 14
Kind of a big deal

Re: Passing off VRF's to an MX

Interesting choice of VRFs for the scenario mentioned.  I'm going to have to make lots of assumptions as to why VRFs were used.

Is there any inter-vrf routing happening?

 

Assuming no inter-vrf routing, and that VRFs are being used for complete segration, you are going to need a pair of MXs per VRF.

Here to help

Re: Passing off VRF's to an MX

Hi Philip,

 

Thanks for replying! The choice to use VRF is not mine, it is the client's. They are not willing to allow me to put my own switches in their physical space and thus I must run on their Layer 3 switching environment. 

 

There should be no inter-vrf routing as the whole point of the topology is to keep traffic segmented. I should have mentioned that there is also a point-of-sale VRF in addition to the ones I mentioned prior, so in the interest of PCI compliancy we need to keep traffic from the cardholder data environment segmented. 

 

Let's take out the high-availability component for the sake of simplicity in this discussion. It then becomes a single MX per VRF? 

 

Can you elaborate any further on why an MX can't handle the pass off of multiple segmented VRF's?

Building a reputation

Re: Passing off VRF's to an MX

Perhaps I‘m missing something but from my point of view this should be rather trivial:

 

Each VRF needs to have its own transfer net to a specific VLAN interface on your MX pair and point its default route to the MX. Everything inside the specific VRF will stay inside its own routing table, inter-VRF traffic and everything going to the „outside world“ will then be routed via your MX pair.

 

Of course, you‘ll have to set up routing on the MX side accordingly. Overlapping IP spaces are an obvious no-go in this scenario 

Here to help

Re: Passing off VRF's to an MX

Hello!

 

So what you are saying is that I should still setup my VLAN interfaces on the MX and make at least one access port for each of these VLANs. The client then needs to provide an ethernet handoff that passes that specific VRF across to the MX and ensure it is patched to the proper access port configured to be for the matching VLAN on the MX? 

 

Yes and then from their the MX can handle routing, I can make my own L3 firewall rules to deny inter-VLAN routing as I see fit and filter specific traffic to the outside world. 

 

Yes there will be no overlapping subnets in place here, all unique subnetting per-each VRF. 

 

If I am mistaking anything please let me know. Is there a way to condense multiple handoffs down to a single link? Perhaps the client can configure their interface closest to the MX as a trunk and somehow tag the VRFs with a VLAN ID to carry those VLANs across to a trunk port on my side? Forgive me if this is entirely incorrect, I have next to no experience with VRFs in practice. 

Kind of a big deal

Re: Passing off VRF's to an MX

>Can you elaborate any further on why an MX can't handle the pass off of multiple segmented VRF's?

 

MX has no support for VRFs.  Sure it supports VLANs, but VRFs are not the same thing as VLANs.

 

If you want to maintain layer 3 segmentation and want to maintain the spirit of VRFs you will need an MX per VRF.  You may well talk to the MX using tagged frames, but that in itself is just an access to a VRF - not a VRF in itself.

Here to help

Re: Passing off VRF's to an MX

@PhilipDAth, I see.

That is really all I am trying to accomplish. I don't wish to incorporate the VRF's into my MX, I just wish for the traffic to remain segmented as the VRF's are doing downstream and have the traffic pass across to the MX and be tagged for the appropriate VLAN. So correct, access to each VRF is what I seek.

Kind of a big deal

Re: Passing off VRF's to an MX

Do you plan for the MX to operate transparently (like a bridge/switch), or be a layer 3 device with a subnet behind it?

Here to help

Re: Passing off VRF's to an MX

I plan for this MX to be able to do it's own routing and serve as the DHCP server for various subnets (one for each downstream VRF)

Kind of a big deal

Re: Passing off VRF's to an MX

In that case create a simple untagged layer 3 interface on your device, and place it in the appropriate VRF.  Plug the MX WAN port into this.

You can then plug the MX LAN interfaces into any internal switching using any internal VLAN you want.

 

Note that the MX will NAT will internal VLANs to the IP address on its WAN interface.  There is a no-nat feature in beta if this is no desirable.

 

Also it will be critical that the WAN interface of the MX can reach the Meraki cloud.

Here to help

Re: Passing off VRF's to an MX

But the VRF's (and the client switching environment) is downstream of my MX so they need to connect to the MX LAN ports. The MX WAN port is already connected to the client's ASA who is acting as a service provider for our internet at this site. 

 

Diagram for clarity:

 

Topology.jpg

Kind of a big deal

Re: Passing off VRF's to an MX

Without the Meraki, how is the ASA plumbed in?  A VLAN per VRF, or a single interface attach to the global VRF (or some other VRF)?

 

What is the Meraki going to be used for?  Just monitoring and some security and content filtering, or do you also want to run AutoVPNs to it?

Here to help

Re: Passing off VRF's to an MX

I am unsure about the ASA configuration, it is the clients. They provide us a 1:1 NAT for our WAN connection at this site. Public IP NAT'ed to the shared virtual IP for high availability MXes.

 

The MX pair is going to be used for monitoring, security & content filtering, normal firewall stuff. There will be no AutoVPN's save for one that we would use for our Syslog VLAN to export logs to Splunk in our datacenter. 

Highlighted
Kind of a big deal

Re: Passing off VRF's to an MX

I would say whatever configuration you have on your side facing towards the ASA - it will the same as facing towards the MX.

Kind of a big deal

Re: Passing off VRF's to an MX

As far as I am aware VRF uses 802.1Q trunks. Is there a danger we are over thinking this issue?

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.