I just failed my Trapeze re-cert by two points. D’oh.
I was originally trained on version 1.0 of the software and it is now at version 5.x. Even though I’ve used it regularly, there are things in the later versions that I simply don’t have experience of…
So I thought I would write up my notes from the partner update training to get the new stuff to stick in my head. Read the rest of this entry »
A colleague of mine has been called in to look at a problem for a customer where Ringmaster appears to lose part of the configuration and gets out of sync with the some of the MXes on the network. But when you try to add the missing config back in, it complains that it is already there… Read the rest of this entry »
A colleague of mine has recently been trying to get a Trapeze access-point to boot remotely from the MX switch by using DHCP option 43. This is what Trapeze refer to as a DAP – a Distributed Access Point.
Option 43 is what is known as the Vendor Specific Information DHCP Option. What should happen is that the AP boots up, does POST and does a DHCP request. The switch or router should send out a DHCP offer – an IP address to use, a default gateway to use and also the option 43 TLV. The TLV should contain the IP address of the MX switch where the AP needs to get its code and configuration from.
He’d configured a DHCP server pool on the Cisco switch where the DAP was attached. Within the scope he’d put the following:
option 43 IP A.B.C.D
which seems sensible, doesn’t it? Actually what was needed was:
option 43 ascii ip:A.B.C.D
If multiple MXes exist, their IP addresses can be strung together on the same line with a comma separating the IPs. Alternatively, hostnames cacn be used – just use the word host instead of the word ip.
Just put MSS 6.0.0.1 on a new MX-20, and all seemed to be going swimmingly. It is Early Availability code so I guess you should expect some problems, but since this customer isn’t going live just yet, we thought it was worth a try.
Anyway – after I left he had some kind of problem where clients weren’t authenticating, so he rebooted the MX. Following that, no clients could connect and Ringmaster couldn’t see the MX!
Looking in the logs we see this:
HTTPD Oct 27 15:18:58.849755 ERROR HTTPD: SSL connection failure (bad cert?); Admin client 192.168.1.100
HTTPD Oct 27 15:19:04.876600 ERROR SYSLOG_DUP: last message repeated 81 times.
Simply re-generating the admin certificate doesn’t work – it results in:
error: 'read error' returned from generate self-signed cert request
So we had to re-generate the keys and the certs from scratch for admin, eap and web. What a pain in the bum.
