I see a very strange behavior on my two nexus switches.
Both are Nexus 5548 with L3-daughter-cards. Both do l2 and l3-switching, ACL-filtering and other things. Furthermore I have a set of servers connected to both switches in a vPC-setup. All in all I do nothing special.
After reloading the primary switch (vpc-primary, root-bridge for all vlans and hsrp-active with preemption for all SVIs) the switche comes back online and after getting up all links and reconverging everthing the network breaks. After a lot of debugging and curses and connection tries and a few additional gray hairs later I have got it to work by pinging all ip-addresses from the switch that I have previously rebooted.
Later I do some tests to find out what was going wrong. I found out that if I clear the arp-cache I will get the same issue. Pinging from server A in one subnet to server B in another subnet doesn't lead to success, because the switch issues no arp-requests. To make it work just ping server B from the switch and all works fine. The switch does arp, the arp-table is updated and the pings from the server A will reach the server B.
fuck. The faulty behavior disappears. Just rebooting the nexus-switch. Two days to view a lots of logg-messages, error discovery, tests... For what? For nothing. And now I'm not absolutely sure that the fault will not raise up again. That does not inspire me with confidence.
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 ...