We have two Cisco 6509-E configured in VSS. A FWSM is installed in the VSS. Recently we have faced a problem, an IP which was configured in a Cyberoam server on the outside of the FWSM, stopped responding from inside. We changed the IP to a different one and it started responding. After some days the new IP too stopped responding and we had to change the IP to yet another IP. The version of the FWSM is 4.0.4 while the IOS of VSS is SXI3.
The problem is existing with the two IPs only (currently). We tried configuring the problematic IPs on a machine and connected it to the outside of the FWSM, but the machine was not able to communicate with the inside IP, though it was able to ping the gateway, which is the IP of the outside VLAN in FWSM.
When we try to trace the problematic IPs from the inside VLANs, the trace seems to end on packet oscillate between FWSM and Core switch IP.
Tracing route to 10.10.139.180 over a maximum of 30 hops
1 1 ms <1 ms <1 ms 10.10.132.2 2 1 ms 1 ms 1 ms 10.10.139.195 3 3 ms 5 ms 2 ms 10.10.139.195 4 4 ms 4 ms 5 ms 10.10.139.195 5 4 ms 3 ms 3 ms 10.10.139.195 6 5 ms 7 ms 11 ms 10.10.139.195
10.10.139.195 is the IP of the vlan in core switch which communicates with the FWSM inside IP (10.10.139.193). The default route in switch 10.10.139.193.
We have tried rebooting the FWSM, but still the problem exists.
Has anyone faced a similare problem. Please respond.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...