Introducing SOC Insights for BloxOne Threat Defense: Boost your SOC efficiency with AI-driven insights to eliminate manual work and accelerate investigation and response times. Read the blog announcement here.

NIOS DNS DHCP IPAM

Reply

vendor-class-identifier within IPv4 Filters Avaya phone

New Member
Posts: 1
4981     0

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

Expert
Posts: 69
4981     0

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 ]
Superuser
Posts: 81
4981     0

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,

 

Showing results for 
Search instead for 
Did you mean: 

Recommended for You