Monday, November 11, 2013

JNCIA Lesson 5 -- VLANs

Up to this point, there has been an "elephant in the room" that we've carefully been sidestepping around. So far, many of our configs have referenced VLANs and Juniper's related -- but significantly different -- concept of "units." Today, we'll dig into VLANs and try to figure out exactly what they are and how to use them. We'll start with a common problem in networking that will hopefully illustrate the use and power of VLANs, then implement a solution for this problem in JunOS.

Suppose you have built a data network for your organization using standard Layer-2-only switches. Shortly afterwards, your internal PBX catastrophically fails beyond any hope of recovery. You decide that continuing to use antiquated POTS telephony is a poor idea, and instead, decide to implement an Asterisk open-source, voice-over-IP (VoIP) PBX system instead. Having done your homework, you are well aware of the common pitfalls associated with VoIP services -- such as Quality of Service (QoS), latency and jitter -- and therefore, you want to roll out the PBX on an entirely new network to minimize contention with other network consumers. However, it seems wasteful to buy additional switches for your enterprise, when you've already got unused ports on the switches you already have in use.

If only there were some way to logically separate the switch ports into separate networks, so that data users would only be in contention with each other for bandwidth while VoIP users could be on their own low-latency network...

Fortunately, this is exactly what VLANs were created to do. VLANs are a logical separation of two (or more) networks using the physical hardware of only one network. Remember when you were a kid and had to share a bedroom with brother or sister? Did you ever get into a fight with your sibling, and draw a line down the middle of the room, declaring something to the effect of, "This is my half of the room, and that is your half. Keep out of my half of the room!" That's basically all a VLAN does -- it splits the switch into separate broadcast domains so that traffic on one virtual LAN (VLAN) does not interact with traffic from other VLANs.

There are two ways for this split to occur, and typically, both methods will be used. First, you can separate the VLANs by port -- ports 1, 5, and 18-24 all belong to VLAN 10, while the remaining ports belong to VLAN 20, for example -- or you can separate traffic into separate VLANs by adding a tag into the Ethernet frame to mark certain frames as belonging to one VLAN and other frames as belonging to another VLAN. Each frame can belong to one and only one VLAN; there is no way to define a frame as belonging to multiple VLANs. Generally speaking, if the port will be connected to a client device -- a desktop, laptop, VoIP telephone, etc. -- you will define the VLAN by port, what is often referred to as an "untagged" or "access" VLAN port. On the other hand, if the port will be used to connect another network device, such as another switch or a router or sometimes even a server -- in other words, any time you potentially want more than one VLAN to transit an Ethernet link -- you will "tag" the frames coming from that port, creating a "tagged" or "trunk" port.

Let's take the example of the VoIP network and look at how we would implement such a design on the EX3200 switches. We've decided to use ports 0-7 on each EX3200 switch for the VoIP service because these ports support Power over Ethernet (PoE), which we can use to power the VoIP telephones (we'll just accept that statement as-is for the time being, as a full discussion of PoE is beyond the scope of this discussion). Additionally, we'll need a port for the Asterisk server, so we will add ge-0/0/8 to the VoIP VLAN, as well. We'll start the configuration by defining the Voice over IP VLAN on the switches:

root@main3200# edit vlans

[edit vlans]
root@main3200# set voip vlan-id 20

[edit vlans]
root@main3200#


Next, we need to define the VLAN interface:

root@main3200# top edit interfaces

[edit interfaces]
root@main3200# set vlan unit 20

[edit interfaces]
root@main3200#


If we wanted this VLAN to be routed, this is where we would add a Layer-3 address to the VLAN interface. Since we have three offices connected over a Layer-3 network, let's go ahead and add the IP address 192.168.10.1/24 to the main3200 router:

root@main3200# delete vlan unit 20 family ethernet-switching

[edit interfaces]
root@main3200# set vlan unit 20 family inet address 192.168.10.1/24

[edit interfaces]
root@main3200#


Now that we have defined the VLANs and the virtual interfaces through which the EX3200 will communicate, we'll need to assign these VLANs to the Gigabit Ethernet ports on the switch. The default VLAN is assigned to each switchport by, well, default. Therefore, we'll only need to add VLAN 20 the Ethernet ports that are used by the VoIP phones and PBX. We've already decided to put ge-0/0/0 through ge-0/0/8 into the VoIP VLAN, so let's make it so:

root@main3200# top

[edit]
root@main3200# set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members voip

[edit]
root@main3200# set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members voip

[edit]
root@main3200# set interfaces ge-0/0/2 unit 0 family ethernet-switching vlan members voips

[edit]
root@main3200# set interfaces ge-0/0/3 unit 0 family ethernet-switching vlan members voip

[edit]
root@main3200# set interfaces ge-0/0/4 unit 0 family ethernet-switching vlan members voip

[edit]
root@main3200# set interfaces ge-0/0/5 unit 0 family ethernet-switching vlan members voip

[edit]
root@main3200# set interfaces ge-0/0/6 unit 0 family ethernet-switching vlan members voip

[edit]
root@main3200# set interfaces ge-0/0/7 unit 0 family ethernet-switching vlan members voip

[edit]
root@main3200# set interfaces ge-0/0/8 unit 0 family ethernet-switching vlan members voip

[edit]
root@main3200# commit
commit complete

[edit]
root@main3200#


We now have nine Ethernet ports, ge-0/0/0 through ge-0/0/8 in the "voip" VLAN (VLAN 20). You hook up Linux hosts to two of the ports, connect a third Linux host to ge-0/0/10 (in the "default" VLAN), configure all of their IP addresses to all be in the 192.168.1.0/24 subnet, and start testing. As expected, hosts on ge-0/0/0 through ge-0/0/8 can talk to each other, but the host on ge-0/0/10 cannot reach either of the other two hosts, since it is in a different VLAN:

root@ge-0-0-2:/root# ping 192.168.1.238
PING 192.168.1.238 (192.168.1.238) 56(84) bytes of data.
64 bytes from 192.168.1.238: icmp_seq=1 ttl=64 time=0.436 ms
64 bytes from 192.168.1.238: icmp_seq=2 ttl=64 time=0.241 ms
64 bytes from 192.168.1.238: icmp_seq=3 ttl=64 time=0.234 ms
64 bytes from 192.168.1.238: icmp_seq=4 ttl=64 time=0.212 ms

--- 192.168.1.238 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.212/0.280/0.436/0.092 ms
root@ge-0-0-2:/root#
...
root@ge-0-0-10:~# nmap -sP 192.168.1.0/24

Starting Nmap 6.00 ( http://nmap.org ) at 2013-10-25 11:09 AKDT
Nmap scan report for 192.168.1.134
Host is up.
Nmap done: 256 IP addresses (1 host up) scanned in 11.12 seconds
root@ge-0-0-10:~# ip addr | egrep eth0 | egrep inet
inet 192.168.1.134/24 brd 192.168.1.255 scope global eth0
root@ge-0-0-10:~#
...
root@ge-0-0-6:~# ping -c4 192.168.1.134
PING 192.168.1.134 (192.168.1.134) 56(84) bytes of data.
From 192.168.1.238 icmp_seq=1 Destination Host Unreachable
From 192.168.1.238 icmp_seq=2 Destination Host Unreachable
From 192.168.1.238 icmp_seq=3 Destination Host Unreachable
From 192.168.1.238 icmp_seq=4 Destination Host Unreachable

--- 192.168.1.134 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3014ms
root@ge-0-0-6:~# ping -c4 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=1.96 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=0.176 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=0.164 ms
64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=0.165 ms

--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 0.164/0.617/1.965/0.778 ms
root@ge-0-0-6:~#


Perfect! Now, let's see if we can get ge-0/0/23 configured to do 802.1q tagging so we can use it as an uplink port from the second switch in the Main Office LAN:

root@main3200# edit interfaces ge-0/0/23 unit 0 family ethernet-switching

[edit interfaces ge-0/0/23 unit 0 family ethernet-switching]
root@main3200# set port-mode trunk

[edit interfaces ge-0/0/23 unit 0 family ethernet-switching]
root@main3200# set vlan members 20

[edit interfaces ge-0/0/23 unit 0 family ethernet-switching]
root@main3200# set native-vlan-id default

[edit interfaces ge-0/0/2 unit 0 family ethernet-switching]
root@main3200# commit
commit complete

[edit interfaces ge-0/0/2 unit 0 family ethernet-switching]
root@main3200#


Now, connect a cross-over cable between the two switches, and connect two hosts to each switch, one host (per switch) on ge-0/0/2 and one host (per switch) on ge-0/0/10. First we'll try pinging from a PC in the default VLAN on the first switch (main3200, ge-0/0/10) to all three other hosts:

root@mo-ge-0-0-10# ping -c4 mo2-ge-0-0-10.example.com
PING mo2-ge-0-0-10.example.com (192.168.1.134) 56(84) bytes of data.
64 bytes from 192.168.1.134: icmp_seq=1 ttl=64 time=0.590 ms
64 bytes from 192.168.1.134: icmp_seq=2 ttl=64 time=0.383 ms
64 bytes from 192.168.1.134: icmp_seq=3 ttl=64 time=0.363 ms
64 bytes from 192.168.1.134: icmp_seq=4 ttl=64 time=0.392 ms

--- mo2-ge-0-0-10.example.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.363/0.432/0.590/0.091 ms
root@mo-ge-0-0-10/root# ping -c4 mo-ge-0-0-2.example.com
PING mo-ge-0-0-2.example.com (192.168.1.17) 56(84) bytes of data.
From 192.168.1.250 icmp_seq=1 Destination Host Unreachable
From 192.168.1.250 icmp_seq=2 Destination Host Unreachable
From 192.168.1.250 icmp_seq=3 Destination Host Unreachable
From 192.168.1.250 icmp_seq=4 Destination Host Unreachable

--- mo-ge-0-0-2.example.com ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 2999ms, pipe 3
root@mo-ge-0-0-10:/root# ping -c4 mo2-ge-0-0-2.example.com
PING mo2-ge-0-0-2.example.com (192.168.1.129) 56(84) bytes of data.
From 192.168.1.250 icmp_seq=1 Destination Host Unreachable
From 192.168.1.250 icmp_seq=2 Destination Host Unreachable
From 192.168.1.250 icmp_seq=3 Destination Host Unreachable
From 192.168.1.250 icmp_seq=4 Destination Host Unreachable

--- mo2-ge-0-0-2.example.com ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 2999ms, pipe 3
root@mo-ge-0-0-10:/root#


Exactly what I expected to see: the host on switch one, port ge-0/0/10 can ping the host on switch two, port ge-0/0/10, but cannot ping the hosts on ge-0/0/2 on either switch. Perfect! Let's make sure the hosts on ge-0/0/2 can ping each other but not hosts on ge-0/0/10:

root@mo-ge-0-0-2:/root# ping -c4 mo2-ge-0-0-10
PING mo2-ge-0-0-10 (192.168.1.134) 56(84) bytes of data.
From 192.168.1.17 icmp_seq=1 Destination Host Unreachable
From 192.168.1.17 icmp_seq=2 Destination Host Unreachable
From 192.168.1.17 icmp_seq=3 Destination Host Unreachable
From 192.168.1.17 icmp_seq=4 Destination Host Unreachable

--- mo2-ge-0-0-10 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 2999ms pipe 4
root@mo-ge-0-0-2:/root# ping -c4 mo2-ge-0-0-2
PING mo2-ge-0-0-2 (192.168.1.129) 56(84) bytes of data.
64 bytes from 192.168.1.129: icmp_req=1 ttl=64 time=0.509 ms
64 bytes from 192.168.1.129: icmp_req=2 ttl=64 time=0.233 ms
64 bytes from 192.168.1.129: icmp_req=3 ttl=64 time=0.247 ms
64 bytes from 192.168.1.129: icmp_req=4 ttl=64 time=0.283 ms

--- mo2-ge-0-0-2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2997ms
rtt min/avg/max/mdev = 0.233/0.318/0.509/0.111 ms
root@mo-ge-0-0-2:/root# ping -c4 mo-ge-0-0-10
PING mo-ge-0-0-10 (192.168.1.250) 56(84) bytes of data.
From 192.168.1.17 icmp_seq=1 Destination Host Unreachable
From 192.168.1.17 icmp_seq=2 Destination Host Unreachable
From 192.168.1.17 icmp_seq=3 Destination Host Unreachable
From 192.168.1.17 icmp_seq=4 Destination Host Unreachable

--- mo-ge-0-0-10 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3015ms pipe 3
root@mo-ge-0-0-2:/root#


Again, that's exactly what I wanted to see! The hosts on ge-0/0/2 on both switches can ping each other, but can't ping hosts on ge-0/0/10. Since both VLANs are working properly across the uplink between the two switches, we know that VLAN 20 (VoIP) is being 802.1q tagged properly on ge-0/0/21, and the default VLAN (PCs and servers) is being carried as the native (untagged) VLAN on the same port.

Since the EX3200 contains routing code as well as switching code, we can configure our routing protocols to route from one VLAN to the other, if we choose:

root@main3200# show protocols ospf
export ospf-default;
area 0.0.0.0 {
    interface ge-0/0/21.0;
    interface vlan.0 {
        passive;
    }
    interface vlan.20 {
        passive;
    }
    interface ge-0/0/19.0 {
        passive;
    }
}

[edit]
root@main3200#


By placing both vlan.0 and vlan.20 into the OSPF process, the router will now route between the two VLAN interfaces (what is called, "Routing-on-a-Stick," or sometimes, a "one-armed router").

No comments:

Post a Comment