CCIE Lab

Topology:

Scenario:

The Host in the 192.168.0.0/24 network should get its IP address from a DHCP server.

Relay is the default router for the Host, but doesn’t have a DHCP service running. It will pass any DHCP requests from it’ f1/0 interface to the DHCP server that has DHCP pools configured on it, using the “ip helper-addres” command.

Between the DHCP router and the Relay router there is a public network, but behind Relay, there is a private network (Host is part of that network).  Relay will use NAT with overload (PAT) to service the private network.

Relay uses DHCP as it’s default route to the Internet, but DHCP doesn’t know about the private network in which Host is in (private networks shoudn’t be permitted to be accessed from the Internet).

Configurations:

DHCP:

ip dhcp pool DHCP_POOL
network 192.168.0.0 255.255.255.0
default-router 192.168.0.1

interface FastEthernet0/0
ip address 200.0.0.1 255.255.255.0

Relay:

interface FastEthernet0/0
ip address 200.0.0.100 255.255.255.0
ip nat outside

interface FastEthernet1/0
ip address 192.168.0.1 255.255.255.0
ip helper-address 200.0.0.1
ip nat inside

ip nat inside source list NAT_HOSTS interface FastEthernet0/0 overload

ip access-list standard NAT_HOSTS
permit 192.168.0.0 0.0.0.255

Host:

interface FastEthernet1/0
ip address dhcp

Problem:

Relay will receive a DHCP request (broadcast) on F1/0 interface. Because of the “ip helper-address“, Relay will transform the request from broadcast to unicast and send it to the DHCP router. The  DHCP request will reach the router, it will assign  an IP from the pool, but the reply will never reach Host.

Explenation:

Using “debug ip dhcp server events“, “debug ip dhcp server packet” and “debug ip packet“, we can find out the problem.

The first thing that could come to mind is the fapt that if Relay receives a packet on F1/0 interface (192.168.0.1) it will send an unicast message with the source IP address of that interface and a destination address of the ip-helper server. This is not true. The relayed request is considered to be generated by the local router (Relay). This means that the source IP address of the relayed request is that of the outgoing interface to the DHCP Server. Here is the debug ip packet output:

*Mar  1 02:33:23.127: IP: tableid=0, s=200.0.0.100 (FastEthernet0/0), d=200.0.0. 1 (FastEthernet0/0), routed via RIB

If  the source address of the IP packet does not have an IP address from the 192.168.0.0/24 network, how does the DHCP Server know from witch pool to give out a free address. The answer is a field in the DHCP protocol, called GIADDR (Gateway IP Address). The value of this field will be the IP address of the interface in the private network.

The problem is that after the DHCP server chooses an IP from the pool, it will reply to the unicast request, with another unicast packet that has the destination IP the GIADDR, not the source address of the request. The output from debug ip dhcp server events:

*Mar  1 03:13:33.719: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d 63.6330.322e.3035.6230.2e30.3031.302d.4661.312f.30 through relay 192.168.0.1.
*Mar  1 03:13:33.731: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d63.6330.322e.3035.6230.2e30.3031.302d.4661.312f.30 (192.168.0.2).
*Mar  1 03:13:33.731: DHCPD: unicasting BOOTREPLY for client cc02.05b0.0010 to relay 192.168.0.1

The DHCP router doesn’t know about the 192.168.0.0/24 network because that is a private network behind a NAT.

A solution to the situation is to add a static route on the DHCP router to the private network. But this would ruin the purpose of NAT. A better solution is to avoid the scenario by design (still, the situation could come up in lab environments and you should now know why it behaves the way it does)

To lower broadcast traffic in our network or for some extra security we use Virtual LANs. Cisco switches can be configured with Ethernet VLAN IDs ranging from 1 to 1001 and, with the extended VLANs, from 1006 to 4096. For trunking, we can use the IEEE 802.1Q (dot1q) protocol that can support the extended VLANs (1-4096).

The fisrt important rule of implementing VLANs in a network tells us that a switch won’t forward a frame from a VLAN if it does not know about that VLAN. All the switches in a network need to know about all the VLANs regardless of the fact that they have or not local access ports in those VLANs. So, we need to go to every switch and configure all the VLAN IDs, or we could use VTP (VLAN Trunking Protocol), Cisco’s proprietary protocol that automatically configures network-wide all the VLANs. Remember, VTP is on by default, in Server mode.

But the use of VTP can sometimes lead to unexpected behavior on the switch. Most common is when you try to reset your switch and you delete the running-config and the flash:vlan.dat, reload the IOS and find all your VLANs still there. If you have VTP configured in your network (without authentication), upon boot-up, the switch will get the VLAN information from it’s VTP neighbors, the reason being that the default configuration is Server mode. The solution would be to set the switch in Transparent mode and delete the VLANs.

The configuration of VTP Transparent mode causes another strange exception. As we are have studied in CCNA, the vlan.dat file in flash holds the VLAN information for a switch, not the running-config in NVRAM. This is not true when dealing with Transparent mode. If the switch is in VTP transparent mode, the VLAN information IS stored in running-config. So, if you configure vtp mode transparent, configure some VLANs, delete the vlan.dat and reboot, you will find the VLANs still there.

One more situation where VLANs are stored in running-config is when we use extended VLANs. Regardless of VTP mode, if we configure a VLAN with an ID greater than 1006, it will be stored as an entry in running-config. Extended VLANs will NOT be carried through VTP, so it makes sense not to store them in vlan.dat, because the switch will try to synchronize the file with the VTP information.

Networking is sometimes hard not because of the concepts that you need to apply, but because of the difference in implementation of some protocols on the equipment. For example, the default settings for DTP differ from one switch model to the next.

DTP (Dynamic Trunking Protocol) is used to negotiate a trunk link between two switches. From the DTP point of view, a port can be ‘desirable‘ (it will actively try to negotiate a  trunk), ‘auto‘ (it will form a trunk if the other side wants to be a trunk) and ‘non-negotiate‘ (port will not negotiate the link). The reason for this protocol is to have a working access or trunk link immediately after you connect the switch to the network.   Most of the combinations are:

• auto – auto => access
• auto – desirable => trunk
• desirable-desirable => trunk
• auto – trunk => trunk
• auto – access => access
• desirable – trunk => trunk
• desirable – access => access

What you should pay attention to is the default setting of a port on different switch models. On a 2950 (Layer 2 switch) and a 3550 (Layer 3 switch), a port is, before any configurations, in desirable. If you connect two of these switches, you will have a trunk link formed. On the other hand, on a 2960 or a 3560, a port is in auto, so between these models, you will have an access port (by default, in VLAN 1). Even more problems could arrive when you have in a network switches of different models. If you connect a 2960 and a 2950, because the first is in auto and the second  is in desirable, a trunk link will be negotiated, so you should be careful when dealing with these kinds of situations.