blog
    The mystery of "ppp ipcp ...
    06 July 08

    The mystery of "ppp ipcp mask request" command

    Posted byPetr Lapukhov
    facebooktwitterlinkedin
    news-featured

    If you ever used IPCP for address allocation with PPP ("ip address negotiated" on client side and "peer default ip address" on server side) you may have noticed that the mask assigned to a client is always /32. It does not matter what mask a server uses on it's side of the connection, just PPP is designed to operate this way.

    However, many have noticed two strange commands "ppp ipcp mask request" and "ppp ipcp mask X.X.X.X" under PPP interface configuration mode. If IPCP assigned address never uses a custom mask, what would the purpose of those commands be? The answer is simple - to configure on-demand address pools in a client. That is, a client may request a DHCP pool parameters from server using IPCP - for example request a subnet and a mask. The client may then further use this information and allocate IP addresses to it's subordinates. Here is a configuration to verify this feature. Consider that R1 connects to R3 over a point-to-point link:

    R1:
    ip dhcp pool LOCAL
    import all
    origin ipcp
    !
    ! Link to R3
    !
    interface Serial0/1
    ip address pool LOCAL
    encapsulation ppp
    ppp ipcp mask request

    R3:
    !
    ! Link to R1
    !
    interface Serial1/2
    ip address 172.16.13.3 255.255.255.0
    encapsulation ppp
    peer default ip address pool POOL
    clock rate 128000
    ppp ipcp mask 255.255.255.0
    !
    ip local pool POOL 172.16.100.1 172.16.100.254

    Using the "debug ppp negotiation" command on R1 (the client) and R3 (the server) you may see the mask being requested and passed down to the client. Debug output from R1:

    Se0/1 IPCP: I CONFREQ [REQsent] id 1 len 10
    Se0/1 IPCP: Address 172.16.13.3 (0x0306AC100D03)
    Se0/1 IPCP: O CONFACK [REQsent] id 1 len 10
    Se0/1 IPCP: Address 172.16.13.3 (0x0306AC100D03)
    Se0/1 CDPCP: Redirect packet to Se0/1
    Se0/1 CDPCP: I CONFREQ [REQsent] id 1 len 4
    Se0/1 CDPCP: O CONFACK [REQsent] id 1 len 4
    Se0/1 IPCP: I CONFNAK [ACKsent] id 1 len 20
    Se0/1 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C01FFFFFF00)
    Se0/1 IPCP: Address 172.16.100.3 (0x0306AC106403)
    Se0/1 IPCP: O CONFREQ [ACKsent] id 2 len 20
    Se0/1 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C01FFFFFF00)
    Se0/1 IPCP: Address 172.16.100.3 (0x0306AC106403)
    Se0/1 CDPCP: I CONFACK [ACKsent] id 1 len 4
    Se0/1 CDPCP: State is Open
    Se0/1 IPCP: I CONFACK [ACKsent] id 2 len 20
    Se0/1 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C01FFFFFF00)
    Se0/1 IPCP: Address 172.16.100.3 (0x0306AC106403)
    Se0/1 IPCP: State is Open
    Se0/1 IPCP: Subnet: address 172.16.100.3 mask 255.255.255.0

    Debug output from R3:

    Se1/2 IPCP: O CONFREQ [Closed] id 1 len 10
    Se1/2 IPCP: Address 172.16.13.3 (0x0306AC100D03)
    Se1/2 CDPCP: O CONFREQ [Closed] id 1 len 4
    Se1/2 PPP: Process pending ncp packets
    Se1/2 IPCP: I CONFREQ [REQsent] id 1 len 20
    Se1/2 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C0100000000)
    Se1/2 IPCP: Address 172.16.100.3 (0x0306AC106403)
    Se1/2 IPCP: Use our explicit subbnet mask 255.255.255.0
    Se1/2 IPCP: O CONFNAK [REQsent] id 1 len 14
    Se1/2 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C01FFFFFF00)
    Se1/2 CDPCP: I CONFREQ [REQsent] id 1 len 4
    Se1/2 CDPCP: O CONFACK [REQsent] id 1 len 4
    Se1/2 CDPCP: I CONFACK [ACKsent] id 1 len 4
    Se1/2 CDPCP: State is Open
    Se1/2 IPCP: I CONFACK [REQsent] id 1 len 10
    Se1/2 IPCP: Address 172.16.13.3 (0x0306AC100D03)
    Se1/2 IPCP: I CONFREQ [ACKrcvd] id 2 len 20
    Se1/2 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C01FFFFFF00)
    Se1/2 IPCP: Address 172.16.100.3 (0x0306AC106403)
    Se1/2 IPCP: Use our explicit subbnet mask 255.255.255.0
    Se1/2 IPCP: O CONFACK [ACKrcvd] id 2 len 20
    Se1/2 IPCP: VSO OUI 0x00000C kind 1 (0x000A00000C01FFFFFF00)
    Se1/2 IPCP: Address 172.16.100.3 (0x0306AC106403)

    Now this is what you get when you configure "ip address negotiated" on R1:

    R1#sh ip interface serial 0/1
    Serial0/1 is up, line protocol is up
    Internet address is 172.16.100.5/32
    Broadcast address is 255.255.255.255
    Address determined by IPCP
    Peer address is 172.16.13.3

    And this is what shows up when you use local DHCP address pool for autoconfiguration (note the subnet mask):

    R1#sh ip interface serial 0/1
    Serial0/1 is up, line protocol is up
    Internet address is 172.16.100.4/24
    Broadcast address is 255.255.255.255
    Address determined by setup command
    Peer address is 172.16.13.3

    However, the funniest part is that R1 serial interface IP address is actually not allocated from the local (on-demand) DHCP pool! Observing the debug output you can see that R1 uses the IP address sent from R3, not allocated from the local DHCP pool. Then again, the local pool DHCP still has the requested subnet:

    R1#sh ip dhcp pool 
    

    Pool LOCAL :
    Utilization mark (high/low) : 100 / 0
    Subnet size (first/next) : 0 / 0
    Total addresses : 254
    Leased addresses : 0
    Pending event : none
    1 subnet is currently in the pool :
    Current index IP address range Leased addresses
    172.16.100.1 172.16.100.1 - 172.16.100.254 0

    R1#sh ip dhcp binding
    Bindings from all pools not associated with VRF:
    IP address Client-ID/ Lease expiration Type
    Hardware address/
    User name
    R1#

    You can see the following on R3:

    R3#sh ip local pool POOL
    Pool Begin End Free In use
    POOL 172.16.100.1 172.16.100.254 253 1
    ...
    172.16.100.1 Se1/2
    172.16.100.2 Se1/2
    172.16.100.3 Se1/2
    172.16.100.4 Se1/2
    Inuse addresses:
    172.16.100.4 Se1/2

    This is what so funny about Cisco IOS - you can never be sure the feature works in a most logical way you may suppose it to work. You can play with this example further, for example changing IP address allocation on R3 to local DHCP Pools or a static IP - there is always something you can experiment with!

    Further reading:

    Configuring the DHCP Server On-Demand Address Pool Manager

    Hey! Don’t miss anything - subscribe to our newsletter!

    © 2022 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
    instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo