[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 <
Robert.B.Sutherland at windstream.com> 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 <kea-users-bounces at lists.isc.org> * On Behalf Of *Evan
> Carson
> *Sent:* Wednesday, November 6, 2019 4:00 PM
> *To:* kea-users at lists.isc.org
> *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
> <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fipphone.mitel.com&data=02%7C01%7CRobert.B.Sutherland%40windstream.com%7Cfe63ef71459047eeb95b08d762fc465b%7C2567b4c1b0ed40f5aee358d7c5f3e2b2%7C1%7C1%7C637086707970887653&sdata=ybRRfpPu13cnOyzXLUV2ojFqrTIFjusuUu%2BijhCjs1s%3D&reserved=0>
> ;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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20191107/fd9a34b6/attachment.htm>