Hi everybody! Currently I'm in troubleshooting a web communication problem and I say web because a user tries to web browser unsuccessfully an HP multifuntional administration page that it is located in a remote branch that is connected to the main office using an ISP MPLS where the user is. Here comes the rare part, trying to web brower the HP multifuntional administration page locally it works! either in the same network segment or in a different network segment through local routing. We already verify network layer connectivity and is fine, I mean, point to point communication is settup a ping from user pc to the HP multifuntional device is successful and a telnet using port 80 from user pc to the HP multifuntional device IP address shows that is open port 80. The matter here is when graphic data is requested from a external place of that branch does not work. We have two web services whitin that branch and neither one works from outside. We have another branch in the same scenario but it works this is the cause I suspect from the ISP MPLS to the affected branch they may be are filtering something but... What you say??? Next the complete comunication from when user web browser an HP multifuntional administration page in the branch where it actually works Now the problematic case This question is marked "community wiki". asked 19 May '12, 15:40  MarkNet |
One Answer:
All the fully-sized segments are missing?! This just looks to me like just another MTU problem and not some really rare case. I'd guess firewall blocks ICMP fragmentation needed but CF bit set messages so they don't appear in the trace. Check your MTU at the links and compare with advertised MSS, if that doesn't solve your problem please comment again. cheers answered 20 May '12, 11:00  Landi I agree, it looks like an MTU based problem... (20 May '12, 11:24) Jasper ♦♦ Fine, thanks for your replay on this guys i'll validate it. (20 May '12, 11:50) MarkNet yeap, MTU problem :) I just validated the correct MTU to use using different packet sizes in a ping from main office to the branch office once determined I used it on the wan interface of the remote branch where the problem was. But just two more questions, since I'm a novice using wireshark how did it look to you another MTU problem?? what did you look at in the capture file?? Thanks a lot for your help guys!! cheers (21 May '12, 21:01) MarkNet 1 Four signs for me:
Regards (21 May '12, 23:07) Kurt Knochner ♦ Alright, very thanks Kurt!! Regards, Mark (22 May '12, 15:03) MarkNet For me - and probably @Landi - it was mostly @Kurt's number 2. It is a common pattern that when you compare traces that work and do not work you'll see the working one with packets has full size segments while the nonworking doesn't. Oh, and I have to admit that after 10 years of doing network analysis there is a fair amount of "gut feeling" involved :-D ...which still needs to be verified each time, of course ;-) (22 May '12, 17:16) Jasper ♦♦ showing 5 of 6 show 1 more comments |
Could you please upload the tracefiles to http://www.cloudshark.org and paste the two links here? It's not very convenient to do network analysis in a picture viewer instead of Wireshark ;-)
link for not working communication capture http://www.cloudshark.org/captures/97f3001c88b1
link for working communication capture http://www.cloudshark.org/captures/c3c0b1767dd7