[QUOTE=tkarhu;9601]Status update:
[LIST]
[*]VM host vsv04/10.31.10.4/SLES11SP2, which has explicit route since yesterday evening, has now pinged over 4h (record) in row. Promising.
[/LIST]
[/QUOTE]
This might actually point in the direction of timing-out ICMP redirect entries. But I must admit, my experience in that area isn’t too in-depth.
[QUOTE=tkarhu;9601]There are now 2 more observations/questions I have (perhaps basic - so bear with me again). Let’s focus on that physical box. itds/10.31.3.50 to keep things as simple as possible.
- I put tcpdump | grep ICMP running to see my echo requests from the Win7/10.31.64.2 (new addr from the pool - gateway for this is gw1/10.31.11.11) behind VPN. What caught my eye looking at tcpdump is:[/QUOTE]
I recommend to use tcpdump -eni eth0 icmp that way you’ll see the MAC addresses as well (and get addresses instead of numbers, which is helpful in case of wrong DNS entries)
[QUOTE=tkarhu;9601]
10:07:28.473471 IP 10.31.64.3 > vsv04: ICMP echo request, id 1, seq 18248, length 40
10:07:28.490802 IP 10.31.64.28 > vsv22: ICMP echo request, id 1792, seq 49222, length 40
10:07:28.500997 IP 10.31.64.5 > vsv01: ICMP echo request, id 1, seq 17074, length 40
10:07:28.501918 IP 10.31.64.6 > 10.31.10.250: ICMP echo request, id 10, seq 53266, length 40
Not being a network specialist, but remembering that switch’s function is to forward correct packet to correct ports, I started to wonder why do I see completely other LMC client’s traffic to completely other hosts? I called a network specialist of ours to clarify and he said “after switch learns hosts MAC, there should only be traffic visible destined to it (host itds in this case)”.
Do you see any simple reason why I see above in host itds’s tcpdump?[/QUOTE]
That specialist’s answer puts it a bit too plain: A switch will forward traffic for a specific MAC address to the port that the switch believes to lead to that MAC address. (That’s a reverse point of view from the one described by your specialist)
If the switch has no clue where to find that specific MAC address, it will broadcast the frame to all ports. And of course, link layer broadcast and multicast frames will be forwarded to all/multiple ports, too. So on any port, you’ll see traffic for the MAC address(es) believed to be reachable via that port, then broad- and multicast traffic and packets for destination addresses the switch doesn’t know about.
An important part in case of the above packets are the link layer addresses (not shown in your output), to which Ethernet adapter were those packets sent? Then you can decide why you see these packets in your trace.
Debugging the exact cause might involve looking at the switch’s MAC address table, which is far beyond the scope of this discussion. OTOH, another cause could be the LMC VPN gateway and it’s handling of the packets… but my crystal ball is foggy today 
[QUOTE=tkarhu;9601]
2. For these days I have had ping running on 4 hosts from this VPN client. Our guest wlan only disconnects it every night, other than that ping runs all the time. Ping output Time-to-Live caught my eye.
[LIST]
[]SLES9: has pinged now 5 days in row. TTL 62
[]SLES11SP1: has pinged now 5 days in row. TTL 62
[]SLES11SP2 VM: after explicit route ping appears ok. TTL 63. Earlier this week I noticed that TTL changed from 62 to 63 on the fly while pinging.
[]SLES11SP2 PHY: doesn’t ping even explicit route added (on the fly). TLL 63 and 63 seen like above VM.
[/LIST]
Does TTL play any part in this equation? Especially why TTL63 for that SP2 if the client is the same Win7/LMC?[/QUOTE]
TTL gives an indication of the number of routers/hops the packets had to cross on their way. An TTL change indicates a topology change (which may be caused simply by optimizing routing tables, taking an extra router out of the path).
The default ttl of Linux boxes seems to be 64 - so when you ping the SLES9 and SLES11SP1 systems, the response crosses two routers. One would be the VPN gateway, my guess for the other is the default router (which needn’t be in the path anyhow, as I had explained earlier). SLESS11SP2 answers are sent directly to the VPN gateway, so only one hop, leading to the remaining TTL of 63.
Concerning the 11SP2 physical machine: How do you get a TTL if you receive no ping replies (“SLES11SP2 PHY: doesn’t ping”)?
I’m under the impression that your network (routing) setup needs some “optimization”… but that would be an on-site job, maybe your network specialist can help out?
Oh, another question: In your original message, you reported that you see only every 5th or 6th ICMP echo request - is this still true when pinging vsv04 with the explicit route? Does the client report missing responses? If the latter is the case, it’d be rather interesting to see where the other four/five responses come from…
Regards,
Jens
Proper static routes with be the work-around.