[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[NOAAPORT #ZLV-851048]: LDM misses data on NOAAPORT via satellite
- 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.
