[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[NOAAPORT #ZLV-851048]: LDM misses data on NOAAPORT via satellite
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.
- Subject: [NOAAPORT #ZLV-851048]: LDM misses data on NOAAPORT via satellite
- Date: Mon, 21 Dec 2020 15:30:47 -0700
Hi Jim, re: > No, I am not using networkmanager. OK. I asked because of a comment I saw in one of the Stack Exchange links I looked at. re: > I also say google searches for DEFROUTE=yes and > tried changing it to 'no' and found it had zero effect. Hmm... that is unexpected. Did you try leaving DEFROUTE=yes in the ifcfg-enp1s0 file and change it to 'no' or comment it out in the ifcfg-eno1 file? re: > I "think" I know the problem, > I just do not know how to fix it. (based on my research of what I am seeing) > > To recap wxengine3 and wxengine4 can talk to other computers on our LAN. The > problem > is these computers need to also be able to talk to computers on our corporate > VPN. I > looked at the listing from 'netstat -rn' and from 'route'. The listings show 2 > gateways. Exactly. I think there should only be one, and it should be on the enp1s0 interface. For comparison, here is the 'netstat -rn' listing from our CentOS 8 machine that is running NOAAPort ingest: ~: netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 128.117.140.251 0.0.0.0 UG 0 0 0 bond0 128.117.140.0 0.0.0.0 255.255.255.0 U 0 0 0 bond0 128.117.140.3 0.0.0.0 255.255.255.255 UH 0 0 0 lo 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth2 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 bond0 224.0.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth2 224.0.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 eth2 224.0.1.3 0.0.0.0 255.255.255.255 UH 0 0 0 eth2 224.0.1.4 0.0.0.0 255.255.255.255 UH 0 0 0 eth2 224.0.1.5 0.0.0.0 255.255.255.255 UH 0 0 0 eth2 224.0.1.6 0.0.0.0 255.255.255.255 UH 0 0 0 eth2 224.0.1.7 0.0.0.0 255.255.255.255 UH 0 0 0 eth2 224.0.1.8 0.0.0.0 255.255.255.255 UH 0 0 0 eth2 224.0.1.9 0.0.0.0 255.255.255.255 UH 0 0 0 eth2 224.0.1.10 0.0.0.0 255.255.255.255 UH 0 0 0 eth2 re: > The metric from 'route' shows the private network gateway (192.168.1.1) > is 100 and for my internet gateway (10.133.207.217) of 101. I "think" what is > happening is when I make a request to the computer from the VPN it comes in on > the 10.133.207.217 gateway but the routing puts the other gateway as a lower > metric gateway so the response goes to the wrong gateway. OK. re: > [weather@wxengine4 ~]$ netstat -rn > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window irtt Iface > 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eno1 > 0.0.0.0 10.133.207.217 0.0.0.0 UG 0 0 0 > enp1s0 > 10.133.204.0 0.0.0.0 255.255.252.0 U 0 0 0 > enp1s0 > 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eno1 > 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 > virbr0 > 224.0.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 eno1 > 224.0.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 eno1 > 224.0.1.3 0.0.0.0 255.255.255.255 UH 0 0 0 eno1 > 224.0.1.4 0.0.0.0 255.255.255.255 UH 0 0 0 eno1 > 224.0.1.5 0.0.0.0 255.255.255.255 UH 0 0 0 eno1 > 224.0.1.6 0.0.0.0 255.255.255.255 UH 0 0 0 eno1 > 224.0.1.7 0.0.0.0 255.255.255.255 UH 0 0 0 eno1 > 224.0.1.8 0.0.0.0 255.255.255.255 UH 0 0 0 eno1 > 224.0.1.9 0.0.0.0 255.255.255.255 UH 0 0 0 eno1 > 224.0.1.10 0.0.0.0 255.255.255.255 UH 0 0 0 eno1 > 224.1.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 eno1 > [weather@wxengine4 ~]$ The fact that there are two gateways is undoubtedly the reason why you had to add GATEWAY0=192.168.1.1 .. GATEWAY10=192.168.1.1 lines in the route-eno1 file in /etc/sysconfig/network-scripts. We did not need to do this. re: > [weather@wxengine4 ~]$ route > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > default gateway 0.0.0.0 UG 100 0 0 eno1 > default gateway 0.0.0.0 UG 101 0 0 enp1s0 > 10.133.204.0 0.0.0.0 255.255.252.0 U 101 0 0 enp1s0 > 192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 eno1 > 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 > ntp.mcast.net 0.0.0.0 255.255.255.255 UH 100 0 0 eno1 > sgi-dog.mcast.n 0.0.0.0 255.255.255.255 UH 100 0 0 eno1 > rwhod.mcast.net 0.0.0.0 255.255.255.255 UH 100 0 0 eno1 > vnp.mcast.net 0.0.0.0 255.255.255.255 UH 100 0 0 eno1 > aviator.mcast.n 0.0.0.0 255.255.255.255 UH 100 0 0 eno1 > nss.mcast.net 0.0.0.0 255.255.255.255 UH 100 0 0 eno1 > audionews.mcast 0.0.0.0 255.255.255.255 UH 100 0 0 eno1 > sub-nis.mcast.n 0.0.0.0 255.255.255.255 UH 100 0 0 eno1 > mtp.mcast.net 0.0.0.0 255.255.255.255 UH 100 0 0 eno1 > ietf-1-low-audi 0.0.0.0 255.255.255.255 UH 100 0 0 eno1 > 224.1.1.1 0.0.0.0 255.255.255.255 UH 100 0 0 eno1 > [weather@wxengine4 ~]$ So, I think we are in agreement that the problem is being caused by there being two gateways defined. Question: - did you bounce the eno1 Ethernet interface after trying to either comment out DEFROUTE or setting it to 'no'? 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: ZLV-851048 Department: Support NOAAPORT Priority: Normal Status: Open =================== 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.
- Prev by Date: [NOAAPORT #ZLV-851048]: LDM misses data on NOAAPORT via satellite
- Next by Date: [NOAAPORT #ZLV-851048]: LDM misses data on NOAAPORT via satellite
- Previous by thread: [NOAAPORT #ZLV-851048]: LDM misses data on NOAAPORT via satellite
- Next by thread: [NOAAPORT #ZLV-851048]: LDM misses data on NOAAPORT via satellite
- Index(es):