Is it possible to merge arp data in from another source and have it included with the netdb? I saw another post with a script that was supposed to get arp data from the netdb box itself and import it but it didn't seem to work for what I need to do. Our DMZ is behind a firewall that I can't query with netDB but I'd like to have the IP addresses available. I was thinking I could somehow take the result of an nmap query and massage it into a format that netDB liked then copy it to the box and import it somehow on a periodic basis. Is this possible?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is fairly easy to do. You need to get your ARP table data in to this format and save it in say /opt/netdb/data/custom-arp.csv. MAC and IP are required, everything else is optional:
8,18,28,38,48,58 * * netdb /opt/netdb/updatenetdb.pl -a /opt/netdb/data/custom-arp.csv
The only other thing you might have to watch out for is there is no process lock mechanism to prevent imports from stacking up if things get slow. As long as your custom ARP table isn't too large, DNS is fast and the imports run fast that shouldn't be a problem.
Is it possible to merge arp data in from another source and have it included with the netdb? I saw another post with a script that was supposed to get arp data from the netdb box itself and import it but it didn't seem to work for what I need to do. Our DMZ is behind a firewall that I can't query with netDB but I'd like to have the IP addresses available. I was thinking I could somehow take the result of an nmap query and massage it into a format that netDB liked then copy it to the box and import it somehow on a periodic basis. Is this possible?
Ok I finally managed to get my arp data into a file but now when I try to bring it in by running "/opt/netdb/updatenetdb.pl -a /home/netdb/custom-arp.csv" I get an error on the first line:
Bad IP Address Input for IPMAC: 10.35.33.4
at /opt/netdb/updatenetdb.pl line 157
The first line of the file is:
10.35.33.4,0024.E867.56EF,0,,,
I'm generating the file with a Windows Powershell script and saving it with UTF8 encoding then sftp-ing it to the netdb box. If I cat the file on the netdb box it looks ok but I wonder if I need to save the text file in another way to make it work...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the problem is likely related to the UTF8 encoding but am not sure. How about pasting a couple lines in to a new file via your SSH terminal and see if it gives you trouble? Your format looks right so encoding is the only thing I can think of. It’s the Net:IP module that’s having trouble with it for some reason and it probably only handles plain text.
Let me know if that’s the problem, I’m sure there’s a quick way to convert from UTF8 to plain text.
Ok I finally managed to get my arp data into a file but now when I try to bring it in by running "/opt/netdb/updatenetdb.pl -a /home/netdb/custom-arp.csv" I get an error on the first line:
Bad IP Address Input for IPMAC: 10.35.33.4
at /opt/netdb/updatenetdb.pl line 157
The first line of the file is:
10.35.33.4,0024.E867.56EF,0,,,
I'm generating the file with a Windows Powershell script and saving it with UTF8 encoding then sftp-ing it to the netdb box. If I cat the file on the netdb box it looks ok but I wonder if I need to save the text file in another way to make it work...
Is it possible to merge arp data in from another source and have it included with the netdb? I saw another post with a script that was supposed to get arp data from the netdb box itself and import it but it didn't seem to work for what I need to do. Our DMZ is behind a firewall that I can't query with netDB but I'd like to have the IP addresses available. I was thinking I could somehow take the result of an nmap query and massage it into a format that netDB liked then copy it to the box and import it somehow on a periodic basis. Is this possible?
Hey,
This is fairly easy to do. You need to get your ARP table data in to this format and save it in say /opt/netdb/data/custom-arp.csv. MAC and IP are required, everything else is optional:
IP,MAC,age(disregard),router_interface,vrf,router
sample: 128.23.0.245,0022.56ba.ef7f,-,Vlan2035,,art-perim
Then do a custom import in your crontab:
8,18,28,38,48,58 * * netdb /opt/netdb/updatenetdb.pl -a /opt/netdb/data/custom-arp.csv
The only other thing you might have to watch out for is there is no process lock mechanism to prevent imports from stacking up if things get slow. As long as your custom ARP table isn't too large, DNS is fast and the imports run fast that shouldn't be a problem.
Jonathan
On Apr 18, 2014, at 11:33 AM, mbrinkho mbrinkho@users.sf.net wrote:
Ok I finally managed to get my arp data into a file but now when I try to bring it in by running "/opt/netdb/updatenetdb.pl -a /home/netdb/custom-arp.csv" I get an error on the first line:
Bad IP Address Input for IPMAC: 10.35.33.4
at /opt/netdb/updatenetdb.pl line 157
The first line of the file is:
10.35.33.4,0024.E867.56EF,0,,,
I'm generating the file with a Windows Powershell script and saving it with UTF8 encoding then sftp-ing it to the netdb box. If I cat the file on the netdb box it looks ok but I wonder if I need to save the text file in another way to make it work...
Hey,
I think the problem is likely related to the UTF8 encoding but am not sure. How about pasting a couple lines in to a new file via your SSH terminal and see if it gives you trouble? Your format looks right so encoding is the only thing I can think of. It’s the Net:IP module that’s having trouble with it for some reason and it probably only handles plain text.
Let me know if that’s the problem, I’m sure there’s a quick way to convert from UTF8 to plain text.
Jonathan
On Apr 21, 2014, at 10:00 AM, mbrinkho mbrinkho@users.sf.net wrote:
I changed the encoding to ASCII and that fixed it. Victory!
Great, hopefully that won’t be a big deal to automate and you should be good to go.
Jonathan
On Apr 21, 2014, at 10:40 AM, mbrinkho mbrinkho@users.sf.net wrote:
It's a lot of steps but I think it will work out fine. Thanks!