Saturday, February 9, 2019

Campus network restructuring, some advices?

Hi guys,

We are trying to face a network migration and I'd like to get some advices or ideas from other members of this community.

First of all, I know is 2019 and there are new technologies that could solve my problems but, as usual, there are some "bussiness needs" to fullfil:

1) Re-use as much as you can current network hardware (limited budged)

2) Make the network more stable

3) Permissions based on network client roles within the enterprise

4) Flexibility to support new requeriments (for example, new roles)

Second, some technical details to give you some background about the current state of the wired network:

  • Campus of 20 buildings all connected with fiber

  • All HP switches forming a 3-tier network

    • 2 x switches Layer 3 at Core (CORE)
    • 2 x switches Layer 3 on each Aggregation/Distribution (AGG)
    • n x switches Layer 2 at Access (ACC)
  • We are using HP IRF (sort of stacking) in CORE and AGG

  • All ACC switches are dual-homed to AGG switches

  • All AGG switches are dual-homed to CORE switches

  • Layer 2 from ACC to CORE

  • CORE holds all VLAN interfaces

Third, due to different reasons, and as you may expect from a L2 "flat" network, we are experiencing network loops and broadcast storms. Also, network access is uncontrolled with no security in mind. So the idea is propose to management a couple of alternatives that could solve or, at least, minimize these issues.

Said that, here you have a couple of ideas I have in my mind to start off:

  • Move layer 2 boundary from CORE to AGG

    • Convert CORE-AGG to routed ports
    • Create VLAN interfaces on each AGG
  • Re-address the network maintaining an ordered IP addressing scheme (summarizing each AGG)

  • Routing would be OSPF

So far, we are fulfilling requirements number 1 (no new hardware is required) and number 2 (loops and broadcast contained to the building, not perfection but better than nothing).

My problems begin with client roles :(. To keep it simple, we are thinking about the following:

  • 3 types of users with different permissions:
    • CORP: normal corporate user, full access
    • PARTNER: bussiness partners living amongs us, restricted access
    • GUEST: no internal access, just internet
  • We have some use cases for DMZ-style subnets in buildings, examples:
    • Servers/Devices reacheable from the internet, video conferencing devices, etc.
    • We called this role simply "DMZ"
    • Permissions should be: permit LAN->DMZ, deny DMZ->LAN, permit DMZ->INET and open only some ports for INET->DMZ
  • A subnet providing tight control to allow hosts to comunicate with only certain servers, example:
    • Printers (talk only to print servers), IP cameras (talk only to DVRs), others
    • somewhat static permissions, just minor changes required from time to time
    • We called this role "SERVICES"
  • A VOICE subnet for IP phones (full access, no problem)
  • Finally, we have our network-management subnet (MGMT) (full access, no problem)

So, every building should have a VLAN and subnet for each of these roles.

Well, let's talk how to deal with role permissions.

For GUEST and SERVICES we are thinking in using ACL, that is, one ACL in the interface VLAN GUEST (deny all RFC1918 addresses) and another ACL in the interface VLAN SERVICES. Let's say we feel confortable with this solution (is not elegant at all, I know).

On the other side, how would you solve DMZ and PARTNER permissions?

Key points to consider before answering:

  • Hardware is not MPLS capable (I wish it was :( such a pity)

  • VRF-Lite is a possibility but links between CORE-AGG should be layer 2 (no support for subinterfaces) and I don't like the idea (we are trying to avoid layer 2 as much as possible, right?)

  • Hardware is not even capable of doing GRE tunnels "to glue" those subnets with a centralized firewall (too bad again)

  • ACL are stateless packet filters incapable to fullfill DMZ and PARTNER policies

  • Adding one firewall per building is not feasable (nor a good idea from my perspective) mainly due to budge constrains

That's all, I'm sorry to made this text so extensive but I wanted to bring you the whole picture.

Thanks in advance for your help. Regards.



No comments:

Post a Comment