topic RE: Extreme Summit Switch Appears to not be Sending any OSPF Hellos in ExtremeSwitching (EXOS/Switch Engine)

Extreme Summit Switch Appears to not be Sending any OSPF Hellos

Trevor_Jackson — Tue, 08 Aug 2017 06:37:00 GMT

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

RE: Extreme Summit Switch Appears to not be Sending any OSPF Hellos

Karthik_Mohando — Tue, 08 Aug 2017 16:32:00 GMT

Hi Trevor,

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

Can you share the "show configuration hal" from the switch?

RE: Extreme Summit Switch Appears to not be Sending any OSPF Hellos

Trevor_Jackson — Tue, 08 Aug 2017 17:23:00 GMT

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

RE: Extreme Summit Switch Appears to not be Sending any OSPF Hellos

Karthik_Mohando — Tue, 08 Aug 2017 19:07:00 GMT

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.

RE: Extreme Summit Switch Appears to not be Sending any OSPF Hellos

Trevor_Jackson — Tue, 08 Aug 2017 19:13:00 GMT

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

RE: Extreme Summit Switch Appears to not be Sending any OSPF Hellos

Trevor_Jackson — Tue, 08 Aug 2017 19:27:00 GMT

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

RE: Extreme Summit Switch Appears to not be Sending any OSPF Hellos

David_Choi — Wed, 09 Aug 2017 06:00:00 GMT

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

RE: Extreme Summit Switch Appears to not be Sending any OSPF Hellos

Steven_Lin — Wed, 09 Aug 2017 06:14:00 GMT

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

RE: Extreme Summit Switch Appears to not be Sending any OSPF Hellos

Karthik_Mohando — Wed, 09 Aug 2017 09:23:00 GMT

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).

RE: Extreme Summit Switch Appears to not be Sending any OSPF Hellos

Stephane_Grosj1 — Wed, 09 Aug 2017 09:23:00 GMT

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

RE: Extreme Summit Switch Appears to not be Sending any OSPF Hellos

Stephane_Grosj1 — Wed, 09 Aug 2017 19:06:00 GMT

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

RE: Extreme Summit Switch Appears to not be Sending any OSPF Hellos

Trevor_Jackson — Wed, 09 Aug 2017 19:20:00 GMT

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