Review of network connectivity diagram

Question

Greeting's, this is my first attempt at network connectivity and hence would truly appreciate if community at large can review and guide me through it.

We have one main office with 7 branch offices. We don't plan to expand over 12-15 branch offices (even if we do, I feel my following assumptions and design should stand).

We plan to have P2P VPN lines between offices. I have proposed that we use 172.16/12 subnet. With 172.16.x.x for HQ and 172.17.x.x and so on for each branch. We will never have over 500 PC's per branch.

There are as of now 6 departments and I have proposed 172.16.1.x and so on for each department which will stay consistent over the branches.

We have (for whatever) reason L3 switches all around and each switch may hold computers of 2 or more departments. Hence to segregate I've proposed VLANs which will be (VLAN IDs) consistent between switches (I am unsure of this part). Hence, if sales computers are in VLAN2 on switch 2. Other switches (switch 3 for example) will have VLAN2 holding subnet and PC dedicated to sales. I've attached a diagram for better explanation. I want to know if it's possible for inter VLAN communication based on the diagram I've attached and of course the changes recommend based on our needs.

I am certain of having made mistakes with trunking. Please do guide me through it. Will the firewall be able to see IP's of endpoint with trunking on uplinks and L3 switch. Also all the switches in the diagram are L3

Thanking you all in anticipation!

Edit:

My requirements are for L3VPN as per one of the answers. Thank you again. Just to confirm and reiterate since this is critical and my job hangs on getting it right - As someone suggested - I am planning to shift to 10/8 subnet for better expendability. Hence: 1. HQ will have 10.1.0.0 subnet

2. Branches will start with 10.2.0.0 series.

3. There will be further subdivision of IP ranges using VLANs per department. This will be consistent throughout the organization A. Sales will be allocated 10.1.1.0 in HQ. B. 10.2.1.0 in branch 1 and 10.3.1.0 in branch 3 – so on and so forth. Network device topology will remain consistency throughout branches:

4. ISP CPE - Firewall - L3 Core swtich - L3 (working in L2 mode) switches - Endpoints. Physical topology between branches will be -
5. Endpoints - L2 Switches - L3 Core switch - firewall - ISP CPE - L3VPN - ISP CPE - Firewall - L3 Core swtich - L3 (working in L2 mode) switches - Endpoints. Topology with IP addresses for illustration will be: Endpoints (10.1.1.5) - L2 Switches (10.1.5.2) - L3 Core switch (10.1.1.1) - firewall (10.1.1.250 - question - should this be on same subnet or is it better to have firewall IP as 10.1.0.250) - ISP CPE - L3VPN - ISP CPE - Firewall (10.2.1.250) - L3 Core swtich (10.2.1.1)- L3 (working in L2 mode) switches (10.1.5.2) - Endpoints (10.2.1.5)

Questions: 1. Is this optimum with respect to security (VLAN segregation for each departments), manageability, bandwidth (broadcast domains and compromised endpoint quarantine)? 2. Will a machine on different VLAN and IP subnet (10.1.2.5) communicate with machine at HQ (10.1.1.5) and with 10.2.2.5 (at branch)? I reckon that within the same office (HQ/Branch) machines won't communicate. However, they will between branches of same department (10.1.1.5 with 10.2.1.5).

Thank you very very much to everyone who has reviewed and assisted me with this.

Second diagram

Answer 1

There are many ways to do this. Here are a few observations:

• It's generally a good idea to push layer 3 as close to the end users as possible. Since you have layer 3 switches everywhere, this is easy for you to do.
• You should consider creating a routing hierarchy, with the branch switch terminating the local VLANs, and the core switch terminating the branch links.
• While it's fine to put each department on a separate VLAN, unless you plan to restrict access between departments, there's no real value.
• It's more important to insure that there are no layer 2 links connecting your branch offices. Everything should be L3. I don't see a need to use trunking anywhere.
• Place your servers on their own VLAN for design consistency and also since that's the most likely place to enforce policy.

Answer 2

So here are a few points I would suggest:

• Create virtual interface of each VLAN on the firewall itself, and use it as gateway for each host in the VLAN.
• Try to get redundancy on the core switch, If stacking available please choose that.
• Use different VLAN for servers and again put its virtual interface on firewall itself(use that interface IP as gateway for servers), In this way you will have a DMZ for servers.
• Have a switch placed in the servers area as well, Do not connect them directly to the core switch.

We will never have over 500 PC's per branch.

• never is a very strong word(avoid it) companies grow, networks grow. You never know when you will need new hardware for growing user base.
• You will have to trunk the ports between switches({department and core} and {server switch and core}) and also between the L3 core and firewall.
• Ports connected to hosts/servers are to be put in access vlan mode unless needed otherwise.
• Yes inter-vlan traffic will go through firewall(you can apply policies what to allow and what not) in this topology.
• Yes firewall will be directly able to see MACs of end hosts in this topology.

UPDATE You can also have L3 as the gateway of each VLAN rather than firewall, I am writing some cons and pros of having firewall as gateway(and vice versa):

Cons

• Each host arp will come to firewall, you will have to see arp-cache size on firewall.
• For inter-vlan routing you have to make policy on firewall(blessing in disguise).
• SLAAC might not be available for IPv6 in firewall.
• If firewall goes down, Inter-vlan traffic will also stop.

Pros

• Lesser configuration overhead.

• You can have DMZs configured(allow/disallow different traffic from internet/intranet).

• More control over inter-vlan traffic.

• Switching faster than routing, Packets will be switched to firewall.

• Firewall will see all the hosts.

UPDATE 2(after question was updated):

Your diagram shows something else(than what you have explained). Anyways.

From Diagram: Do not use the management IP of switches from same VLAN as that clients! Use a separate network.

L2 Switches (10.1.5.2)

L2 switches at both ends have same management IP, don't do that. Assign different management IP range(I take this is a typo).

firewall (10.1.1.250 - question - should this be on same subnet or is it better to have firewall IP as 10.1.0.250)

Do not use the same network, its of no use. Use a point to point network(a /30) between L3 and firewall, Since in any case gateway of your VLANs will be the L3 so why complicate things(if you are going to use this topology i.e.)

1. Is this optimum with respect to security (VLAN segregation for each departments), manageability, bandwidth (broadcast domains and compromised endpoint quarantine)?

Yes seems like so till now(will update if something comes in my mind).

2. Will a machine on different VLAN and IP subnet (10.1.2.5) communicate with machine at HQ (10.1.1.5) and with 10.2.2.5 (at branch)?

As you said you are using L3VPN(routes are advertised via bgp mostly from one end router to another), So for example 10.1.0.0/8 from HQ is advertised to all the other branches via L3VPN and 10.2.0.0/8 from a branch to HQ, they will be able to communicate. So in essence, depending on how much routes your ISP lets you advertise. You can achieve this easily if the HQ office has routes of branch office and vice versa.

I reckon that within the same office (HQ/Branch) machines won't communicate. However, they will between branches of same department (10.1.1.5 with 10.2.1.5).

Is this something you think, or something you want. Because this won't happen by default. Its rather reverse of what you think(presuming) The local VLANs will be able to talk via inter-vlan(via L3) routing(since you have configured GWs of each VLAN on L3 itself). Also for different offices(HQ/branch) departments to talk you will need L3VPN routes transported(as explained above, job of ISP), though you can also achieve this with NAT(config overhead).

Hope this helps!