12-08-2015 12:27 PM - edited 03-08-2019 03:01 AM
I have the following weird behavior that I would like to understand.
I am setting up (stage) a group of 3850 switches and a 4500x core.
One of the stacks (3850) has the following repeating connections.
VAN-SRV3850#debug ip tcp packet address 192.168.2.2
TCP Packet debugging is on for line number 0, address 192.168.2.2
VAN-SRV3850#
*Dec 8 12:39:23.062: tcp0: I LISTEN 192.168.2.2:41940 192.168.2.1:23 seq 797930839
OPTS 20 SYN WIN 5840
*Dec 8 12:39:23.063: tcp0: O SYNRCVD 192.168.2.2:41940 192.168.2.1:23 seq 3141151245
OPTS 4 ACK 797930840 SYN WIN 4128
*Dec 8 12:39:23.067: tcp0: I SYNRCVD 192.168.2.2:41940 192.168.2.1:23 seq 797930840
ACK 3141151246 WIN 5840
*Dec 8 12:39:23.067: tcp0: I ESTAB 192.168.2.2:41940 192.168.2.1:23 seq 797930840
DATA 24 ACK 3141151246 PSH WIN 5840
*Dec 8 12:39:23.278: TCP2: bad seg from 192.168.2.2 -- outside window: port 23 seq 797930864 ack 3141151321 rcvnxt 797930876 rcvwnd 4092 len 12
VAN-SRV3850#show tcp br
TCB Local Address Foreign Address (state)
3259E67C 10.120.30.2.22 192.168.255.216.56814 ESTAB
38CA7174 192.168.2.1.23 192.168.2.2.41939 TIMEWAIT
38E22818 192.168.2.1.23 192.168.2.2.41940 ESTAB
The stack does not have an interface with 192.168.2.1 assigned to it, nor can I find where the packet might be originating from as this network does not exist that I am aware of.
The ssh session is my console connection.
Lines have transport input ssh configured.
12-08-2015 04:04 PM
Do a wireshark capture and get the MAC address of the 192.168.2.x host. Then do something like "show mac address-table" and search for the MAC address, which will identify which port it is plugged into.
Depending on what you have enable, you may also be able to use the "show ip device tracking ..." command and have it spit the port out that it is plugged into.
12-09-2015 11:48 AM
I am not onsite at the moment.
The point is there isn't much connected to it. A 4500X vss, another 3850 stack connected to the 4500x and and a 3925 router. The outside world is connected to the mgmtVrf in the 4500X. There are no networks configured on any of the above with 192.168.2.x.
The following are points about the 3850 not working correctly regarless of the source of this traffic.
1. The 3850 does not have an interface 192.168.2.1.
2. It should not answer if it did due to transport input ssh
3. If the traffic was coming from outside the 3850, the 4500X does not have a connection or a route to network 192.168.2.0.
4. I can block the connections with an acl and access-class on the vty ports.
5. There is nothing else connected to the 4500 or the 3850.
6. 192.168.2.1 or 2 is not in the arp table.
7. It still occurs even with default route removed and proxy arp is disabled on the 4500x for the vlan that the 3850 has an interface on.
8. vlan 30 has ip 10.120.30.2 There is no other ip interface except vlan 1 which is shutdown.
I have shutdown the other 3850 and the 3925. I can't shut anything else down as I would lose connectivity to the environment.
Further investigation of this will have to wait until I am on site.
02-26-2016 09:11 AM
Just to close this off. The issue disappear after an upgrade and reload.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide