?
Solved

Communication error with VM Host

Posted on 2012-08-17
3
Medium Priority
?
1,093 Views
Last Modified: 2012-09-18
Good morning experts, I am having an issue that no one seems to be able to get their head around.  Ive opened up tickets with Cisco, VMWare and Raritan.

I connect to a colocation facility through two Cisco ASA 5510 devices.

At my colocation facility i have just installed a new raritan kvm and an hp proliant server.  i am able to communicate with these devices while on a machine at my colo but not at my hq.  at my hq, i am able to ping the devices and ssh into them but not able to either connect using vsphere to the host or https to the kvm.  

my asa 5510s allow all traffic to and from the differnet subnets

vmware says its a network issue

cisco says its a vmware issue

raritan says its a MTU size issue with my routers...

Below is a packet trace from my ASA at headquarters.

44 packets captured

   1: 10:45:30.287125 192.168.1.174 > 10.200.0.5: icmp: echo request
   2: 10:45:30.287552 10.200.0.5 > 192.168.1.174: icmp: echo reply
   3: 10:45:31.270463 192.168.1.174 > 10.200.0.5: icmp: echo request
   4: 10:45:31.270829 10.200.0.5 > 192.168.1.174: icmp: echo reply
   5: 10:45:32.270432 192.168.1.174 > 10.200.0.5: icmp: echo request
   6: 10:45:32.270798 10.200.0.5 > 192.168.1.174: icmp: echo reply
   7: 10:45:33.270432 192.168.1.174 > 10.200.0.5: icmp: echo request
   8: 10:45:33.270783 10.200.0.5 > 192.168.1.174: icmp: echo reply
   9: 10:46:04.089106 192.168.1.174.3804 > 10.200.0.5.443: S 1696509091:1696509091(0) win 65535 <mss 1130,nop,nop,sackOK>
  10: 10:46:04.089503 10.200.0.5.443 > 192.168.1.174.3804: S 1448733841:1448733841(0) ack 1696509092 win 5840 <mss 1460,nop,nop,sackOK>
  11: 10:46:04.095347 192.168.1.174.3804 > 10.200.0.5.443: . ack 1448733842 win 65535
  12: 10:46:04.101572 192.168.1.174.3804 > 10.200.0.5.443: P 1696509092:1696509169(77) ack 1448733842 win 65535
  13: 10:46:04.101938 10.200.0.5.443 > 192.168.1.174.3804: . ack 1696509169 win 5840
  14: 10:46:04.102182 192.168.1.174.3804 > 10.200.0.5.443: R 1696509169:1696509169(0) win 65535
  15: 10:47:26.733207 192.168.1.174.3813 > 10.200.0.5.443: S 1987437665:1987437665(0) win 65535 <mss 1130,nop,nop,sackOK>
  16: 10:47:26.738456 10.200.0.5.443 > 192.168.1.174.3813: S 2709832402:2709832402(0) ack 1987437666 win 5840 <mss 1460,nop,nop,sackOK>
  17: 10:47:26.747138 192.168.1.174.3813 > 10.200.0.5.443: . ack 2709832403 win 65535
  18: 10:47:52.252321 192.168.1.174.3813 > 10.200.0.5.443: P 1987437666:1987437667(1) ack 2709832403 win 65535
  19: 10:47:52.252733 10.200.0.5.443 > 192.168.1.174.3813: . ack 1987437667 win 5840
  20: 10:47:52.253008 192.168.1.174.3813 > 10.200.0.5.443: R 1987437667:1987437667(0) win 65535
  21: 10:48:11.383372 192.168.1.174 > 10.200.0.5: icmp: echo request
  22: 10:48:11.383937 10.200.0.5 > 192.168.1.174: icmp: echo reply
  23: 10:48:12.351300 192.168.1.174 > 10.200.0.5: icmp: echo request
  24: 10:48:12.351849 10.200.0.5 > 192.168.1.174: icmp: echo reply
  25: 10:48:13.335630 192.168.1.174 > 10.200.0.5: icmp: echo request
  26: 10:48:13.336179 10.200.0.5 > 192.168.1.174: icmp: echo reply
  27: 10:48:39.840486 192.168.1.174 > 10.200.0.5: icmp: echo request
  28: 10:48:39.840990 10.200.0.5 > 192.168.1.174: icmp: echo reply
  29: 10:48:40.834658 192.168.1.174 > 10.200.0.5: icmp: echo request
  30: 10:48:40.835146 10.200.0.5 > 192.168.1.174: icmp: echo reply
  31: 10:48:41.834566 192.168.1.174 > 10.200.0.5: icmp: echo request
  32: 10:48:41.835055 10.200.0.5 > 192.168.1.174: icmp: echo reply
  33: 10:48:54.433144 192.168.1.174 > 10.200.0.5: icmp: echo request
  34: 10:48:54.433693 10.200.0.5 > 192.168.1.174: icmp: echo reply
  35: 10:48:55.428948 192.168.1.174 > 10.200.0.5: icmp: echo request
  36: 10:48:55.429466 10.200.0.5 > 192.168.1.174: icmp: echo reply
  37: 10:48:56.429009 192.168.1.174 > 10.200.0.5: icmp: echo request
  38: 10:48:56.429558 10.200.0.5 > 192.168.1.174: icmp: echo reply
  39: 10:50:35.525714 192.168.1.174.3835 > 10.200.0.5.443: S 3083369825:3083369825(0) win 65535 <mss 1130,nop,nop,sackOK>
  40: 10:50:35.526141 10.200.0.5.443 > 192.168.1.174.3835: S 2472181647:2472181647(0) ack 3083369826 win 5840 <mss 1460,nop,nop,sackOK>
  41: 10:50:35.533953 192.168.1.174.3835 > 10.200.0.5.443: . ack 2472181648 win 65535
  42: 10:50:35.534167 192.168.1.174.3835 > 10.200.0.5.443: P 3083369826:3083369903(77) ack 2472181648 win 65535
  43: 10:50:35.534197 192.168.1.174.3835 > 10.200.0.5.443: R 3083369903:3083369903(0) win 65535
  44: 10:50:35.534411 10.200.0.5.443 > 192.168.1.174.3835: . ack 3083369903 win 5840
44 packets shown

10.200.0.5 is the raritan at the colo

192.168.1.174 is my pc at the hq

you can see where the connection drops at the end when i try to connect to the raritan through a browser.

anyone out there have a thought on this?  something i can try?
0
Comment
Question by:SSNYT
  • 2
3 Comments
 
LVL 20

Expert Comment

by:agonza07
ID: 38310144
Have you tried reducing the MTU size?

http://www.richard-slater.co.uk/archives/2009/10/23/change-your-mtu-under-vista-or-windows-7/

Also the Cisco IPSEC VPN client has a utility called "Set MTU" that you can use if you have it.
0
 
LVL 1

Accepted Solution

by:
SSNYT earned 0 total points
ID: 38318591
thanks, ill try that.  my routers and firewalls are set at 1500 MTU, but i havent tried reducing the size...

weird news though, yesterday afternoon i was playing with it a bit and dropped a known working host on that subnet, then changed my non connecting host's ip to the one that was dropped and was able to connect to vcenter!  i then reset the previous host's ip to an open ip one great 116 instead of 115 and was able to rejoin that one to vcenter as well??!?!??!  

what the heck?  any one have an idea what that was all about?  my raritan still has the same issue but at this time my colo host is up and communicating to vcenter at my headquarters!
0
 
LVL 1

Author Closing Comment

by:SSNYT
ID: 38408744
sorry forgot to close this one....turns out it was my webfilter that was blocking traffic from the hq to my colo facility.  i found this out by double checking through the firewall logs and saw that it kept referencing the web filter during the times i was trying to connect.  i added it to the white list and all is well now.
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article explains the fundamentals of industrial networking which ultimately is the backbone network which is providing communications for process devices like robots and other not so interesting stuff.
In this article I will be showing you how to subnet the easiest way possible for IPv4 (Internet Protocol version 4). This article does not cover IPv6. Keep in mind that subnetting requires lots of practice and time.
Monitoring a network: why having a policy is the best policy? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the enormous benefits of having a policy-based approach when monitoring medium and large networks. Software utilized in this v…
Michael from AdRem Software outlines event notifications and Automatic Corrective Actions in network monitoring. Automatic Corrective Actions are scripts, which can automatically run upon discovery of a certain undesirable condition in your network.…

840 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question