Above is a quick reminder of different Hex values, given the previous post on FHRP troubleshooting which includes the VLAN / Router Group in Hex format. Click here for my full Hex Conversion article.
It will be needed for IPv6 troubleshooting!
Now a quick but necessary review of IPv4 identification!
It is important to be able to immediately identify incorrect IP Addressing, as this should be the first Layer 3 routing issue to address, as this starts with the host and its Gateway being in the same subnet!
The order of the octets from left to right:
128 / 64 / 32 / 16 / 8 / 4 / 2 / 1 = 255
From a prefix perspective when figuring out a network # / range, the subnet mask is the network prefix length, so any octects that are 255 can be assumed that is the network # in the section.
So 136.234.18.37 /28 =
10001000.11101010.00010010.00100101
11111111.11111111.11111111.11110000
Resulting in 136.234.18.32-.39 / 28
4 remaining host bits = 8 total bits per subnet, with the last IP of course being the broadcast address.
The host range can be determined from either approach, a /25 is a prefix of 128 is the 4th octet, which gives two subnets of .0-.127, and .128-.255.
When figuring out an inverse (wildcard) mask, the inverse mask is what is subtracted from a full /32 prefix.
So 0.0.191.255 = 255.255.64.0, as 191 + 64 = 255 and 0 + 255 = 255.
Nothing tricky, find the network # that adds up to 255, and that is your network # / host ranges depending on the host IP and which range its in.
Immediately verify your host and its default gateway is configured correctly both on the host with “ipconfig” and on the router LAN interace with “sh run int (int)” / “sh ip int brief” or in the running config.
How frames create their source / destination from the Prefix
When a Host A is forming a Frame to send to Host B, it will check the Prefix of the PC, which is the IP Address vs the Subnet Mask to confirm if they are on the same network.
If they are found to be on the same network the Src MAC will be that of Host A and the Dst MAC that of Host B, whereas if on another subnet the Src MAC will be Host A and the Dst MAC will be that of the Default Gateway, as it will require a Layer 3 device to route the traffic to the different subnetwork.
This is an important concept to understand for IPv6, as it doesn’t use Broadcast traffic at all, so part of understanding the Neighbor Discovery / Multicast Groups is understanding this need to need a Gateway to send common traffic to an uncommon Destination!
More on that in my next post regarding all things IPv6 🙂
DHCP config / behavior review and troubleshooting
DHCP association is initiated by the Client to the DHCP Server with a “DHCP Discover” discover request is flood from Src Host MAC / 0.0.0.0 to Dest FFFF.FFFF.FFFF / 255.255.255.255.
All DHCP Servers in the same subnet as the Host will respond with a DHCP Offer that includes a Host Address lease from its DHCP Pool, DNS / Default Gatwey (Default Router) / DHCP Server / Etc information, again this step 2 is a “DHCP OFFER” sent by the DHCP Server.
The Client will accept the first DHCP Offer is receives, this third step is a “DHCP REQUEST” packet, sent back to the DHCP Server to acknowledge it will use the Offer received.
The last step is the DHCP Server acknowledging to the Client that its Offer has been accepted for the Lease duration configured on the DHCP Server, by sending a “DCHP ACK” packet to finish the process.
The process is referred to as DHCP DORA, though there are a few less known DHCP messages:
- DHCP DECLINE – Sent Client to Server to inform an IP Address is already in use
- DHCP NAK – Sent Server to Client informing it will not provide reauested information
- DHCP INFORM – Requests IP Parameter information, often sent by a peripheral server, if for example a secondary DHCP Server is configured on the network
As mentioned in another TSHOOT article, many Layer 2 mechanisms can cause issues between a Host and Server, such as DTP / VTP / VACLs / Etc, to rule the out a Ping to the DHCP Server IP will rule out Layer 2 and Layer 3 connectivity as possible issues if the ping succeeds.
If not in the same subnet as the Host, the command “IP helper-address x.x.x.x” where x = DHCP Server IP, and this will need to be set on the interface that will receive DHCP Requests / can reach the subnet with the DHCP Server.
If a client has an APIPA Address (auto-config) of 169.254.x.x, a great first step is to make sure the network Boundary or DHCP Server has an IP in the common subnet as the Host, and if a network boundary that the IP helped command is correctly configured as routers do not forward broadcasts at all by default.
If that is verified good, then the DHCP Pool Config on the router will nee to be reviewed, which can be reviewed in detail here.
One value that is easy to overlook is the “default router” value, which is what will be provided as the Hosts Default Gateway, which will need to be its Network Boundary IP which can also be verified on the Host itself as the Default Gateway in “ipconfig” output.
If a Hosts gateway is on a different subnetwork than the Host, it won’t be able to ping anything, but will get IP info from DHCP – Just not the correct IP information.
IP NAT review and troubleshooting
NAT on a router can be quickly checked if it is working at all by using the command “sh ip nat translations” to see if there is any active transations, and a “clear ip nat trans *” to clear dynamic NAT translations to see if this resolves the host connectivity issue.
The 4 type of NAT IP Addresses just to review are:
Inside Local – The IP of a LAN Host before its Translated to an Internet Routable address
Inside Global – The Address the LAN IP is translated to that is publicly routable, likely the WAN interface IP of the router
Outside local – The address of the host trying to be reached, likely the remote WAN interface IP, assuming the destination is behind a router / NAT itself
Outside Global – The translated address of the remote host, likely the WAN IP as PAT / NAT Overload is basically always used outside of a Cisco exam
Two configurations that you will want to confirm is that the appropriate “ip nat inside” and “ip nat outside” is assigned to the correct interfaces, and that the ACL referenced in the NAT pool / interface overload command includes your hosts subnet with “sh access-list” command.
Click here for a full NAT post.
One last important consideration with NAT is it can cause issues if the traffic traverses a VPN, as the tunnel will verify a packets checksum which is changed during the NAT translation process.
That concludes IPv4 related troubleshooting
This should help eliminate IPv4 related issues immediately for trouble tickets, remember not to forget the many Layer 2 protocols if your pings are failing to anywhere from the host!
The DEVNET GRIND! 