cancel
Showing results for 
Search instead for 
Did you mean: 

Extreme Summit Switch Appears to not be Sending any OSPF Hellos

Extreme Summit Switch Appears to not be Sending any OSPF Hellos

Trevor_Jackson
New Contributor II
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

11 REPLIES 11

Trevor_Jackson
New Contributor II
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:

9ca468d0190f4738985182120019636c_RackMultipart20170809-39761-txpn34-PA_OSPF_Settings_inline.jpg



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

Stephane_Grosj1
Extreme Employee
Did you check the usual, like mtu? Is the Palo Alto using also a broadcast link or is it configured as pt2pt?

Stephane_Grosj1
Extreme Employee
He's running 22.1, so he should not be hitting this bug.

Karthik_Mohando
Extreme Employee
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).
GTM-P2G8KFN