3

I'm in need of some advice regarding the implementation of the network core layer of a network I need to design. I've found some similar questions asked (and answered) already, but none have really given me a clear answer - though there might be no clear definitive answer either.

Design

Internet <--> Fortigate <--4x1G--> Core <--2x10G--> Access Switches

  • The current network design consists of a firewall (Fortigate 100D), a pair of stacked "network core" L3 switches (Netgear M4300) configured for redundancy and then an access layer of switches (Spine and Leaf off the core) for end-user devices.
  • Switches are connected over 10G LAG's.
  • The network utilises 6-8 VLANs.
  • Only 2-3 of these VLAN's require inter-VLAN routing between each other/to the internet.
  • There are usually around ~200 devices on the network at any one time during peak load.

Issue

My issue is in deciding whether to use the "core" switches OR the Fortigate firewall as the default gateway/L3 switch in the network. As far as my research has revealed, using the "core" for this purpose (Option A) has the benefit of line-rate routing while loosing the L7/IPS/other fancy features, requiring the use of ACL's instead; whereas using the Fortigate (Option B) essentially reverses those pros/cons.

So my questions are as follows:

  1. If implementing Option B, trunking the VLAN's that require routing (over a 4x1G LAG) to the Fortigate; is the loss of line-rate routing really that big of a deal in terms of performance loss?
  2. As far as I understand, if traffic was destined for a device within the same VLAN (as the source) and didn't need to cross to a different VLAN or Subnet, the packets won't pass through the default gateway/L3 switch; is this correct?
  3. Functionality/Practicality aside, which option would be considered best practice in terms of both security and performance?
  4. Sort of unrelated - If I needed to use the Fortigate as a VPN gateway to allow remote connections into the network, what is the best practice for facilitating this if deploying Option A? Do I just create a seperate physical connection back from the Fortigate into the core and assign VPN traffic to it?

Thanks for taking the time to help, it is very much appreciated. :)

Kind Regards


Update

The VLAN contents are as follows:

  1. [Routed] Corporate VLAN: Workstations, Printers, Servers, etc. (The majority of devices are here)
  2. [Routed] Wireless VLAN
  3. [Routed] Production VLAN (Media servers, streaming devices, etc.)
  4. PBX VLAN (40-50 Digital phones)
  5. Finance/Legal VLAN (NAS, Finance workstation)
  6. DMZ VLAN (Web servers)
  7. Studio VLAN (High-bandwidth 4K video editing on 10G links)
  8. [Option A] VLAN to Firewall/Internet

The primary need for L3 routing is of course access to the internet. However I do want some inter-connectivity between the first three VLAN's listed above.

While I don't necessarily need L7/IPS features on inter-VLAN routing, the Fortigate allows control of L3 routing using user-based rules (Radius, LDAP, Local Auth, etc.) which is appealing. For example, I can use LDAP groups to allow specific users to access portions of another VLAN, while denying other users - So let's say if you connect wirelessly onto the Wireless VLAN and authenticate with the Fortigate, your device can now access portions of the Corporate VLAN.

Mainly the primary question I'm looking for a solid answer to is the realistic benefit of line-rate routing over CPU-bound routing (Question 1) and confirming my assumption about non-L3 bound traffic (Question 2).

3
  • What's on the 6-8 VLANs and where are servers/PBX etc? The principal traffic routes will help answer the question.
    – jonathanjo
    Commented Nov 14, 2017 at 15:06
  • Is there are reason that you need to use layer-7 inspection between internal VLANs? We simply don't know enough about your network and how it is used to give a useful answer to your question.
    – Ron Maupin
    Commented Nov 14, 2017 at 15:09
  • Added some additional information. Commented Nov 14, 2017 at 15:23

4 Answers 4

1

There is no clear objective answer to your problem. Here are specific answers to your questions:

  1. If implementing Option B, trunking the VLAN's that require routing (over a 4x1G LAG) to the Fortigate; is the loss of line-rate routing really that big of a deal in terms of performance loss?

This is difficult to answer objectively. Only you can determine how big a deal it is.

  1. As far as I understand, if traffic was destined for a device within the same VLAN (as the source) and didn't need to cross to a different VLAN or Subnet, the packets won't pass through the default gateway/L3 switch; is this correct?

Correct.

  1. Functionality/Practicality aside, which option would be considered best practice in terms of both security and performance?

It's a trade-off between security and performance. There is no "best practice." Eveyone's requirements are different.

  1. Sort of unrelated - If I needed to use the Fortigate as a VPN gateway to allow remote connections into the network, what is the best practice for facilitating this if deploying Option A? Do I just create a seperate physical connection back from the Fortigate into the core and assign VPN traffic to it?

You can, or you can create multiple VPN groups (according to your security requirements) and adjust your ACLs to allow appropriate access for each group.

1

They are just general-principles comments, but perhaps it helps you:

I tend to value simplicity very highly. I'd consider splitting the machines into VLANs according to their access permission, probably splitting off servers into two or three VLANs depending on who is allowed access (eg LEGALSERVERS, GENSERVERS, PUBLICWEB) ... then access is per-VLAN not part-of-VLAN.

The video content makes me think you're better off using the L3 switches for inter-VLAN routing.

I like a physical wire (or two) to outside world which I can pull easily. (With guest wifi, if you have it). Switch-cluster of inside, a single (pair) or wires to firewall, then links to world.

VLAN 6 DMZ has workstations on it?

Hope that's of some use.

2
  • Thanks for the reply. Maybe this is a rephrase of one of my questions, but considering (for example) the Studio VLAN isn’t routed (has no access to the internet/other VLANs) and is only for data transfers between the editing computers and a NAS (all on that same VLAN) - the traffic wouldn’t go through the fortigate if the fortigate was the default gateway correct? Commented Nov 14, 2017 at 16:28
  • That's correct, that's just within-vlan traffic.
    – jonathanjo
    Commented Nov 14, 2017 at 21:02
0

I've know this design as a collapsed or compressed core. The core and distribution layer are in a sense one. In most cases I've seen the collapsed core does routing. If you read standards they say to limit routing to the distribution or even access layer but your situation is not a standard three layer design. Designs can be like opinions in that everyone has one. I personally route at the core on a collapsed core design.

0

Q1: wirespeed routing. When a device routes traffic it exchanges the destination address in each and every packet that is to be routed, i.e. which has a destination outside it's broadcast domain. In your case traffic will be limited to 4 Gbps, probably less as the FG-100D is not built for higher loads. Whether this is acceptable is your decision.

Q2: each VLAN forms a broadcast domain. This is the main advantage of using VLANs (IMHO), to isolate broadcasts - not to enforce security. For intra-VLAN traffic the router will not be contacted. Each workstation/sender uses it's network address, the network mask and the destination address to determine if the packet has to be sent to the router or if the destination can be found locally. In this case the hardware address is found via arp broadcast; the router will not participate in the transmission.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.