Network design question

[snared04drummer]

I have a project that I'm designing for a customer, and we have a complication for which there has risen a disagreement on design philosophy.

The design calls for the hosts in Vlan 211, at site 20, to be in the same VLAN and subnet as the server attached to the core.  I believe that they in fact can exist as separate subnets, and allow routing to handle the communication between the devices, with the use of ip helper-address and other configurations, as needed.

However it has been suggested that a better design would be to have unique VLAN's at each site, to use SVI's on either end rather than routed ports, and to tag VLAN's throughout the network as needed.

As I have noted on the drawing, this would literally put the default gateway of the server on a remote top switch, which leads me to believe that this is bad design practice.

However, I simply do not have enough experience using SVI's in this manner to articulate this belief further, nor am I sure whether it's even correct or not.

Any ideas/thoughts would be greatly appreciated.

[Jon Marshall]

However it has been suggested that a better design would be to have unique VLAN's at each site, to use SVI's on either end rather than routed ports, and to tag VLAN's throughout the network as needed.

I don't follow the bit about SVIs at either end ie. you don't have SVIs for the same vlan on both the site and core switches.

And if you were extending the vlans what is the point of local SVIs ie. you may as well have them all on the core switch.

Not that I am saying that is a good choice.

Are you sure they are not saying they will route some vlans locally on the site switches and route to the core over a dedicated SVI but then also for some vlans they will route them on the core.

That would make more sense if there is a requirement to have the same vlan(s) across multiple sites.

But you wouldn't have a local SVI and one on the core for the same vlan, it definitely wouldn't use the same IP as in your diagram as you would get IP address conflicts and the server wouldn't be using .255 as it's IP as that is a broadcast address.

It really depends on whether there is a need to have the same vlan(s)/IP subnet(s) across multiple sites.

If there isn't then I don't understand the logic of what they are proposing.

And regardless of all the above it makes no sense to put the server in the client vlan unless there is a specific need for it.

Jon

[snared04drummer]

The idea is that, yes, some vlans/subnets need to exist across multiple sites.

I.e. a phone system where the server, which is located at the core, needs to be on the same subnet as all of the phones that it services.  I understand that in practice, most applications wouldn't need a network configuration to exist in this way, but we've been given this requirement for the design.

That being said, most vlans and their subsequent SVI's will exist ONLY locally at a site.  Specific VLAN's that need to exist across multiple sites will be tagged across as needed.

The .255 server address was just a typo.  Assume it's 254.

So let's approach this another way:

If you needed to extended a VLAN/subnet across multiple sites, say, with the basic design that's shown, what would be best practice for implementation?

[Jon Marshall · Accepted solution]

For the vlans you don't need to extend ie, they are routed locally on the site switch you create the SVIs there.

For vlans that are to be extended the SVIs are on the core switch but you don't also have an SVI on the site switch as well, this is where I think the proposed design is wrong.

What you then do is -

1) create a new vlan on the site and core switch (different vlan per site). This vlan has no end clients in it and the IP subnet is a /30.

2) create SVIs on site switch and core switch for this vlan.

3) the site switch is connected to the core with a trunk and you allow on the trunk link -

the new vlan you have created

any vlans you are extending between the sites.

All other vlans ie. the ones routed locally on the site switches are not allowed on the trunk link.

In effect you have a P2P link but with a vlan and SVIs instead of L3 interfaces.

Then you either use statics or run a dynamic routing protocol on that P2P link.

The key thing is not to allow any vlans that are routed locally on the site switch across the trunk link.

And any vlans you extend between sites only has an SVI on the core switch not on any of the site switches.

Jon

[snared04drummer]

Perhaps I just explained it poorly, but what you described is, in effect, what they were wanting to do.

However, how do you reconcile the fact that the server attached to the core in this design has its default gateway on a remote switch?  

Is there a way to use L2TPv3 or a similar approach to make this work?

[Jon Marshall]

However, how do you reconcile the fact that the server attached to the core in this design has its default gateway on a remote switch?  

I would put the SVI for vlan 211 on the core switch not the site switch.

Makes no sense to put it on the site switch as far as I can see and you don't gain anything by it.

Joe has covered L2TPv3 and possibly MPLS but it really isn't worth the trouble even if your switches supported it which they may not.

Jon

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

The idea is that, yes, some vlans/subnets need to exist across multiple sites.

Some or just one?

I.e. a phone system where the server, which is located at the core, needs to be on the same subnet as all of the phones that it services.  I understand that in practice, most applications wouldn't need a network configuration to exist in this way, but we've been given this requirement for the design.

Oh my, 2015 and there's still apps like this?

If you have just one VLAN that needs to be extended all over, you can extend it on access ports between L3 switches.  This VLAN would also serve as the transit between SVI interfaces, defined at each remote site.  Other SVIs, per site, would host VLANs only known to that site.  You could, if desired, reuse VLAN numbers between sites, because those other VLANs won't be on trunks.  The advantage of this approach, you only have one "ugly" VLAN and you don't need to manage pruning.

If you have multiple VLAN/subnets you need to extend between sites, then you extend those VLAN where necessary, using trunks, and manage what's allowed on your trunks.  Where possible, you keep VLAN/subnets as local as possible, and route between L3 devices.  You can dedicate a special p2p transit VLAN, between L3 devices, or just route across one (or more) VLANs between L3 devices.

Is there a way to use L2TPv3 or a similar approach to make this work?

"Routine" L3 switched might not support, but even if they do, like other tunneling protocols, L2TPv3 overhead might cause packet fragmentation.  VLANs, on L3 switches, would be much more efficient.  I also don't see L2TPv3 offering much unless you wanted to bypass L2 across transits.

MPLS would be another option, but extending L2 would be somewhat like using L2TPv3, although MPLS adds to the packet, so fragmentation shouldn't be a concern.  It's also likely to be efficiently implemented on devices that support it, which might not be true for L2TPv3.

As I have noted on the drawing, this would literally put the default gateway of the server on a remote top switch, which leads me to believe that this is bad design practice.

You can have the gateway anywhere, physically, but since you have an extended L2 domain, you're just going to have frames/packets often transit multiple devices even if their L3 destination is on the same L3 switch.  This is why, traditionally, we like to route across WANs, and on modern L3 switches, it can be practical to even route on the same device.