Header Only - DO NOT REMOVE - Extreme Networks
Question

Extreme Summit Switch Appears to not be Sending any OSPF Hellos


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

12 replies

Userlevel 6
Hi Trevor,

Are these two devices directly connected or via an intermediate switch?

Can you share the "show configuration hal" from the switch?
Karthik,
The devices are directly connected with no intermediate switch or device in between. Here is the output of show configuration hal:

# Module hal configuration.
#
configure iproute sharing max-gateways 4

Thanks
Userlevel 6
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.
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
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
Userlevel 4
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
Userlevel 4
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
Userlevel 4
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
Userlevel 6
Hi Trevor,

I would suggest to open up a ticket with GTAC so that we can assist you to collect the packets to the CPU via debug mode (which needs one time password).
Userlevel 7
Karthik Mohandoss wrote:

Hi Trevor,

I would suggest to open up a ticket with GTAC so that we can assist you to collect the packets to the CPU via debug mode (which needs one time password).

He's running 22.1, so he should not be hitting this bug.
Userlevel 7
Did you check the usual, like mtu? Is the Palo Alto using also a broadcast link or is it configured as pt2pt?
I verified that the MTU is 1500 on both the Palo Alto device as well as the switch:

Extreme Switch:

debug vlan show vlan "Inside" | i mtu
flags:0x1100001000[-] mtu:1500 qos:0 l2Protos:0 adminState:1

Palo Alto Firewall:

Name: ethernet1/2, ID: 17
Operation mode: layer3
Virtual router default
Interface MTU 1500

This is the default value in both cases. The Palo Alto is configured to use a broadcast link:



I supposed I will try upgrading to version 22.3.1.4 this evening to see if it makes any difference in either the OSPF issue and/or the packet capture issue. I will report back tomorrow if this makes any difference as I have to wait until after hours to reboot the switch.

Thanks

Reply