Extreme Summit Switch Appears to not be Sending any OSPF Hellos

  • 0
  • 2
  • Problem
  • Updated 1 year ago
  • Not a Problem
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 <Noti:ospf.neighbor.ChgState> 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 <Noti:ospf.neighbor.ChgState> 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 <Noti:ospf.neighbor.ChgState> 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 <Noti:ospf.neighbor.ChgState> 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 <Noti:ospf.neighbor.ChgState> 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 <Noti:ospf.neighbor.ChgState> 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 <Noti:ospf.neighbor.ChgState> 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 <Noti:ospf.neighbor.ChgState> 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 <Noti:ospf.neighbor.ChgState> 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
Photo of Trevor Jackson

Trevor Jackson

  • 302 Points 250 badge 2x thumb

Posted 1 year ago

  • 0
  • 2
Photo of Karthik Mohandoss

Karthik Mohandoss, Employee

  • 6,058 Points 5k badge 2x thumb
Hi Trevor,

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

Can you share the "show configuration hal" from the switch?
Photo of Trevor Jackson

Trevor Jackson

  • 302 Points 250 badge 2x thumb
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
Photo of Karthik Mohandoss

Karthik Mohandoss, Employee

  • 6,058 Points 5k badge 2x thumb
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.
Photo of Trevor Jackson

Trevor Jackson

  • 302 Points 250 badge 2x thumb
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
Photo of Trevor Jackson

Trevor Jackson

  • 302 Points 250 badge 2x thumb
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
Photo of David Choi

David Choi, Employee

  • 1,966 Points 1k badge 2x thumb
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
Photo of Steven Lin

Steven Lin, Employee

  • 2,330 Points 2k badge 2x thumb
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
Photo of Karthik Mohandoss

Karthik Mohandoss, Employee

  • 6,058 Points 5k badge 2x thumb
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). 
Photo of Grosjean, Stephane

Grosjean, Stephane, Employee

  • 13,526 Points 10k badge 2x thumb
He's running 22.1, so he should not be hitting this bug.
Photo of Grosjean, Stephane

Grosjean, Stephane, Employee

  • 13,650 Points 10k badge 2x thumb
Did you check the usual, like mtu? Is the Palo Alto using also a broadcast link or is it configured as pt2pt?
Photo of Trevor Jackson

Trevor Jackson

  • 302 Points 250 badge 2x thumb
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
(Edited)