[Kea-users] Vendor-Identifying option 125 vivso-suboptions
Sutherland, Rob
Robert.B.Sutherland at windstream.com
Thu Nov 7 15:23:21 UTC 2019
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/0941b5c6/attachment.htm>
More information about the Kea-users
mailing list