Extreme Summit Switch Appears to not be Sending any OSPF Hellos
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎08-07-2017 11:37 PM
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
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
08/08/2017 01:53:33.87
08/08/2017 01:41:13.84
08/08/2017 01:41:13.83
08/08/2017 01:33:43.81
08/08/2017 01:33:43.81
08/08/2017 01:32:58.22
08/08/2017 01:23:08.41
08/08/2017 01:23:08.41
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
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎08-09-2017 12:20 PM
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
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
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎08-09-2017 12:06 PM
Did you check the usual, like mtu? Is the Palo Alto using also a broadcast link or is it configured as pt2pt?
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎08-09-2017 02:23 AM
He's running 22.1, so he should not be hitting this bug.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎08-09-2017 02:23 AM
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).
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).
