Extreme Summit Switch Appears to not be Sending any OSPF Hellos

[Trevor_Jackson]

I am trying to get an OSPF adjacency between a Summit X460G2-48p-G4 and a Palo Alto VM-100. I have done this quite a few times already at other deployments, but I am having a very hard time getting this working at this particular location.

When I run the show ospf neighbor command, I can see the Palo Alto VM-100 as a neighbor but the neighborship is stuck in "init":

Neighbor ID Pri State Up/Dead Time Address Interface
BFD Session State
==========================================================================================
10.130.36.10 1 INIT /DR 00:00:05:41/00:00:00:01 10.130.36.10 Inside
None

Looking in the log:

08/08/2017 01:53:33.87 Changing the state of neighbor rtid 10.130.36.10 ipa 10.130.36.10 to state = INIT due to hello received.

08/08/2017 01:53:33.87 Changing the state of neighbor rtid 10.130.36.10 ipa 0.0.0.0 to state = DOWN due to new neighbor.

08/08/2017 01:41:13.84 Changing the state of neighbor rtid 10.130.36.10 ipa 10.130.36.10 to state = INIT due to hello received.

08/08/2017 01:41:13.83 Changing the state of neighbor rtid 10.130.36.10 ipa 0.0.0.0 to state = DOWN due to new neighbor.

08/08/2017 01:33:43.81 Changing the state of neighbor rtid 10.130.36.10 ipa 10.130.36.10 to state = INIT due to hello received.

08/08/2017 01:33:43.81 Changing the state of neighbor rtid 10.130.36.10 ipa 0.0.0.0 to state = DOWN due to new neighbor.

08/08/2017 01:32:58.22 Changing the state of neighbor rtid 10.130.36.10 ipa 10.130.36.10 to state = DOWN due to inactivity timer expiry.

08/08/2017 01:23:08.41 Changing the state of neighbor rtid 10.130.36.10 ipa 10.130.36.10 to state = INIT due to hello received.

08/08/2017 01:23:08.41 Changing the state of neighbor rtid 10.130.36.10 ipa 0.0.0.0 to state = DOWN due to new neighbor.

There are multiple instances of these log entries likely because I disabled and enabled OSPF on the Summit a few times as a a troubleshooting step.

I have done a packet capture on the PA-VM100 and while it receives pings from 10.130.36.9 address without any issue. There was no other traffic from 10.130.36.9. As best as I can see, it seems as if the PA is sending Hellos but the Summit isn't.

Here is some additional info concerning the switch and OSPF config:
* sw-601.40 # sho fdb vlan "Inside"
Mac Vlan Age Flags Port / Virtual Port List
--------------------------------------------------------------------------------
00:50:56:80:16:59 Inside(0130) 0000 dhmi 4

Flags : d - Dynamic, s - Static, p - Permanent, n - NetLogin, m - MAC, i - IP,
x - IPX, l - lockdown MAC, L - lockdown-timeout MAC, M- Mirror, B - Egress Blackhole,
b - Ingress Blackhole, v - MAC-Based VLAN, P - Private VLAN, T - VLAN translation,
D - drop packet, h - Hardware Aging, o - IEEE 802.1ah Backbone MAC,
S - Software Controlled Deletion, r - MSRP,
X - VXLAN, Z - OpenFlow

Total: 35 Static: 0 Perm: 0 Dyn: 35 Dropped: 0 Locked: 0 Locked with Timeout: 0
FDB Aging time: 300
* sw-601.41 # sho iparp "Inside"
VR Destination Mac Age Static VLAN VID Port
VR-Default 10.130.36.10 00:50:56:80:16:59 12 NO Inside 130 4

# Module ospf configuration.
#

configure ospf routerid 10.130.36.9
enable ospf
enable ospf export direct cost 1 type ase-type-1
create ospf area 0.0.0.5
configure ospf add vlan Inside area 0.0.0.5
configure ospf vlan Inside priority 0

sho version

Switch : 800607-00-05 1528N-45618 Rev 5.0 BootROM: 1.0.2.1 IMG: 22.1.1.5
X460-G2-VIM-2SS-B-1: 800558-00-03 1524N-41626 Rev 3.0
PSU-1 : Internal PSU-1 800592-00-07 1549A-45278
PSU-2 :

Image : ExtremeXOS version 22.1.1.5 by release-manager
on Thu Oct 27 14:58:15 EDT 2016
BootROM : 1.0.2.1
Diagnostics : 5.4
Certified Version : EXOS Linux 3.18.24, FIPS fips-ecp-2.0.12

[Steven_Lin]

Which version the switch is running? I'm afraid you hit below bug.
https://gtacknowledge.extremenetworks.com/articles/Solution/OSPF-state-is-stuck-in-Init

[David_Choi]

Hi Trevor,

As your version is 22.1.1, the issue of "no packet capture file" seems to be matched with:

https://gtacknowledge.extremenetworks.com/articles/Solution/Enabling-Debug-Packet-Capture-on-a-port-...

So now, you can get packet capture either :

• Packet capture from Palo Alto VM-100 or
• Mirror packet for the port in the switch

Please refer following URL for the way of mirroring on EXOS:
https://gtacknowledge.extremenetworks.com/articles/How_To/How-To-Enable-And-Configure-Mirroring-In-E...

Regards,
David

[Trevor_Jackson]

I also ran a packet capture using these commands instead:

debug packet capture ports 4 on
debug packet capture ports 4 off

The switch accepted these commands but there was no packet capture afterwards:

ls
drw-r--r-- 2 root root 1024 Apr 14 2016 dhcp
drw-r--r-- 2 root root 1024 Apr 14 2016 lost+found
-rw-rw-rw- 1 root root 500783 Aug 8 02:14 primary.cfg
drw-r--r-- 4 root root 1024 Aug 8 01:19 ssl
drwxr-xr-x 2 root root 1024 Aug 8 01:19 vmt

ls /usr/local/tmp
-rw-rw-rw- 1 root root 36 Aug 8 14:55 capture.log
drwxrwxrwx 2 root root 1024 Apr 14 2016 dhcp

[Trevor_Jackson]

I tried the packet capture command, but it would not run at all:

debug packet capture port 4 on file-name ospftshoot1 count 200
^
%% Invalid input detected at '^' marker.

I realize the article indicates that this is a "hidden" command but here is what I get if I try to question mark it:

debug packet ?
show Display packet details

[Karthik_Mohando]

Trevor,

Thanks for sharing the output, i do not see the issue in the hal configuration that i expected.

Since both the devices are directly connected the next step i would suggest is to do a TCPDUMP in the switch, there are few debug command available to do this from EXOS CLI itself but be wary and read through the complete article before proceeding.

https://gtacknowledge.extremenetworks.com/articles/How_To/Perform-a-packet-capture-in-the-EXOS-CLI-u...

Lets see what the packet capture says.