You do not get an IP address.
Refer to the following diagram for the troubleshooting flow:
This section describes SD-Access specific troubleshooting. All the debugs and show commands from traditional DHCP troubleshooting would still apply here.
The architecture of SD-Access introduces a few design changes on how DHCP would operate in a fabric:
SD-Access fabric uses the anycast IP address for Gateway IP Address (GIADDR) in DHCP messages. This is the same IP address across all the edge switches in the fabric for a given VLAN. To identify the source Routing Locator ID (RLOC) where the host is connected the Option 82 field is required.
Here's a sample config from one of the edge switches:
interface Vlan1021 description Configured from apic-em mac-address 0000.0c9f.f45c vrf forwarding DEFAULT_VN ip address 220.127.116.11 255.255.255.0 <<Anycast IP address on all edge switches>> ip helper-address 192.168.1.101 no ip redirects ip pim sparse-mode ip route-cache same-interface ip igmp version 3 no lisp mobility liveness test lisp mobility 172_70_10_0-DEFAULT_VN endDHCP Option 82 is enabled on the edge node with the following command, which is pushed by DNAC:
ip dhcp relay information option
The options can be verified from either Sniffer capture or debug DHCP messages.
Here's an example of Option 82 from a DHCP Discover packet.
There are 2 sub-options in the Option 82 message, which help identify the end client requesting for an IP address:
Agent Circuit ID: 000403fd0117
00 - Sub Option 1
04 - Length of option
03fd - VLAN 1021
01 - Module 1
17 - Port 23 (0x17)
Agent Remote ID: 030800100201c0a86445
03 - Sub-option for LISP
08 - Length of option
001002 - LISP instance ID 4098
01 - IPv4 Locator
c0a86445 - 192.168.100.69 [Source RLOC ID]
The option can be verified from either Sniffer capture or debug DHCP messages.
The following SD-Access fabric configurations are necessary to understand the communication between the DHCP Client and Server.
interface Loopback1021 description Loopback Border vrf forwarding DEFAULT_VN ip address 18.104.22.168 255.255.255.255 router bgp 65000 address-family ipv4 vrf DEFAULT_VN network 22.214.171.124 mask 255.255.255.255 neighbor 172.16.10.54 remote-as 65004 exit-address-family
When the DHCP Discover packet is received from the client, if the LISP Map-cache does not have an entry for the server, then the map-request is sent towards the map server.
Following is a snippet of the LISP control plane debugs taken on the Edge, for reference:
010224: *Oct 12 10:30:22.890: DHCP_SNOOPING: process new DHCP packet, message type: DHCPDISCOVER, input interface: Gi1/0/23, MAC da: ffff.ffff.ffff, MAC sa: 0672.5a4c.0000, IP da: 255.255.255.255, IP sa: 0.0.0.0, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 0672.5a4c.0000, efp_id: -2072051712, vlan_id: 1021 010231: *Oct 12 10:30:22.891: [XTR] LISP: Processing data signal for EID prefix IID 4098 192.168.1.101/32 010232: *Oct 12 10:30:22.891: [XTR] LISP-0: Remote EID IID 4098 prefix 192.168.1.101/32, Change state to incomplete (sources: <signal>, state: unknown, rlocs: 0). 010233: *Oct 12 10:30:22.891: [XTR] LISP-0: Remote EID IID 4098 prefix 192.168.1.101/32, [incomplete] Scheduling map requests delay 00:00:00 min_elapsed 00:00:01 (sources: <signal>, state: incomplete, rlocs: 0). 010236: *Oct 12 10:30:23.020: [XTR] LISP: Send map request for EID prefix IID 4098 192.168.1.101/32 010238: *Oct 12 10:30:23.020: LISP-0: EID-AF IPv4, Sending map-request from 192.168.1.101 to 192.168.1.101 for EID 192.168.1.101/32, ITR-RLOCs 1, nonce 0xD5532B99-0xC6AC6FD0 (encap src 192.168.100.69, dst 192.168.101.8), FromPITR. 010242: *Oct 12 10:30:23.021: [XTR] LISP-0: Map Request IID 4098 prefix 192.168.1.101/32 remote EID prefix[LL], Received reply with rtt 1ms.
BGL-FE-12#sh ip lisp map-cache 192.168.1.101 instance-id 4098 LISP IPv4 Mapping Cache for EID-table vrf DEFAULT_VN (IID 4098), 5 entries 192.168.1.0/24, uptime: 00:24:27, expires: 23:35:32, via map-reply, complete Sources: map-reply State: complete, last modified: 00:24:27, map-source: 192.168.100.65 Idle, Packets out: 5(2037 bytes) (~ 00:23:25 ago) Locator Uptime State Pri/Wgt Encap-IID 192.168.100.65 00:24:27 up 10/10 - Last up-down state change: 00:24:27, state change count: 1 Last route reachability change: 1w1d, state change count: 1 Last priority / weight change: never/never RLOC-probing loc-status algorithm: Last RLOC-probe sent: 00:24:27 (rtt 1ms)
Workaround: Make sure the proxy ITR is configured on the edge and with a 0/0 map-cache for the DHCP request to be sent in the Overlay. Refer LISP troubleshooting page, to debug why the map-cache entry is not present.
BGL-FE-12#sh ip route 192.168.100.65 Routing entry for 192.168.100.65/32 Known via "isis", distance 115, metric 20, type level-1 Redistributing via isis Last update from 192.168.100.117 on FortyGigabitEthernet1/1/1, 1w1d ago Routing Descriptor Blocks: * 192.168.100.117, from 192.168.100.65, 1w1d ago, via FortyGigabitEthernet1/1/1 Route metric is 20, traffic share count is 1 BGL-FE-12#ping 192.168.100.65 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.100.65, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Workaround: Verify underlay Routing protocol (For example IS-IS) to understand why the RLOC is not reachable.
This step helps identify routing issues outside the fabric for reachability of the server.
9500-border-7#ping vrf DEFAULT_VN 192.168.1.101 source 126.96.36.199 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.101, timeout is 2 seconds: Packet sent with a source address of 188.8.131.52 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Fusion-Router#sh ip bgp vpnv4 vrf DEFAULT_VN 184.108.40.206/32 BGP routing table entry for 1:4098:220.127.116.11/32, version 3 Paths: (1 available, best #1, table DEFAULT_VN) Advertised to update-groups: 116 Refresh Epoch 1 65000 172.16.10.53 (via vrf DEFAULT_VN) from 172.16.10.53 (192.168.100.65) Origin IGP, metric 0, localpref 100, valid, external, best Extended Community: RT:1:4098 rx pathid: 0, tx pathid: 0x0
PS C:\Users\Administrator> ROUTE PRINT 172.70.10* ======================================================================== Interface List 14...00 0c 29 f4 2b bf ......Intel (R) 82574L Gigabit Network Connection #2 12...00 0c 29 f4 2b b5 ......Intel (R) 82574L Gigabit Network Connection 1...........................Software Loopback Interface 1 13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter 15...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2 ======================================================================= IPv4 Route Table ======================================================================= Active Routes: Network Destination Netmask Gateway Interface Metric 18.104.22.168 255.255.255.0 192.168.1.1 192.168.1.101 11
Another important troubleshooting step would be to take packet captures at various points in the fabric to understand the DHCP message flow. The Embedded Packet Capture functionality on Cisco devices provide the ability to perform packet captures. Here are a few points of packet capture and corresponding causes to troubleshoot.
|A||Ingress on Edge Node||
The Discover packet is not received on the Edge node, check if the client has actually sent Discover.
In this case, troubleshoot on the client to understand why Discover was not sent.
|B||Egress on Edge Node||The Discover is received on the Edge and not sent out.
In this case, add platform debugging to see why packets are getting dropped.
|C||Ingress on the Border Node||Verify whether the correct Option 82 values are used when the packet is received on the Border. If Discover is not received on the Border, check the intermediate IP network for drops or reachability.|
|D||Egress on the Border Node||The Discover is not sent out of the Border.|
|E||On the DHCP Server||The packet is not received on the Server. Debugging needs to be done outside the fabric, in this case, and on shared services.|
Basic checks should include the following:
In a traditional network, the IP address of the interface that the DHCP Discover message discovers is used to set the Relay Address (giaddress) when being forwarded by the relay towards the DHCP server.
The Fabric Edge/xTR pushed config:
interface Vlan1021 description Configured from apic-em mac-address 0000.0c9f.f45c vrf forwarding DEFAULT_VN ip address 22.214.171.124 255.255.255.0 << This would be the same any cast address used across all fabric edge switches >> ip helper-address 192.168.1.101 no ip redirects ip pim sparse-mode ip route-cache same-interface ip igmp version 3 no lisp mobility liveness test lisp mobility 172_70_10_0-DEFAULT_VN
With the LISP architecture, an IP Anycast is used. In other words, every Fabric Edge uses an Anycast IP Address.