Failover Peer Issue with Polycom SoundStation IP 6000 Phone

[willieb]

Thanks Glenn,

That is great news! I won't try to add the allow statement then. But
unfortunately it's not working. The ACK still shows the identifier of the
secondary server and not the primary for the SSIP class match. I verified
this with a wireshark capture. Here's the syntax I've tried (separately) and
it makes no difference for the identifier used in the ACK:

class "SSIP" {
match if substring (hardware,2,4) = aa:bb:cc:34;
server-identifier x.x.14.34;
}

class "SSIP" {
match if substring (hardware,1,5) = 1:aa:bb:cc:34;
server-identifier x.x.14.34;
}

class "SSIP" {
match if substring (hardware,2,4) = aa:bb:cc:34;
option dhcp-server-identifier x.x.14.34;
}

class "SSIP" {
match if substring (hardware,1,5) = 1:aa:bb:cc:34;
option dhcp-server-identifier x.x.14.34;
}

class "SSIP" {
match if substring (hardware,2,4) = aa:bb:cc:34;
server-identifier x.x.14.34;
option dhcp-server-identifier x.x.14.34;
}

class "SSIP" {
match if substring (hardware,1,5) = 1:aa:bb:cc:34;
server-identifier x.x.14.34;
option dhcp-server-identifier x.x.14.34;
}

Edit: Glenn, I didn't mean to send those first 2 replies directly to your
email lol...


glenn.satchell wrote
> Hi Will,
> 
> Looks like a simple syntax error of some sort in the config. If you run 
> that ExecStart command yourself I'm sure it will give better info.
> 
> However, the good news is that you don't need to 'allow members of 
> "SSIP"' in the pool(s). All the work is done in the class statement, in 
> that if it matches the class then all the settings in the class are 
> applied to that request. IP address and other allocation will be done in 
> whatever pools it subsequently uses. You could check this with a packet 
> trace using tcpdump for example.
> 
> regards,
> Glenn
> 
> --snip--

Quoted from: 
http://isc-dhcp-users.2343191.n4.nabble.com/Failover-Peer-Issue-with-Polycom-SoundStation-IP-6000-Phone-tp3609p3650.html




--
Sent from: http://isc-dhcp-users.2343191.n4.nabble.com/