I’m a little confused about how to determine which IP address relates to which Subscriber Module.
We have all our customers assigned public IP addresses with a linux DHCP server. Functionally, as far as the Linux server is concerned, each of these customers’ routers could be connected to a switch - and the Linux server can’t actually see any of the layer 2 stuff in between (as far as I know).
I’m not sure how I can determine which subscriber module each IP address is actually going through.
Obviously it’s important to be able to do that efficiently because we get legal notices on occasion from customer activities, and for other administrative reasons.
Any ideas on how to best approach this would be appreciated… if I could make Prizm talk to the DHCP server somehow, perhaps.
We do not use DHCP on the clietn radios for that very reason. We set up radios before they go into the field, then put in the customer info, including full address into the location field. Once I accept the radio into Prizm, I then have a page that geocodes the client address into lat/long, then I put it on a google map.
But I’m rambling. In your linux DHCP server, you’ll find (probably in /var/run) a dhcp.leases file, which will allow you to correlate the IP to the MAC address for current leases. The problem with DHCP, depending on your lease time, is that you’ll not know who was using an address once it goes to someone else.
Yeah, I know how to find the mac addresses in the dhcpd.leases file, but it’s the mac address of the client’s router or computer which is connected to the radio, not the radio itself. That doesn’t help much, because I don’t know what radio is actually connected to their router.
I am almost considering implementing some kind of registration system, much like the one that Telus uses (their Online Customer Administration) where a customer has to login and register their MAC address to get an IP address. Then we know very explicitly who has which address.
Of course, if we did that, I doubt we’d be able to use the Cisco 3550 switch for DHCP which we were planning on doing; we’d have to use a linux system or something (which is what we are doing now, but we wanted to ditch that router to simplify matters).
Prizm has an IP/MAC search function that seems to work ok. Prizm logs the contents of the bridging table when it polls an SM. You can also configure Prizm to poll the ARP table of a router/L3 switch. Then Prizm correlates that so when you do a query, you can see what elements have a particular MAC/IP.
Check out the “netdir_arp” and “netdir_bridge” tables in your Prizm database. Those tables should have ARP information from your switch (assuming you set Prizm to poll for it) and the bridging table information from the SMs.
Another alternative would be to use translation bridging in the AP. This will rewrite L2 MAC information with the MAC of the SM. Note, that your DHCP server will still see the MAC of the customer router/pc since the translation bridging function doesn’t rewrite the DHCP payload. It would be nice if the SM or AP could modify DHCP requests to include the SM MAC address as option 82 data. We have telco gear that does that. It’s very nice for tracking users right from our Linux DHCP server.
With translation bridging you could then poll your 3550 ARP table and get the IP to SM MAC correlation. Then if you need it, you can tie the IP from the dhcp.leases file your Linux server to the IP from the ARP table on the 3550 and you will have IP address to SM and pc/router data that you could timestamp and save to a database.
You mention using your 3550 as a DHCP server. I’m not sure of your network design, but I find using the 3550 as a DHCP relay and having a central DHCP server to be more manageable. The downside is if the DHCP server goes down, more sites are affected than if you do DHCP at each site.
Another way to accomplish all of this would be a DHCPatriot box. This implements the registration idea you were speaking of. I’ve talked to a couple people who use them and say they work very well.
https://www.dhcpatriot.com/
Charlie
Thanks boeningc, that’s some good info there. I’ll have a look at that when I’m in the office on Monday.
No problem. Hope it helps. 
Charlie