Separate VLAN for WAN link

Solved
Vlad
Conversationalist

Separate VLAN for WAN link

Hello Everyone,

I'm new to the forums and wanted to start a discussion regarding a topology that I have in mind for a new office.  Planning on having a single MX250 for the firewall/L3 and stack of MS250 switches underneath. I an planning to bring in 2 ISP's that will provide an RJ45 handoff. That will terminate at an arbitrary port on one of the MS250 switches. My idea was to set a vlan (let's say 1000) on that port and make sure its an access port. Patch that port into the MX250 WAN1 port, from what I can tell, Im allowed to tag a wan port.  Repeat the same with ISP2 (vlan 1001) and WAN2 port.

At this point, I should be able to communicate to the cloud, either by statically configuring an IP or getting via dhcp. 

 

Does anyone see any issues with the above design/statements? If not, i'll proceed to the core switch topology and this is where I'm a bit hazy with the way Meraki handles vlaning/routing...

 

When I configure a port on the MX for the local LAN, on a completely different port with a completely different vlan, do I need top make sure that port is able to carry vlans 1000//1001 or does the Meraki somehow automagically mask that requirement and builds a routing table that will provide connectivity?

1 Accepted Solution
Vlad
Conversationalist

Thanks @RyanB, this totally makes sense. One of the reasons the idea of terminating at the "core" stuck with me is because eventually (hopefully), i'll be deploying a second MX250 as a warm spare and I wanted to build a foundation/standards for the way we'll be doing WAN links. I would terminate at the core (single port) and then I would split out from the core into each of the respective WAN ports on the MX pair. And I think your suggestion of not having to tag the WAN port makes good sense. This might get forgotten or overlooked down the road and will send future me or next admin for a loop, no pun intended 🙂

 

Another reason to terminate at the core is flexibility in my opinion and please feel free to poke holes in this as much as you please....If we ever have to swap out the firewall and go to a completely different vendor (long shot), we'd be able to set up the devices along side production and failover somewhat seamlessly.  Possibly down the line, if this tiny branch office network expands, I could potentially enable L3 and involve my core in some routing decisions (again, long shot).

 

My last question for you If I may, is regarding the routing table and the default route. At this point, I should have 2 direct routes, both default, from each of the ISP's and another direct route from the LAN interface(granted there is only a single flat VLAN for local) In order to be able to manipulate traffic, I believe I would modify the Primary WAN option within the MX interface to change the metric for which route traffic would be going out of. Do I need to setup any static routes? How do I specify the default route config or is that automatic and handled by the MX?

 

Thanks again, This was seriously helpful

 

 

View solution in original post

10 Replies 10
MilesMeraki
Head in the Cloud

Is this an MPLS WAN or DIA ISP connection? if DIA connection why don't you just plug the ISP's RJ45 handoffs directly into the WAN 1 and WAN 2 ports of the MX250? Assuming you're getting a single handoff for each ISP.

Eliot F | Simplifying IT with Cloud Solutions
Found this helpful? Give me some Kudos! (click on the little up-arrow below)
Vlad
Conversationalist

These are both DIA links. The immediate issue that I would run into with the MX250 is that the WAN interfaces are SFP+. Both of the ISPs are giving me RJ45 handoffs because we are taking the poor man's approach to getting out to the web and will be ordering two cheap "business grade" providers.  I am taking precautions and will be getting SFP to copper modules just in case, but the plan is to definitely be weary of the costs involved. Eventually, the plan is to get a redundant MX as a warm spare in which case, we'll have go with the vlan-off-the-WAN approach or introduce a "dirty" switch. 

RyanB
Meraki Employee
Meraki Employee

Does anyone see any issues with the above design/statements?

There isn't an issue with that, but a few things to be aware of. I typically turn off RSTP just so I'm not putting this onto the ISP network - but be careful you're not making any loops. 

On top of that, if you set port 48 as access into VLAN 1000 which has your ISP link into it, you can just make port 47 access on VLAN 1000, and plug that into the MX on WAN 1 without having to tag a VLAN on the MX. 

As WANKiller said, if you only have one MX250 you don't really need to do this, and you can plug the ISP link directly into WAN1. People usually go with this design when they need to split that one RJ45 handoff into 2 different edge MX250's for warm spare.

 

When I configure a port on the MX for the local LAN, on a completely different port with a completely different vlan, do I need top make sure that port is able to carry vlans 1000//1001 or does the Meraki somehow automagically mask that requirement and builds a routing table that will provide connectivity?

You don't want to do this. Keep the WAN & LAN side separate. When you configure a trunk link between the MX LAN and your downstream switch you'll want to only allow certain VLAN's on that trunk - basically all VLAN's except 1000 & 1001. On the MS port when you set the link type to trunk, just specify the specific VLANs and list all the VLANs between the MX and MS (and again don't include 1000 or 1001 in that list). 

 

Physical Connectivity - for clarity

Cable 1: ISP Link into Port 48 on MS250 - configured access VLAN 1000 disabled RSTP

Cable 2: MX WAN 1 interface into Port 47 on MS250 - MX default configuration, MS250 port 47 configured access VLAN 1000 disabled RSTP. 

Cable 3: MX LAN 1 interface into Port 1 on MS250 - trunk on both sides, allowed VLANS: 1,5,10,15 (or whatever VLANs you've created on the MX - don't include 1000 or 1001).

 

Hope this helps!

PhilipDAth
Kind of a big deal
Kind of a big deal

@Vlad that will work fine.  Personally I would make the ports towards the MX250 access ports in the correct VLAN.  Then you wont have to configure anything on the local status page of the MX250's.  The MS250's will work "out of the box".  If you need to use tagging towards the ISP I would make only that port a trunk port with only that VLAN allowed.

 

Vlad
Conversationalist

That is a great idea and i think is the correct approach. Having a vlan tag on the WAN interface is "snowflaky" and future Vlad or next admin will certainly forget this config and will lose probably 2-3 hours of their day searching for that 🙂

Vlad
Conversationalist

Thanks @RyanB, this totally makes sense. One of the reasons the idea of terminating at the "core" stuck with me is because eventually (hopefully), i'll be deploying a second MX250 as a warm spare and I wanted to build a foundation/standards for the way we'll be doing WAN links. I would terminate at the core (single port) and then I would split out from the core into each of the respective WAN ports on the MX pair. And I think your suggestion of not having to tag the WAN port makes good sense. This might get forgotten or overlooked down the road and will send future me or next admin for a loop, no pun intended 🙂

 

Another reason to terminate at the core is flexibility in my opinion and please feel free to poke holes in this as much as you please....If we ever have to swap out the firewall and go to a completely different vendor (long shot), we'd be able to set up the devices along side production and failover somewhat seamlessly.  Possibly down the line, if this tiny branch office network expands, I could potentially enable L3 and involve my core in some routing decisions (again, long shot).

 

My last question for you If I may, is regarding the routing table and the default route. At this point, I should have 2 direct routes, both default, from each of the ISP's and another direct route from the LAN interface(granted there is only a single flat VLAN for local) In order to be able to manipulate traffic, I believe I would modify the Primary WAN option within the MX interface to change the metric for which route traffic would be going out of. Do I need to setup any static routes? How do I specify the default route config or is that automatic and handled by the MX?

 

Thanks again, This was seriously helpful

 

 

RyanB
Meraki Employee
Meraki Employee

One of the reasons the idea of terminating at the "core" stuck with me is because eventually (hopefully), i'll be deploying a second MX250 as a warm spare and I wanted to build a foundation/standards for the way we'll be doing WAN links.

Yeah it's a very common approach, good to put some forethought into it now. Also yes, totally forgot the MX250 has SFP+ WANs so you'll need to convert the media. 

 

At this point, I should have 2 direct routes, both default, from each of the ISP's and another direct route from the LAN interface(granted there is only a single flat VLAN for local) In order to be able to manipulate traffic, I believe I would modify the Primary WAN option within the MX interface to change the metric for which route traffic would be going out of. Do I need to setup any static routes? How do I specify the default route config or is that automatic and handled by the MX?

Not sure I entirely follow, but let me just over answer it and hope I cover your questions.

The core switch if it's L2 will just use the trunk up to the MX where the MX will hold the gateway for all the VLANs you've created. If the core switch is L3 you'd probably have one transit VLAN between the MX and the Core and you'd put a 0.0.0.0/0 route on the core up to the other end (MX) of the transit VLAN, so that all traffic goes back to the MX. You'd have no routes configured on the MS250 if you're running it in L2 mode, and only one configured if you ran it in L3 mode (route to the MX).

 

The MX then would have it's two WAN links which come through the MS250. The MX will NAT the traffic for any private addresses into the two public addresses from each ISP by default. The MX by default is going to not load balance those links, but make WAN1 it's primary. Within Security Appliance > Traffic Shaping in dashboard you're able to turn on load balancing if you want the MX to utilize both internet links, you can make WAN 2 primary, or you could even define certain local VLANs take different internet links based on source or destination. But no default route configuration on the MX is required, by default it will send any traffic it doesn't know about out the WAN interfaces.

 

DHAnderson
Head in the Cloud

My personal preference is to keeps things simple, until you can't.

Planning a current network design based future maybes (not hard requirements) can increase cost, complication and reliability, without any direct benifit today.

So my suggestion would be to set up the simplest design first, and plug the two WAN ports into the MX. Later, when you eventually (hopefully) get a warm spare, a more complex configuration is required. Just be sure you do not move your single point of failure from a firewall to a switch.
Dave Anderson
GrantB
New here

Is cabling the single WAN handoff from dual ISP directly to downstream MS switches and then from MS switches back upstream to HA pair of MX an official Meraki solution?  Is there any documentation on this other than in the Meraki community?

 

typeraj
Here to help

@GrantB I've been referring to these two articles, which you may find useful: 

 

https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair

https://www.willette.works/mx-warm-spare/

 

@RyanB When you have 2 ISPs (single RJ45 handoff from each) split between two MXs, am I right in thinking that you'd need 3 IPs within the same range, from each ISP: ISP1-Gateway, ISP1-MX1 & ISP1-MX2 and then ISP2-Gateway, ISP2-MX1 & ISP2-MX2?

 

 

Get notified when there are additional replies to this discussion.
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.