Okay so I showed the topology of a hospital network. But what's the thought process that goes into that? Well let's kind of walk through it in detail, so we can understand each of the steps. So suppose we wanted to design a hospital network. Suppose we have two different hospitals, we're part of a hospital system, we have two different hospitals, two different sites. There's bunch of things we want to do. How do we do that? Well let's start drying it out. So suppose you have two different sites. Each of these is a separate hospital. At each of these hospitals, you want each of them to connect up to the public internet. They're different geographic locations ,so they're going to connect to different ISPs. Then those ISPs are going to provide internet services. Now each of these sites we have a set of devices. So we have a bunch of voice devices. So we have a bunch of places where there's telephones, users can pick up the telephone and make phone calls to each other. There's public address systems where there can be announcements of different codes. There's a bunch of headsets. So this is going to be a voice network. It's going to spin the two sites. So voice network on one side should alter or raise the voice network on the other side. There's also going to be a set of security devices. Cameras are going to watch people leaving and entering the facility. There's going to be automatic door locks, and we're going to monitor where people are located and things like that. This information is going to be stored on a set of servers. So video feeds and things like that are going to be viewable and you can review them at different times. They're going to go up in the cloud and so on. There's also going to be a HIPAA network where there's a set of medical terminals and a bunch of places where you can access and store patient information. So these are the goals of what we want. Now, how can we design a network to fulfill these goals? Well let's start at the top. So we have Internet connectivity. So the internet is going to be a layer of three connection, usually. So we need something like a router. We need a router to be able to connect to the internet. If we want redundancy, we're going to have multiple routers, just in case one of the routers fails. For added redundancy, we can have two routers. Each of these routers can have a separate link to the Internet. Now these two routers could connect to the same router in the ISP. For added redundancy, it could connect to two different routers at that ISP, in case one of the ISP's routers fails. If we wanted even more reliability, these routers could connect to another ISP as well. So this gives us a lot of additional redundancy. We are a hospital, we want to have solid internet connections. Maybe we're storing important information in the Cloud. So one way to achieve redundancy is have multiple layers of redundant links, multiple routers in case one of ours fails and then multiple links going up to the parent ISPs. Beneath these routers for a wide-area network, we're going to have another layer beneath that protects our network. This is going to be a NAT firewall layer. So the reason we're doing that here is maybe to save IP addresses. But NAT gives you a security advantage too, because it makes your internal devices are not externally addressable. If you use a private address space, you can guarantee in some sense that no one externally can send IP packet to one of your internal devices. That's what NAT does. So that hides your internal devices. If you communicate externally, you get a pseudonym, you get another IP address that the device sees externally and that it can be rebuffed later to hide your internal device. So that is what NAT does. It's typically common to put firewall at this layer too. You do this beneath your routers. You do this beneath your routers because your routers deal with a lot of traffic and your routers can do some initial filtering there to protect your firewalls from getting overloaded. So with your firewalls, you can put access controls and various things like that. Now what's common to do is to actually have multiple layers of firewalls. So what you do is, you have one kind of layer of NAT in and firewalling and kind of general protections. For those you put in high-speed firewalls. You put it in devices that do firewalling and hardware. Things that can keep up with really high rates of speed if you're being denial-of-service attacks and so on. What those do is, those acts as a shield for your next layer of firewalls. That's where you do things like Intrusion detection and intrusion prevention because there you're looking deep inside packets. You often have to do this in software because it's hard to do general text processing in hardware. You're going to have two layers of firewalling. Then beneath that, you're going to have your switching infrastructure. The switching infrastructure is all about taking data and getting it out inside your network as used for transport. So it's common to have multiple layers of switches, because you don't want huge numbers of connections hanging off your firewalls. Firewalls aren't built for that, switches are. So you want to have your core switches, your distribution switches, your access switches, multiple layers that gradually fan out your traffic into lower and lower bandwidth connections and then reach the individual devices. This is where you get into individual wiring closets on each floor, you're running cables out and so on, and those connect to the individual devices. So this is what we're going to do at site 1. You're probably going to do the same thing as site 2. This is good for transparency. You can have your network operators share information back and forth. It's good to reuse device types and reuse connections and things like that. You may intentionally use different device types. If you want to have added redundancy, you might use some Cisco and some F5 and things like that. But in general, it's good practice to use individual vendors because you can build your scripts to that vendor if you're able to. So there's these individual devices that are now connected. We have these individual sites. But we're not done yet. All we've done is we've established connections. We can't actually route yet. We haven't created any routing tables or phony tables or rules or anything like that. Part of that process can be done for us. So these border routers, these WAN routers at the top, those might be BGP or some protocol to collect routes from the internet. Your ISP providers may advertise routes down to you, or you may configure them to be default routes. So you may configure default routes in them and just say, "Okay, any packets that I don't know how to deal with, I just forward that to my ISP." What you're probably going to do is you're probably going to four different traffics in different directions. You may have individual routes configured and, then maybe a default route on top of that into WAN routers. So you're going to set that up, Now another thing we need to do is fill in the core. So we're running ethernet down at the lower layer, so that's going to set up default connectivity between devices. But that's not what we want. We don't want all devices to be able to reach all other devices, we want to take our Vlans and our VRFs and our different segments and instantiate them on these networks to prevent them from talking together too much. This is where network design comes into play. There's a lot of different ways to do this. One way that's smart is to do this with a layered approach. So here's one thing we can do. What we can do is we can go into our switches. What we're going to do is we're going to configure our switches to put different ports on different Vlans. So the switch is going to say, okay, this is a voice unit that's attached to me at this port. This is a security unit that's attached to this port. So if I get packets from the security devices it's going on the security. Vlan, if I get packets from the voice devices it's going on the Voice Vlan." So this is the first thing you're going to do. You're going to do port configuration, and you're going to turn on port security on the ports to indicate which MAC addresses are allowed to connect, because you're going to know, okay this is connected to an IP camera, and I know the MAC address of that. So if someone walks over and unplugs the IP camera and plugs in their own network sniffer, you want to disable that because that's a different mac address. You're going to turn on features like that at these individual ports. One thing that's a neat trick is to embed Vlan information in your addressing. So oftentimes, you'll have a lot of flexibility about what addresses to use when you configure networks or if you're using private address space. So if you are using private address space, you might as well use 10/8. Use a really huge prefix for your network because it's all private anyway. So you can see what I'm doing here, is I'm configuring these Vlans. So Vlan 3 at switch 1 is going to be put on 10.1. 3.0/24, whereas Vlan 8 is going to be 10.1.8.0/24. So what I'm doing here is I'm using the second octet of IP address as the switch number, and the third octet as the Vlan number. I don't have to do this. I can just create these Vlans and give arbitrary prefixes to each Vlan. But one reason this is going to be smart is because, when these Vlans are constructed creating access controls, access controls get super easy to create because access controls are defined on IP addresses, and if information about the switch in the Vlan is encoded in the IP addresses, then I can just use wildcards. We'll see how that works in a bit. But let's suppose I keep doing that. I'm going go to this switch and I'm going to configure the voice Vlan and the security Vlan and this switch, I'm going to configure different Vlans there. Then these individual Vlans are going to be configured and then these Vlans are going to be created and they're going to be switched over ethernet. That'll get us up to the Core layer three switches. Now, layer 3 switches, they don't do Vlans. They connect to Vlans, so we can define Vlans on those interfaces and we can say, okay these are trunk pores that point down towards access switches. We can do that. But these individual switches don't switch based on Vlans because they're layer 3. So at layer three we're going to define VRFs. VRFs are like layer 3 Vlans. So at these layer three switches, we're going to define the voice Vlan, security Vlan, the HIPAA Vlan and so on. They're connected out to these individual switches. So packets are going to come from the devices, they're going to be switched onto the Vlan, corresponding to the device type. Then they're going to go up and they're going to hit the layer 3 switch and they're going to be mapped to the VRF associated with that Vlan and then they're going to keep going up. This is where we reach the firewall layer. So good practice is you define all your firewall rules in one part of your network. You could go out to these individual switches and put firewall rules at each of these individual switches, then you have to keep them all up to date, you have to keep them coordinated, they may be be managed by different people and different teams. What's common in enterprises is to have a networking team and a separate security team. So you want to give your security team one point of entry to your firewall rules and have them at one layer and, that's good practice for those environments. It's good practice in general to have all your rules at one place. So by virtualizing things and bringing everything together to your firewalling, you can define all your policies at that one layer. So what we're going to do at this layer, is we're going to define all our rules. We're going to say which devices can reach which other devices, which Vlans can reach each other and which Vlans can reach out into the public internet. If you define your rules in terms of these IP addresses, so if you define your IP address ranges in terms of the Vlans or the switch numbers, you actually have a lot of control. If you look at the access controls they're putting in here, you can see it gets really easy because you can just wildcard the other fields. So if I want to make it so everything from switch 1 can reach the public internet, then I wildcard everything except for the second octet. If I want to say everything from Vlan 1 can reach site 2, then I wildcard everything except for the third octet and so on. So at a high level, I hope you can see that, what we're trying to do is we're trying to define these Vlans and we're creating these different segments. We really want to keep them separate. There are certain points where segments have to overlap and merge. They might all have to talk to public Internet. You might want certain segments to reach each other and so on. The way we do that is through firewall rules and you have to be really careful about your firewall rules, and you want to put them at just certain places in your network. So this is a good network design principle.
