CCIE CCNA CISCO LIFE Work

Secondary IP subnet + DHCP

by |Published |2 comments

Egy nagyon érdekes problémába (elméleti kérdésbe) futottam bele a napokban. A kérdés a következő: hogyan lehetne kikényszeríteni, hogy a DHCP szerver secondary IP subnetből adjon IP-t a klienseknek? Egyáltalán hogyan viselkedik a Cisco router DHCP tekintetében akkor, ha van egy secondary subnet is konfigurálva az interface-n, és relay funkcióval továbbítjuk a kérést a központi DHCP szerver felé? Bár le van írva a dokumentációban, úgy döntöttem, kilaborozom.

A teszt topológiánk a következő lesz:

 

secondary_dhcp_hcb

 

Röviden összefoglalva az alap szituációt: R1, R2 és R3 lesznek a DHCP-s számítógépek. A switch minden portja az 1-es VLAN-ban van (alapértelmezett konfiguráció). R4 E0/0 lábán lesz konfigurálva egy IP subnet és egy secondary subnet, valamint DHCP Relay R5 felé. R5 lesz a DHCP szerverünk.

Alap konfigurációnk a következőek:

 

R1-R2-R3

conf t
no ip routing
int e0/0
ip address dhcp
no shutdown
end

 

R4

conf t
int e0/0
ip address 192.168.0.1 255.255.255.0
ip address 192.168.1.1 255.255.255.0 secondary
ip helper-address 10.1.45.5
no shutdown
int e0/1
ip address 10.1.45.4 255.255.255.0
no shutdown
end

 

R5

conf t
ip dhcp excluded-address 192.168.0.1
ip dhcp excluded-address 192.168.1.1
!
int e0/0
ip address 10.1.45.5 255.255.255.0
no shutdown
!
!
ip dhcp pool 192-168-0
network 192.168.0.0 /24
default-router 192.168.0.1
domain-name fkuris.local
!
!
ip dhcp pool 192-168-1
network 192.168.1.0 /24
default-router 192.168.1.1
domain-name fkuris1.local
!
!
ip route 192.168.0.0 255.255.255.0 10.1.45.4
ip route 192.168.1.0 255.255.255.0 10.1.45.4
end

 

Elsőre nem biztos, hogy nyilvánvaló, miért van szükség a két statikus route-ra. Azért kellenek, mert nem konfiguráltam routing protokollt, és mivel a DHCP szerver az OFFER üzenetet a relay agent-nek küldi vissza (esetünkben R4 E0/0 interface), tudnia kell, merre küldje a csomagot a 10.1.45.0/24-nek.

 

A klienseink máris kaptak IP-t, természetesen a primary subnetből:

R1#
R1#
*Jan 24 10:12:37.884: %DHCP-6-ADDRESS_ASSIGN: Interface
Ethernet0/0 assigned DHCP address 192.168.0.5,
mask 255.255.255.0, hostname R1
R1#
R1#

 

R4-en látjuk az ARP táblában a 3 klienst (és a router IP-it), illetve pingelni is tudjuk őket.

 

R4#sh ip arp | i 0/0
Internet 192.168.0.1 - aabb.cc00.0400 ARPA Ethernet0/0
Internet 192.168.0.3 1 aabb.cc00.0200 ARPA Ethernet0/0
Internet 192.168.0.4 1 aabb.cc00.0300 ARPA Ethernet0/0
Internet 192.168.0.5 1 aabb.cc00.0100 ARPA Ethernet0/0
Internet 192.168.1.1 - aabb.cc00.0400 ARPA Ethernet0/0
R4#
R4#
R4#
R4#
R4#
R4#
R4#ping 192.168.0.255 rep 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.0.255, timeout is 2 seconds:
Reply to request 0 from 192.168.0.4, 2 ms
Reply to request 0 from 192.168.0.5, 3 ms
Reply to request 0 from 192.168.0.3, 2 ms
R4#

 

R5-n látszanak a DHCP bejegyzések. Eddig jók vagyunk, az alap infrastruktúránk tehát készen.

R5#sh ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type
 Hardware address/
 User name
192.168.0.3 0063.6973.636f.2d61. Jan 25 2016 01:53 PM Automatic
 6162.622e.6363.3030.
 2e30.3230.302d.4574.
 302f.30
192.168.0.4 0063.6973.636f.2d61. Jan 25 2016 01:53 PM Automatic
 6162.622e.6363.3030.
 2e30.3330.302d.4574.
 302f.30
192.168.0.5 0063.6973.636f.2d61. Jan 25 2016 01:53 PM Automatic
 6162.622e.6363.3030.
 2e30.3130.302d.4574.
 302f.30
R5#

 

Nézzük először is, mit ír a Cisco dokumentáció erről a szituációról:

https://supportforums.cisco.com/discussion/11421896/secondary-ip-address-and-dhcp

http://www.cisco.com/c/en/us/support/docs/ip/dynamic-address-allocation-resolution/27470-100.html#secd

http://www.cisco.com/en/US/docs/ios/12_4t/ip_addr/configuration/guide/htdhcpre.html#wp1089419

 

A lényeg a következő:

By default, DHCP has a limitation in that the reply packets are sent only
if the request is received from the interface configured with the primary
IP address. DHCP traffic uses the broadcast address.
When the DHCP request is received by the router interface,
it forwards it to the DHCP server (when IP helper-address is configured)
with a source address of the primary IP configured on the interface
to let the DHCP server know which IP pool it must use (for the client)
in the DHCP reply packet.

There is no way for the router to know if the DHCP broadcast request
comes from a device that is on the secondary IP network configured
on the interface. As a workaround, sub-interface configuration
(provided that the device connected to the router supports dot1q tagging)
to separate the two subnets can be configured, so both of them get 
their correspondent IP addresses properly.

If the secondary address is the preferred way, there is 
another workaround, which is to enable the global configuration 
command ip dhcp smart-relay . This has a limitation in that 
it only uses the secondary IP to relay the DHCP request if
 there is no response from the DHCP server after three consecutive 
requests for the primary address pool.

 

Tehát az “ip dhcp smart-relay” paranccsal rávehetjük a routert, hogy a secondary IP-jét használja giaddr-ként, mikor továbbítja a DHCP csomagot a szerver felé. Ezt viszont csak akkor teszi meg, ha a primary subnetből 3 DHCP kérésre nem kap választ. Tehát ahhoz, hogy a secondary subnetből kaphasson a kliens IP-t, meg kell majd oldanunk, hogy az elsődleges tartományból ne adjon címet a szerver.

Először is kapcsoljuk be az “ip dhcp smart-relay” parancsot a dokumentációnak megfelelően:

 

R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#ip dhcp smart-relay
R4(config)#end
R4#

 

Próbáljunk most meg egy IP újítást R1-n (E0/0 shut – no shut), mi változik (elvileg semmi, mert kapni fog címet a szervertől), közben R5-n a DHCP debug be van kapcsolva.

!R1-en e0/0 --> shut, R5-n DHCPRELEASE-t látunk -->
!
!
R5#
*Jan 24 14:24:19.435: DHCPD: client's VPN is .
*Jan 24 14:24:19.435: DHCPD: No option 125
*Jan 24 14:24:19.435: DHCPD: DHCPRELEASE message received from client
0063.6973.636f.2d61.6162.622e.6363.3030.2e30.3130.302d.4574.302f.30 (192.168.0.5).
*Jan 24 14:24:19.435: DHCPD: removing ARP entry (192.168.0.5 vrf default).
*Jan 24 14:24:21.119: DHCPD: client's VPN is .
*Jan 24 14:24:21.119: DHCPD: No option 125
*Jan 24 14:24:21.119: DHCPD: DHCPRELEASE message received from client
0063.6973.636f.2d61.6162.622e.6363.3030.2e30.3130.302d.4574.302f.30 (192.168.0.5).
*Jan 24 14:24:21.119: DHCPD: Finding a relay for client 0063.6973.636f.2d61.6162
622e.6363.3030.2e30.3130.302d.4574.302f.30 on interface Ethernet0/0.
*Jan 24 14:24:23.129: DHCPD: client's VPN is .
*Jan 24 14:24:23.129: DHCPD: No option 125
*Jan 24 14:24:23.129: DHCPD: DHCPRELEASE message received from client
0063.6973.636f.2d61.6162.622e.6363.3030.2e30.3130.302d.4574.302f.30 (192.168.0.5).
*Jan 24 14:24:23.129: DHCPD: Finding a relay for client 0063.6973.636f.2d61.6162.
622e.6363.3030.2e30.3130.302d.4574.302f.30 on interface Ethernet0/0.
R5#
!
!
!
!R1-en E0/0 no-shut --> R5 ad IP-t a 192.168.0.0/24-ből -->
!
R5#
*Jan 24 14:24:44.877: DHCPD: client's VPN is .
*Jan 24 14:24:44.877: DHCPD: No option 125
*Jan 24 14:24:44.877: DHCPD: DHCPDISCOVER received from client
0063.6973.636f.2d61.6162.622e.6363.3030.2e30.3130.302d.4574.302f.30 through 
relay 192.168.0.1.
*Jan 24 14:24:44.877: DHCPD: Allocate an address without class information 
(192.168.0.0)
*Jan 24 14:24:44.878: DHCPD: Saving workspace (ID=0xAB000005)
*Jan 24 14:24:46.896: DHCPD: Reprocessing saved workspace (ID=0xAB000005)
*Jan 24 14:24:46.896: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d61.
6162.622e.6363.3030.2e30.3130.302d.4574.302f.30 through relay 192.168.0.1.
*Jan 24 14:24:46.897: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d61.
6162.622e.6363.3030.2e30.3130.302d.4574.302f.30 (192.168.0.6).DHCPD: 
Setting only requested parameters
*Jan 24 14:24:46.897: DHCPD: no option 125
*Jan 24 14:24:46.897: DHCPD: unicasting BOOTREPLY for client
aabb.cc00.0100 to relay 192.168.0.1.
*Jan 24 14:24:46.900: DHCPD: New packet workspace 0xF5DC9F40 (ID=0xC0000006)
*Jan 24 14:24:46.900: DHCPD: client's VPN is .
R5#
*Jan 24 14:24:46.900: DHCPD: No option 125
*Jan 24 14:24:46.900: DHCPD: DHCPREQUEST received from client 0063.6973.636f.
2d61.6162.622e.6363.3030.2e30.3130.302d.4574.302f.30.
*Jan 24 14:24:46.900: DHCPD: Appending default domain from pool
*Jan 24 14:24:46.900: DHCPD: Using hostname 'R1.fkuris.local.' for dynamic 
update (from hostname option)
*Jan 24 14:24:46.900: DHCPD: Sending DHCPACK to client 0063.6973.636f.2d61.6162
622e.6363.3030.2e30.3130.302d.4574.302f.30 (192.168.0.6).DHCPD: Setting only requested parameters
*Jan 24 14:24:46.900: DHCPD: no option 125
*Jan 24 14:24:46.900: DHCPD: unicasting BOOTREPLY for client aabb.cc00.0100 to relay 192.168.0.1.
R5#

 

Tehát letiltáskor egy DHCPRELEASE üzenetet látunk. Aztán újításkor látjuk, hogy a 192.168.0.1-es relay felé megy a DHCPOFFER, azaz semmi nem változott, a debugban is látható, hogy a 192.168.0.6-s IP-t kapja R1. Ez R1-en is látszik természetesen a logban:

 

R1#
*Jan 24 14:24:50.998: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet0/0 
assigned DHCP address 192.168.0.6, mask 255.255.255.0, hostname R1

 

Szimuláljuk, hogy a 192.168.0.0/24 megtelt (két címet hagyok benne, R2-R3 számára, hogy tudjanak újítani, de R1-nek már ne legyen hely), és nézzük, hogy mi történik. 3 sikertelen DISCOVER esetén azt kellene látnunk, hogy R4-től a secondary IP-ről kapja R5 az üzenetet.

Bekapcsolom R4-en is a debugot közben, hogy többet lássunk a folyamatból.

Először is hagyjunk két címet a pool-ban, és újítsuk meg R2-R3 lease-ét.

!
R5(config)#ip dhcp excluded-address 192.168.0.1
R5(config)#ip dhcp excluded-address 192.168.0.4 192.168.0.254
!
!
!
!
R2#
*Jan 24 14:34:17.743: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet0/0 assigned
DHCP address 192.168.0.3, mask 255.255.255.0, hostname R2
R2#
!
!
!
!
R3#
*Jan 24 14:34:14.693: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet0/0 assigned
DHCP address 192.168.0.2, mask 255.255.255.0, hostname R3
R3#

 

Akkor most próbáljunk meg R1-en új címet kérni, és kövessük a folyamatot:

!
!R1-en shut -->
!
!
!
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int e0/0
R1(config-if)#shut
R1(config-if)#
*Jan 24 14:39:26.728: %LINK-5-CHANGED: Interface Ethernet0/0, changed
state to administratively down
*Jan 24 14:39:27.737: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Ethernet0/0, changed state to down
R1(config-if)#
!
!
!
!Ez R5-n DHCPRELEASE-ként jelenik meg -->
!
!
!
R5#
*Jan 24 14:39:20.190: DHCPD: client's VPN is .
*Jan 24 14:39:20.190: DHCPD: No option 125
*Jan 24 14:39:20.190: DHCPD: DHCPRELEASE message received from client 
0063.6973.636f.2d61.6162.622e.6363.3030.2e30.3130.302d.4574.302f.30 
(192.168.0.6).
*Jan 24 14:39:20.190: DHCPD: removing ARP entry (192.168.0.6 vrf default).
*Jan 24 14:39:20.454: DHCPD: client's VPN is .
*Jan 24 14:39:20.454: DHCPD: No option 125
*Jan 24 14:39:20.454: DHCPD: DHCPRELEASE message received from client 
0063.6973.636f.2d61.6162.622e.6363.3030.2e30.3130.302d.4574.302f.30 (192.168.0.6).
R5#
*Jan 24 14:39:20.454: DHCPD: Finding a relay for client
0063.6973.636f.2d61.6162.622e.6363.3030.2e30.3130.302d.4574.302f.30 on 
interface Ethernet0/0.
R5#
R5#
*Jan 24 14:39:22.466: DHCPD: client's VPN is .
*Jan 24 14:39:22.466: DHCPD: No option 125
*Jan 24 14:39:22.467: DHCPD: DHCPRELEASE message received from client
0063.6973.636f.2d61.6162.622e.6363.3030.2e30.3130.302d.4574.302f.30 (192.168.0.6).
*Jan 24 14:39:22.467: DHCPD: Finding a relay for client 0063.6973.636f.2d61.
6162.622e.
6363.3030.2e30.3130.302d.4574.302f.30 on interface Ethernet0/0.
R5#
!
!
!
!
!R1-en no shut -->
!
R1(config-if)#no shut
R1(config-if)#
!
!
!
!R4 relay --> 3x 192.168.0.1 a giaddr -->
!
R4#
*Jan 24 14:39:45.270: DHCPD: client's VPN is .
*Jan 24 14:39:45.270: DHCPD: No option 125
*Jan 24 14:39:45.270: DHCPD: relay binding created for client 0063.6973.
636f.2d6 1.6162.622e.6363.3030.2e30.3130.302d.4574.302f.30.
*Jan 24 14:39:45.270: DHCPD: setting giaddr to 192.168.0.1.
*Jan 24 14:39:45.271: DHCPD: BOOTREQUEST from 0063.6973.636f.2d61.6162.
622e.6363 .3030.2e30.3130.302d.4574.302f.30 forwarded to 10.1.45.5.
R4#
*Jan 24 14:39:48.600: DHCPD: client's VPN is .
*Jan 24 14:39:48.600: DHCPD: No option 125
*Jan 24 14:39:48.600: DHCPD: setting giaddr to 192.168.0.1.
*Jan 24 14:39:48.600: DHCPD: BOOTREQUEST from 0063.6973.636f.2d61.6162.
622e.6363 .3030.2e30.3130.302d.4574.302f.30 forwarded to 10.1.45.5.
R4#
*Jan 24 14:39:52.620: DHCPD: client's VPN is .
*Jan 24 14:39:52.620: DHCPD: No option 125
*Jan 24 14:39:52.620: DHCPD: setting giaddr to 192.168.0.1.
*Jan 24 14:39:52.620: DHCPD: BOOTREQUEST from 0063.6973.636f.2d61.6162.
622e.6363 .3030.2e30.3130.302d.4574.302f.30 forwarded to 10.1.45.5.
!
!
!
!
!
!R5 nem tud adni IP-t, tele a pool -->
!
!
R5#
*Jan 24 14:39:45.271: DHCPD: client's VPN is .
*Jan 24 14:39:45.271: DHCPD: No option 125
*Jan 24 14:39:45.271: DHCPD: DHCPDISCOVER received from client 
0063.6973.636f.2d61.6162.622e.6363.3030.2e30.3130.302d.4574.302f.30 
through relay 192.168.0.1.
*Jan 24 14:39:45.271: DHCPD: Allocate an address without class 
information (192.168.0.0)
R5#
*Jan 24 14:39:48.600: DHCPD: client's VPN is .
*Jan 24 14:39:48.600: DHCPD: No option 125
*Jan 24 14:39:48.600: DHCPD: DHCPDISCOVER received from client 
0063.6973.636f.2d61.6162.622e.6363.3030.2e30.3130.302d.4574.302f.30 
through relay 192.168.0.1.
*Jan 24 14:39:48.600: DHCPD: Allocate an address without class information 
(192.168.0.0)
R5#
*Jan 24 14:39:52.621: DHCPD: client's VPN is .
*Jan 24 14:39:52.621: DHCPD: No option 125
*Jan 24 14:39:52.621: DHCPD: DHCPDISCOVER received from client 
0063.6973.636f.2d61.6162.622e.6363.3030.2e30.3130.302d.4574.302f.30 through 
relay 192.168.0.1.
*Jan 24 14:39:52.621: DHCPD: Allocate an address without class information 
(192.168.0.0)
R5#
R5#
R5#
!
!
!
!Megvolt a 3 DISCOVER, IP még nincs --> R4 a secondary giaddr-t használja -->
!
!
!
R4#
*Jan 24 14:40:11.124: DHCPD: client's VPN is .
*Jan 24 14:40:11.124: DHCPD: No option 125
*Jan 24 14:40:11.124: DHCPD: excessive retransmissions from client 
0063.6973.636 f.2d61.6162.622e.6363.3030.2e30.3130.302d.4574.302f.30.
*Jan 24 14:40:11.124: DHCPD: switching to relay address 192.168.1.1.
*Jan 24 14:40:11.124: DHCPD: setting giaddr to 192.168.1.1.
*Jan 24 14:40:11.125: DHCPD: BOOTREQUEST from 0063.6973.636f.2d61.6162.
622e.6363 .3030.2e30.3130.302d.4574.302f.30 forwarded to 10.1.45.5.
R4#
*Jan 24 14:40:13.150: DHCPD: client's VPN is .
*Jan 24 14:40:13.150: DHCPD: No option 125
*Jan 24 14:40:13.150: DHCPD: forwarding BOOTREPLY to client aabb.cc00.0100.
*Jan 24 14:40:13.150: DHCPD: no option 125
*Jan 24 14:40:13.150: DHCPD: broadcasting BOOTREPLY to client aabb.cc00.0100.
*Jan 24 14:40:13.152: DHCPD: client's VPN is .
*Jan 24 14:40:13.152: DHCPD: No option 125
*Jan 24 14:40:13.152: DHCPD: Finding a relay for client 0063.6973.636f.2d61.
6162 .622e.6363.3030.2e30.3130.302d.4574.302f.30 on interface Ethernet0/0.
*Jan 24 14:40:13.152: DHCPD: setting giaddr to 192.168.1.1.
R4#
*Jan 24 14:40:13.152: DHCPD: BOOTREQUEST from 0063.6973.636f.2d61.6162.
622e.6363 .3030.2e30.3130.302d.4574.302f.30 forwarded to 10.1.45.5.
*Jan 24 14:40:13.153: DHCPD: client's VPN is .
*Jan 24 14:40:13.153: DHCPD: No option 125
*Jan 24 14:40:13.153: DHCPD: forwarding BOOTREPLY to client aabb.cc00.
0100.
*Jan 24 14:40:13.153: DHCPD: no option 125
*Jan 24 14:40:13.153: DHCPD: broadcasting BOOTREPLY to client aabb.
cc00.0100.
*Jan 24 14:40:13.155: DHCPD: removing ARP entry (0.0.0.0 vrf default).
*Jan 24 14:40:13.155: DHCPD: removed relay binding for aabb.cc00.0100
R4#
!
!
!
!R5-n már a 192.168.1.1 a giaddr, és oszt is IP-t -->
!
*Jan 24 14:40:11.124: DHCPD: client's VPN is .
*Jan 24 14:40:11.124: DHCPD: No option 125
*Jan 24 14:40:11.124: DHCPD: DHCPDISCOVER received from client 
0063.6973.636f.2d61.6162.622e.6363.3030.2e30.3130.302d.4574.302f.30 
through relay 192.168.1.1.
*Jan 24 14:40:11.124: DHCPD: Allocate an address without class information
 (192.168.1.0)
*Jan 24 14:40:11.124: DHCPD: Saving workspace (ID=0x26000008)
R5#
*Jan 24 14:40:13.149: DHCPD: Reprocessing saved workspace (ID=0x26000008)
*Jan 24 14:40:13.149: DHCPD: DHCPDISCOVER received from client 
0063.6973.636f.2d61.6162.622e.6363.3030.2e30.3130.302d.4574.302f.30 through 
relay 192.168.1.1.
*Jan 24 14:40:13.149: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.
2d61.6162.622e.
6363.3030.2e30.3130.302d.4574.302f.30 (192.168.1.2).DHCPD: Setting only 
requested parameters
*Jan 24 14:40:13.149: DHCPD: no option 125
*Jan 24 14:40:13.149: DHCPD: unicasting BOOTREPLY for client 
aabb.cc00.0100 to relay 192.168.1.1.
*Jan 24 14:40:13.153: DHCPD: New packet workspace 0xF5DCFAE0 (ID=0xB8000009)
*Jan 24 14:40:13.153: DHCPD: client's VPN is .
R5#
*Jan 24 14:40:13.153: DHCPD: No option 125
*Jan 24 14:40:13.153: DHCPD: DHCPREQUEST received from client 
0063.6973.636f.2d61.6162.622e.6363.3030.2e30.3130.302d.4574.302f.30.
*Jan 24 14:40:13.153: DHCPD: Appending default domain from pool
*Jan 24 14:40:13.153: DHCPD: Using hostname 'R1.fkuris1.local.' for
 dynamic update (from hostname option)
*Jan 24 14:40:13.153: DHCPD: Sending DHCPACK to client 
0063.6973.636f.2d61.6162.622e.6363.3030.2e30.3130.302d.4574.302f.30 
(192.168.1.2).DHCPD: 
Setting only requested parameters
*Jan 24 14:40:13.153: DHCPD: no option 125
*Jan 24 14:40:13.153: DHCPD: unicasting BOOTREPLY for client aabb.
cc00.0100 to relay 192.168.1.1.
R5#
!
!
!
!R1 megkapta az IP-t -->
!
!
R1(config-if)#
*Jan 24 14:39:47.243: %LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up
*Jan 24 14:39:48.243: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
Ethernet0/0, changed state to up
R1(config-if)#
*Jan 24 14:40:17.239: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet0/0 
assigned 
DHCP address 192.168.1.2, mask 255.255.255.0, hostname R1
R1(config-if)#
!
!
!
!

 

Tehát a dokumentációnak megfelelően működik a folyamat.

 

 

 

AUTHOR

Kuris Ferenc
Network Engineer

You may also like