[lug] Solved [Was: can ping the host, but can't ssh for a few seconds]

[Michael Hirsch]

On Tue, Jul 10, 2012 at 4:07 PM, Michael Hirsch <mdhirsch at gmail.com> wrote:

> On Tue, Jul 10, 2012 at 9:42 AM, Ebben Aries <earies at dscp.org> wrote:
>
>> so now that we know they are on the same segment - i would check a few
>> things
>>
>> - 1st, rule out any potential for protocol preference v6/v4 within ssh -
>> and replace 'warsaw' w/ its actual IP address and force v4 'ssh -4
>> software at 192.168.1.21'
>> - insert an arp check in your string
>>
>> # date; ping -c 1 192.168.1.21; /sbin/route; arp -na 192.168.1.21; ssh -4
>> software at 192.168.1.21
>>
>
> Ho ho! Progress.  My new command is to check arp, ping, arp again, ssh
> with IPv4, then arp again:.  (I took out route because it wasn't
> interesting.)
>
>     date;  arp -na 192.168.1.21; ping -c 1 192.168.1.21; arp -na
> 192.168.1.21; ssh -4 software at 192.168.1.21;  arp -na 192.168.1.21
>
> The results of the arps look okay, but a few seconds later I get a
> different answer!:
>

 Okay, so we cleaned it up.  It turns out that a) warsaw was a vmware image
with two virtual NICs on a server that has 5 NICs, and b) when we moved to
our new office our IT team had some trouble configuring it correctly.  The
server was on two networks with one NIC which meant that ultimately the two
virtual NICs were really on the same wire.

I don't fully understand what was going on, but both virtual NICs responded
to the arp request for our internal network 192.168.1.21.  Typically the
wrong one came through first and ssh would send to the wrong NIC.  Then the
other response would come through from the correct NIC and ssh could
connect properly.

Now we have the two ports on physically separate wires and we aren't seeing
multiple responses to arp requests.  Hooray!

Thanks everyone for your help.  Now I can get back to my real job.  :)

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20120710/0a5d4277/attachment.html>