[IDD #GQL-934266]: ldm upstream feed

Louis-Philippe,

> Just to be sure the basics are covered, here's our setup:
> 
> Source host on our side is 142.135.12.127 (unidata1.cmc.ec.gc.ca), and is 
> NATTED to 199.212.17.130 & 199.212.17.131.

Problems will occur if multiple downstream LDM-s request the same feedtype 
*and* are behind the same NAT device because they will, consequently, present 
the same IP address to our server, which will see a single downstream LDM 
that's requesting overlapping feeds. It will, consequently, disconnect the 
oldest one. This can lead to thrashing.

The solution is to ensure that all LDM-s behind a NAT device request disjoint 
feedtypes from an upstream LDM.

> A tcpdump on unidata1.cmc.ec.gc.ca show this:
> 
> 1 0.000000       unidata1.cmc.ec.gc.ca idd.unidata.ucar.edu  TCP      68     
> 45840 ? 388 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=512
> 26 0.087081       idd.unidata.ucar.edu  unidata1.cmc.ec.gc.ca TCP      68     
> 388 ? 45840 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1380 SACK_PERM=1 WS=256
> 27 0.087132       unidata1.cmc.ec.gc.ca idd.unidata.ucar.edu  TCP      56     
> 45840 ? 388 [ACK] Seq=1 Ack=1 Win=29696 Len=0
> 29 0.087545       unidata1.cmc.ec.gc.ca idd.unidata.ucar.edu  TCP      180    
> 45840 ? 388 [PSH, ACK] Seq=1 Ack=1 Win=29696 Len=124
> 107 0.175030       idd.unidata.ucar.edu  unidata1.cmc.ec.gc.ca TCP      62    
>  388 ? 45840 [ACK] Seq=1 Ack=125 Win=14848 Len=0
> 142 0.227620       idd.unidata.ucar.edu  unidata1.cmc.ec.gc.ca TCP      92    
>  388 ? 45840 [PSH, ACK] Seq=1 Ack=125 Win=14848 Len=36
> 143 0.227691       unidata1.cmc.ec.gc.ca idd.unidata.ucar.edu  TCP      56    
>  45840 ? 388 [ACK] Seq=125 Ack=37 Win=29696 Len=0
> 232 0.575480       idd.unidata.ucar.edu  unidata1.cmc.ec.gc.ca TCP      62    
>  388 ? 45840 [FIN, ACK] Seq=37 Ack=125 Win=14848 Len=0
> 233 0.575955       unidata1.cmc.ec.gc.ca idd.unidata.ucar.edu  TCP      56    
>  45840 ? 388 [FIN, ACK] Seq=125 Ack=38 Win=29696 Len=0
> 246 0.663512       idd.unidata.ucar.edu  unidata1.cmc.ec.gc.ca TCP      62    
>  388 ? 45840 [ACK] Seq=38 Ack=126 Win=14848 Len=0
> 
> Over 2 minutes, we see 99 retries of this same pattern.

Does the situation I described exist?

Are Unidata1 and Unidata2 the only systems behind the NAT device requesting 
feeds from our server?

> Network wise, is TCP/388 the only protocol involved?

Yes.

> If it’s the app layer that thrashes the connection, usually it means a 
> misconfig on one end.
> 
> Also we only have outgoing web filtering, but hot 80/443 involved AFAIK. Also 
> nothing can be initiated from the Internet to reach any of internal hosts, 
> only outgoing is allowed.

That's OK.

> Another host, on a similar subnet on our end, 142.135.24.129 
> (ldm-nexrad2.cmc.ec.gc.ca) is working correctly.

Because that host presents a different IP address to our server, the situation 
I described can't arise.

> Murray: Can you confirm both of the hosts are configured/licensed (if any) 
> the same way?

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: GQL-934266
Department: Support IDD
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.