Solved: Re: Troubleshooting - HTTP/HTTPS not accessible on the network

joe_chris · ‎04-29-2018

PC A is trying to access Server B web server. WAN is Metro Ethernet with 1ms latency.

PING from A to B OK
TRACEROUTE from A to B OK
SSH from A to B OK
HTTP/HTTPS from A to B NO RESPONSE

From the WireShark capture, Server B tries to reach PC A after exhausting retries. Any obvious issue with the network?

Zanthra · ‎05-01-2018

I have a strong suspicion that MTUs are not configured properly. Try reducing the MTU on the server and client interfaces to something low like 1200 and see if it makes a difference.

Due to SSH being an interactive protocol, it does not often have reason to fill packets to the max MTU, while HTTP and HTTPS do.

View solution in original post

mohammed01701 · ‎04-29-2018

Hi joe_chris!

Q1. Have you tried to use ping port 80 or 443 from the pc?

Q2. Have you any access-list that drops only http and https in your network?

Q3. Are you sure the http/s service is upp and running on the server?

Q4. Have tried to access the webbserver in localy, i mean using http/s in the local webbserver?

Q5. Coul you post the wireshark result?

/Mohammed

joe_chris · ‎04-29-2018

Hi Mohammed,

Q1: Yes, telnet 80/443 OK.

Q2: No access-list configured in all three switches.

Q3: Yes, I can connect to the web server if PC A is in VLAN 20.

Q4: Yes, as per Q3.

Q5: Please find the previous Wireshark extract. PC A IP was set to 192.168.17.93. VLAN 16 subnet 192.168.16.0/23.

Thanks.

mohammed01701 · ‎04-30-2018

Hi joe_chris!

Could you please send a pcap file not screenshot?

What i can se at this moment: Is that you have wrong time och screenshot "2018-03-07" have you tried to sync time? Have you same time both server and PC? I don´t know if is that a issue. Could you run 1 time for http and another time for https? and send pcap files:

/Mohammed

joe_chris · ‎04-30-2018

Hi Mohammed, As mentioned in the previous reply, the screenshot was from previous capture on 7th March. Unfortunately I do not have access to the equipment today. It will take sometime to recapture. Will update again.

joe_chris · ‎04-30-2018

Hi Mohammed,

You may want to take a look at the pcap file from previous capture. PC A in this capture is 192.168.17.93. Date is 7th March 2018. I will update again on the new capture.

mohammed01701 · ‎04-30-2018

Hi joe_chris!

Have you tested without the standby switch? Can you run traceroute from PC to server and server to PC?

Could you send the HSRP configuration?

What i can se at this moment is: You have some kind of packet loss or packet is comming out of order (TCP Dup ACK).

/Mohammed

joe_chris · ‎04-30-2018

Hi Mohammed,

No, the equipment is in production. I would like to understand more on the issue before such testing. traceroute and pathping without any packet loss.

Unfortunately I can't share the whole running config. Here is the config for HSRP section.

Switch 1

!
interface Vlan16
ip address 192.168.16.5 255.255.254.0
standby 0 ip 192.168.16.1
standby 0 priority 120
standby 0 preempt
!
interface Vlan20
ip address 192.168.20.2 255.255.255.0
standby 0 ip 192.168.20.1
standby 0 priority 120
standby 0 preempt
!

Switch 2

!
interface Vlan16
ip address 192.168.16.6 255.255.254.0
standby 0 ip 192.168.16.1
standby 0 preempt
!
interface Vlan20
ip address 192.168.20.3 255.255.255.0
standby 0 ip 192.168.20.1
standby 0 preempt
!

mohammed01701 · ‎04-30-2018

Hi joe_chris!

Ok, sorry.

The switch (that PC and server) connected, is this swich also connected to the standby router "I hope so"? by the topology you posted i only see this is connected to the active HSRP router? If that switch is not connected to the standby router, i don´t understand why do you needed to use HSRP. This switch is already single point of failure.. I don´t know if this problem is related network or service http/s is not configured good. You mentioned before you could ssh to the server, ping and telnet, so again i don´t know if this issue related network? Have any kind of CRC errors on those interfaces on your topology?

When you are on the server, can you use webbrowser and access the webserver, efter that please post the wireshark?

Thanks

/Mohammed

joe_chris · ‎04-30-2018

Hi Mohammed,

Let me share with you the reason for HSRP. The switches are in two different sites. HSRP is gateway for VLANs in Site A. Some of the VLANs are 'extended' over to Site B. Could the topology be the cause of the dropped packets observed in Wireshark?

I will also collect Wireshark for SSH just for comparison. May be SSH is robust enough for a few packet loss but not HTTP/HTTPS.

joe_chris · ‎05-01-2018

Hi Mohammed,

Attached is the PCAP file for SSH.

joe_chris · ‎05-01-2018

Hi Mohammed, Attached is the PCAP file for HTTP.

joe_chris · ‎05-01-2018

Hi Mohammed,

Attached is the PCAP file for HTTPS.

joe_chris · ‎05-01-2018

Hi Mohammed,

No CRC error between the interfaces for Site A to Site B link.

Site A

GigabitEthernetx/y is up, line protocol is up (connected)
Hardware is Gigabit Ethernet Port, address is 2894.0fc6.3bd9 (bia 2894.0fc6.3bd9)
Description:
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 3/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, link type is auto, media type is 10/100/1000-TX
input flow-control is on, output flow-control is on
Auto-MDIX on (operational: on)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:04, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 840000 bits/sec, 1190 packets/sec
5 minute output rate 12688000 bits/sec, 1662 packets/sec
25014879428 packets input, 6840670406116 bytes, 0 no buffer
Received 202383839 broadcasts (57384203 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
38918159560 packets output, 45904476975531 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

Site B

GigabitEthernety/z is up, line protocol is up (connected)
Hardware is Gigabit Ethernet Port, address is 2894.0fc6.3cc8 (bia 2894.0fc6.3cc8)
Description:
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 3/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, link type is auto, media type is 10/100/1000-TX
input flow-control is on, output flow-control is on
Auto-MDIX on (operational: on)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 11990000 bits/sec, 1611 packets/sec
5 minute output rate 862000 bits/sec, 1198 packets/sec
32406759005 packets input, 39711848191204 bytes, 0 no buffer
Received 887560244 broadcasts (438536781 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
20891977179 packets output, 5250509294585 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

Zanthra · ‎05-01-2018

I have a strong suspicion that MTUs are not configured properly. Try reducing the MTU on the server and client interfaces to something low like 1200 and see if it makes a difference.

Due to SSH being an interactive protocol, it does not often have reason to fill packets to the max MTU, while HTTP and HTTPS do.