[Kea-users] Vendor-Identifying option 125 vivso-suboptions

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[Kea-users] Vendor-Identifying option 125 vivso-suboptions

Evan Carson
Hello,

We are running Kea 1.4.0 and are having trouble getting the server to hand out option 125 to a Mitel phone. The Kea server is replying to the client with this data in the DHCP offer with an empty option 125 containing only the Mitel enterprise option but no data.

We have this option definition specified in the Dhcp4 config:
        "option-def": [
        {
                "array": false,
                "code": 130,
                "encapsulate": "",
                "name": "mitel-option",
                "record-types": "",
                "space": "vendor-1027",
                "type": "string"
            }
      ],

We then placed this option in the subnet["pools"]["option-data"] for our phone subnet
                            {
                                "name": "vivso-suboptions",
                                "data": "1027"
                            },
                            {
                                "name": "mitel-option",
                                "space": "vendor-1027",
                                "data": "id:ipphone.mitel.com;sw_tftp=10.78.182.2;call_srv=10.78.182.2;vlan=71;l2p=6;dscp=46;"
                            }

Here is the DHCP Offer pcap coming back from server:

Frame 15952: 332 bytes on wire (2656 bits), 332 bytes captured (2656 bits)
Ethernet II, Src: RealtekU_e9:ea:63 (52:54:00:e9:ea:63), Dst: SmcStand_9c:c6:36 (08:00:0f:9c:c6:36)
Internet Protocol Version 4, Src: 192.168.1.1, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 67, Dst Port: 68
Bootstrap Protocol (Offer)
    Message type: Boot Reply (2)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x99cc086f
    Seconds elapsed: 0
    Bootp flags: 0x8000, Broadcast flag (Broadcast)
    Client IP address: 0.0.0.0
    Your (client) IP address: 192.168.1.102
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: SmcStand_9c:c6:36 (08:00:0f:9c:c6:36)
    Client hardware address padding: 00000000000000000000
    Server host name: KVM_128T_Remote
    Boot file name not given
    Magic cookie: DHCP
    Option: (1) Subnet Mask
    Option: (3) Router
    Option: (6) Domain Name Server
    Option: (51) IP Address Lease Time
    Option: (53) DHCP Message Type (Offer)
    Option: (54) DHCP Server Identifier
    Option: (61) Client identifier
    Option: (125) V-I Vendor-specific Information
        Length: 5
        Enterprise: Mitel, Corp. (1027)
            Length: 0
    Option: (255) End

It looks like the configuration for the enterprise ID is working correctly however the custom "mitel-option" string doesn't seem to be contributing. Is there anything wrong with the way we have this configured?

We aren't using any client-class configuration to restrict this option to only the clients requesting a given Vendor-Identifying Vendor Class option. Is it a requirement that the client-classification be used to specify the vendor class option?

Thank you for your help,

Evan Carson

_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Vendor-Identifying option 125 vivso-suboptions

Sutherland, Robert

Here’s what worked for my Mitel phones (note that I used option 43):

 

  "client-classes": [

  {

      "name": "mitel",

      "test": "substring(option[60].hex,0,17) == 'ipphone.mitel.com'",

      "option-def": [

          {

              "name": "vendor-encapsulated-options",

              "code": 43,

              "type": "string"

          }

      ],

      "option-data": [

      {

          "name": "vendor-encapsulated-options",

          "data": "id:ipphone.mitel.com;sw_tftp=10.151.75.34;call_srv=10.151.75.32"

      }

    ]

  },

 

From: Kea-users <[hidden email]> On Behalf Of Evan Carson
Sent: Wednesday, November 6, 2019 4:00 PM
To: [hidden email]
Subject: [Kea-users] Vendor-Identifying option 125 vivso-suboptions

 

Hello,

 

We are running Kea 1.4.0 and are having trouble getting the server to hand out option 125 to a Mitel phone. The Kea server is replying to the client with this data in the DHCP offer with an empty option 125 containing only the Mitel enterprise option but no data.

 

We have this option definition specified in the Dhcp4 config:

        "option-def": [
        {
                "array": false,
                "code": 130,
                "encapsulate": "",
                "name": "mitel-option",
                "record-types": "",
                "space": "vendor-1027",
                "type": "string"
            }
      ],

 

We then placed this option in the subnet["pools"]["option-data"] for our phone subnet

                            {
                                "name": "vivso-suboptions",
                                "data": "1027"
                            },
                            {
                                "name": "mitel-option",
                                "space": "vendor-1027",
                                "data": "id:ipphone.mitel.com;sw_tftp=10.78.182.2;call_srv=10.78.182.2;vlan=71;l2p=6;dscp=46;"
                            }

 

Here is the DHCP Offer pcap coming back from server:

 

Frame 15952: 332 bytes on wire (2656 bits), 332 bytes captured (2656 bits)
Ethernet II, Src: RealtekU_e9:ea:63 (52:54:00:e9:ea:63), Dst: SmcStand_9c:c6:36 (08:00:0f:9c:c6:36)
Internet Protocol Version 4, Src: 192.168.1.1, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 67, Dst Port: 68
Bootstrap Protocol (Offer)
    Message type: Boot Reply (2)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x99cc086f
    Seconds elapsed: 0
    Bootp flags: 0x8000, Broadcast flag (Broadcast)
    Client IP address: 0.0.0.0
    Your (client) IP address: 192.168.1.102
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: SmcStand_9c:c6:36 (08:00:0f:9c:c6:36)
    Client hardware address padding: 00000000000000000000
    Server host name: KVM_128T_Remote
    Boot file name not given
    Magic cookie: DHCP
    Option: (1) Subnet Mask
    Option: (3) Router
    Option: (6) Domain Name Server
    Option: (51) IP Address Lease Time
    Option: (53) DHCP Message Type (Offer)
    Option: (54) DHCP Server Identifier
    Option: (61) Client identifier
    Option: (125) V-I Vendor-specific Information
        Length: 5
        Enterprise: Mitel, Corp. (1027)
            Length: 0
    Option: (255) End

It looks like the configuration for the enterprise ID is working correctly however the custom "mitel-option" string doesn't seem to be contributing. Is there anything wrong with the way we have this configured?

 

We aren't using any client-class configuration to restrict this option to only the clients requesting a given Vendor-Identifying Vendor Class option. Is it a requirement that the client-classification be used to specify the vendor class option?

 

Thank you for your help,

 

Evan Carson

 

Sensitivity: Internal


_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Vendor-Identifying option 125 vivso-suboptions

Evan Carson
Hi Rob,

Thank you for the info. I think this would work although our customer we are integrating a solution for claims that his requires option 125 specifically. I'm not sure that is necessarily true but that is what he is claiming based on his previous server setup. If I can't figure out how to get the vendor identifying options working I will get them to test out option 43 as you configure it above.

I'm curious if there is a way to get option 125 working to encapsulate the right vendor ID with the options included. From the docs I believe Kea allows it and I think I have it configured correctly above but it's only sending out an empty option.

Thanks again,

Evan

On Thu, Nov 7, 2019 at 10:23 AM Sutherland, Rob <[hidden email]> wrote:

Here’s what worked for my Mitel phones (note that I used option 43):

 

  "client-classes": [

  {

      "name": "mitel",

      "test": "substring(option[60].hex,0,17) == 'ipphone.mitel.com'",

      "option-def": [

          {

              "name": "vendor-encapsulated-options",

              "code": 43,

              "type": "string"

          }

      ],

      "option-data": [

      {

          "name": "vendor-encapsulated-options",

          "data": "id:ipphone.mitel.com;sw_tftp=10.151.75.34;call_srv=10.151.75.32"

      }

    ]

  },

 

From: Kea-users <[hidden email]> On Behalf Of Evan Carson
Sent: Wednesday, November 6, 2019 4:00 PM
To: [hidden email]
Subject: [Kea-users] Vendor-Identifying option 125 vivso-suboptions

 

Hello,

 

We are running Kea 1.4.0 and are having trouble getting the server to hand out option 125 to a Mitel phone. The Kea server is replying to the client with this data in the DHCP offer with an empty option 125 containing only the Mitel enterprise option but no data.

 

We have this option definition specified in the Dhcp4 config:

        "option-def": [
        {
                "array": false,
                "code": 130,
                "encapsulate": "",
                "name": "mitel-option",
                "record-types": "",
                "space": "vendor-1027",
                "type": "string"
            }
      ],

 

We then placed this option in the subnet["pools"]["option-data"] for our phone subnet

                            {
                                "name": "vivso-suboptions",
                                "data": "1027"
                            },
                            {
                                "name": "mitel-option",
                                "space": "vendor-1027",
                                "data": "id:ipphone.mitel.com;sw_tftp=10.78.182.2;call_srv=10.78.182.2;vlan=71;l2p=6;dscp=46;"
                            }

 

Here is the DHCP Offer pcap coming back from server:

 

Frame 15952: 332 bytes on wire (2656 bits), 332 bytes captured (2656 bits)
Ethernet II, Src: RealtekU_e9:ea:63 (52:54:00:e9:ea:63), Dst: SmcStand_9c:c6:36 (08:00:0f:9c:c6:36)
Internet Protocol Version 4, Src: 192.168.1.1, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 67, Dst Port: 68
Bootstrap Protocol (Offer)
    Message type: Boot Reply (2)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x99cc086f
    Seconds elapsed: 0
    Bootp flags: 0x8000, Broadcast flag (Broadcast)
    Client IP address: 0.0.0.0
    Your (client) IP address: 192.168.1.102
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: SmcStand_9c:c6:36 (08:00:0f:9c:c6:36)
    Client hardware address padding: 00000000000000000000
    Server host name: KVM_128T_Remote
    Boot file name not given
    Magic cookie: DHCP
    Option: (1) Subnet Mask
    Option: (3) Router
    Option: (6) Domain Name Server
    Option: (51) IP Address Lease Time
    Option: (53) DHCP Message Type (Offer)
    Option: (54) DHCP Server Identifier
    Option: (61) Client identifier
    Option: (125) V-I Vendor-specific Information
        Length: 5
        Enterprise: Mitel, Corp. (1027)
            Length: 0
    Option: (255) End

It looks like the configuration for the enterprise ID is working correctly however the custom "mitel-option" string doesn't seem to be contributing. Is there anything wrong with the way we have this configured?

 

We aren't using any client-class configuration to restrict this option to only the clients requesting a given Vendor-Identifying Vendor Class option. Is it a requirement that the client-classification be used to specify the vendor class option?

 

Thank you for your help,

 

Evan Carson

 

Sensitivity: Internal


_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users