Don't get me wrong; I have configured all of the protocols and examples that we have discussed, and I have verified that the examples I have provided work as advertised. However, many of these examples have required that we connect one or more hosts to the various networks that we have built so that we can test end-to-end connectivity across the network(s). While there is certainly no reason why a network admin cannot configure such hosts by hand, I must confess that I do not like doing more work than is necessary. Again, do not be mislead; I am not claiming that I am unwilling to work when it is necessary, but rather I am saying that if there is an easy way to accomplish a task and a difficult way to accomplish a task, then, all else being equal, I will choose the easy way. To that end, when I have needed a PC connected to the Juniper switches to test connectivity, I have -- without providing you with the instructions on how to do likewise -- made use of the DHCP protocol to automatically assign IP addresses to my devices. I apologize, and in penance, I will endeavour to right that wrong in this lesson ;)
As I am sure you know -- or at least have by now guessed -- DHCP is a standard protocol for automatically assigning various network settings to computers on a LAN. Most obvious, of course, is the ability to automatically assign an IP address to a host on the network. However, DHCP can also assign a number of other settings such as the default gateway, DNS (name server) addresses, and domain name. Needless to say, the ability to automatically provision network settings to any device that connects to a LAN can be a huge time-saver for a busy network admin. Do you really want to visit the workstation of every user in your company first thing in the morning to assign an IP address for the day? Of course, not! Fortunately, this is another example of the kind of routine, mundane, repetitive task that computers perform extremely well, so let's set up our main office EX3200 to do so.
In one of the earlier lessons, we agreed that the default VLAN on our main3200 switch would use the network 192.168.1.0/24. However, we also stated that we would have a handful of network devices and servers on this network. Network devices almost always have their IP addresses assigned statically, as it becomes very difficult to configure your LAN equipment to reach a default gateway, for example, when the gateway address changes periodically. Servers, for exactly the same reason, often have statically assigned IP addresses also, and therefore, we will set aside the first 15 IP addresses -- 192.168.1.1 through 192.168.1.15 -- for servers and network equipment. Consequently, our DHCP server will assign addresses in the range 192.168.1.16 through 192.168.1.254 to client PCs. Also, our DNS servers for all three networks are located at 192.168.1.6 and 192.168.2.6; we'll assign those name server addresses to client PC's, as well. Let's get started:
root@main3200# edit system services
[edit system services]
root@main3200# set dhcp domain-name main.example.com
[edit system services]
root@main3200# set dhcp router 192.168.1.1
[edit system services]
root@main3200# set dhcp pool 192.168.1.0/24 address-range low 192.168.1.16 high 192.168.1.254
[edit system services]
root@main3200# set dhcp name-server 192.168.1.6
[edit system services]
root@main3200# set dhcp name-server 192.168.2.6
[edit system services]
root@main3200# commit
commit complete
[edit system services]
root@main3200#
That's it!
Now, hook up a PC to one of the ports in the default VLAN, and see if it obtains an address in the 192.168.1.0/24 net block:
me@myllt:~$ ip addr | egrep -A3 "eth0:"
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:24:e8:cb:f9:e9 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.16/24 brd 192.168.1.255 scope global eth0
inet6 fd04:4879:556a:0:24:e8ff:fecb:f9e9/64 scope global
me@myllt:~$
Sweet! My laptop obtained the IP address 192.168.1.16/24 automatically from the DHCP service on the EX3200 switch!
However, we still have a problem. If you recall, we had planned not just one, but two VLANs on this physical network: the default VLAN for hosts like my laptop, but also a Voice-over-IP VLAN for our internal PBX. It's nice not to have to statically assign IP addresses to desktops and laptops, but wouldn't it be nice to also have DHCP hand off IP addresses automatically to the VoIP telephones, too?
Fortunately, that's not a problem, either. All we have to do is set up a separate DHCP pool using the same net block that we put the VoIP VLAN into:
root@main3200# set dhcp router 192.168.10.1
[edit system services]
root@main3200# set dhcp pool 192.168.10.0/24 address-range low 192.168.10.8 high 192.168.10.254
[edit system services]
root@main3200# set dhcp sip-server address 192.168.10.2
[edit system services]
root@main3200# commit
commit complete
[edit system services]
root@main3200#
Now, to test, we'll connect another laptop to one of the ports in the VoIP VLAN and see if we get a 192.168.10.xxx address:
me@myllt2:~$ ip addr | egrep -A3 "eth0:"
2: eth0: mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:15:c5:08:5d:92 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.8/24 brd 192.168.10.255 scope global eth0
inet6 fd04:4879:556a:0:15:c5ff:fe08:5d92/64 scope global
me@myllt2:~$
Yep, it worked! We now have both the default VLAN and the VoIP VLAN receiving IP addresses automatically.
It's outside of the scope of this lesson, but just for grins, let's see if OSPF will route across the VLANs for us:
me@myllt2:~$ ping -c1 192.168.1.16
PING 192.168.1.16 (192.168.1.16) 56(84) bytes of data.
64 bytes from 192.168.1.16: icmp_req=1 ttl=63 time=1.82 ms
--- 192.168.1.16 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.822/1.822/1.822/0.000 ms
me@myllt2:~$
There's that "routing-on-a-stick" we discussed earlier in action for ya' ;)
No comments:
Post a Comment