This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Heather, re: > I am not confident that the route table is correct. npingest is the name of > my server, not the name of the novra. This is correct. The value should be the IP of the Ethernet interface on your computer to which the output of the Novra is connected. It should not be the IP address of the Novra. re: > See my /etc/hosts file: > [ldm@npingest ~]$ cat /etc/hosts > 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 > ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 > 10.2.15.252 npingest.triad.local npingest Hmm... I expected to see an association of the 'npingest.triad...' name with the IP address of the eth1 interface, which, according the 'ip addr' listing you sent earlier, is 192.168.0.10, not 10.2.14.252. Question: - what exactly was the 'route' command that you ran? re: > I am not sure why it showed up as the gateway?? It should. The route invocation I sent was: route add -net 224.0.0.0 netmask 240.0.0.0 gw 192.168.0.10 dev eth1 Note that 192.168.0.10 immediately follows 'gw' which stands for gateway. This route command says to send all multicast traffic from 224.0.0.0 with a netmask of 240.0.0.0 through the gateway 192.168.0.10 on the eth1 interface. As an example, here is the output of 'ifconfig -a' and 'route' on one of our CentOS 6.10 NOAAPort ingest machines: leno.unidata.ucar.edu: ~: ifconfig -a eth0 Link encap:Ethernet HWaddr 00:24:27:FE:47:6D inet addr:128.117.156.25 Bcast:128.117.156.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:58352713 errors:0 dropped:0 overruns:0 frame:0 TX packets:174811106 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3073030830 (2.8 GiB) TX bytes:263096344257 (245.0 GiB) eth1 Link encap:Ethernet HWaddr C0:3F:D5:68:29:E3 inet addr:192.168.1.7 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:11932127247 errors:0 dropped:0 overruns:0 frame:0 TX packets:427063 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:16329496411907 (14.8 TiB) TX bytes:44231112 (42.1 MiB) Interrupt:20 Memory:f7c00000-f7c20000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:3742 errors:0 dropped:0 overruns:0 frame:0 TX packets:3742 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:346063 (337.9 KiB) TX bytes:346063 (337.9 KiB) ~: route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 128.117.156.0 * 255.255.255.0 U 0 0 0 eth0 192.168.1.0 * 255.255.255.0 U 0 0 0 eth1 link-local * 255.255.0.0 U 1002 0 0 eth1 link-local * 255.255.0.0 U 1035 0 0 eth0 224.0.0.0 192.168.1.7 240.0.0.0 UG 0 0 0 eth1 default flr-n156.unidat 0.0.0.0 UG 0 0 0 eth0 notice that in: 224.0.0.0 192.168.1.7 240.0.0.0 UG 0 0 0 eth1 the second value is the IP address of our eth1 interface. The setup of our Novra that is attached to the eth1 interface on leno is: CMCS 192.168.1.20> show lan Network Interface Settings: Receiver MAC Address: 00-06-76-05-02-a9 Receiver IP: 192.168.1.20 Receiver Subnet Mask: 255.255.255.0 Default Gateway IP address: 192.168.1.8 Unicast Status Destination: 255.255.255.255:6516 Broadcast Status Port: 6516 IGMP: OFF Ethernet Packets out since boot: 131807803477 The Default Gateway IP address could have been 192.168.1.7, but it doesn't matter since all that really matters is that the address is on the same subnet and is not the same as the IP address of the Novra. re: > I have attached my ldmd.conf file. It looks much different from > yours. This is the same file that I used on my previous server. The differences are that you are using the system logging daemon for LDM logging and we are not, and we are specifying the log level via the '-n' flag. Speaking of logging, is there any log output from your noaaportIngester invocations? re: > Unfortunately, I cannot get you the VPN to log onto my server. OK, no worries. re: > Do you have a google account? We do google hangouts for work, and > through that I can share my screen with you. Would that work? Yes, I have both work and private Google accounts. And, hangouts works for me. Let me think about your situation for awhile. Hopefully, something will come to mind. Cheers, Tom -- **************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 address@hidden Boulder, CO 80307 ---------------------------------------------------------------------------- Unidata HomePage http://www.unidata.ucar.edu **************************************************************************** Ticket Details =================== Ticket ID: GGP-872890 Department: Support NOAAPORT Priority: Normal Status: Closed =================== NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.