- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
vendor-class-identifier within IPv4 Filters Avaya phone
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-10-2019 06:56 AM
Hi,
I created an IPv4 Option filter for Avaya phones. As vendor-class-identifier I used ccp.avaya.com
VLAN500 is Data VLAN and VLAN504 Voice VLAN
Option 242 for VLAN500: L2Q=1,L2QVLAN=504,VLANTEST=10
Option 242 for VLAN504 MCIPADD=145.26.237.172,MCPORT=1719,L2QVLAN=504,HTTPSRVR=145.26.237.165,HTTPPORT=80
However phone is getting an IP address from DATA VLAN only. After traffic capture it looks like option 242 is not send from Infoblox DHCP to the phone.
Can somebody conform ccp.avaya.com is correct for a Avaya J179IP Phone
Re: vendor-class-identifier within IPv4 Filters Avaya phone
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-10-2019 11:56 AM
Is there some reason you're not using the built-in fingerprint named "Avaya IP Phone"? It relies on a number of option lists, most including option 176 (old) or 242 (new). We don't have any J179 units but we do have B189 conference phones.
The only reason we even investigated that fingerprint was to use it to prevent DHCP to phones on the data VLANs. That was due to a software bug in older 6.6 software that caused a boot loop.
I'm also curious why you're storing the voice VLAN in the option 242 string instead of the phone learning that from the connected switch via LLDP. Before that method was supported by the phone software, maintaining many 242 strings was a real pain. Now the 242 string has nothing except the webserver (HTTPSRVR=MyServer.domain.com). The phone connects there and automagically pulls the xxxupgrade.txt file and the 46xxsettings.txt file for all parameters for each model. With that approach, the fingerprint isn't needed.
Re: vendor-class-identifier within IPv4 Filters Avaya phone
[ Edited ]- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-11-2019 08:20 PM - edited 06-27-2023 02:10 PM
Hello There,
It doesn't appear to be a problem with your VCI. The easiest way to identify this would be to look at the value of option 60 included in the DISCOVER packet sent by J179IP. Have you applied this filter globally ? I'm thinking it should be two filters added at the network level to differentiate value returned for Data VLAN from voice VLAN.
Just my thoughts. But i think this may need some data analysis & I'd suggest the best option would be to contact Infoblox Technical Support.
Best regards,