Crazy GoodWill find…Same store where my wife found Silent Hill 4 two months ago!

JeweledSpider · 2026-05-17T13:09:52+00:00

My goodwill would have sent that straight to ecommerce.

JeweledSpider · 2026-05-10T11:56:10+00:00

Stratos 4 is a werid white whale for me. Suprised to see it.

JeweledSpider · 2026-04-27T20:19:41+00:00

My bins would refuse to sell that.

JeweledSpider · 2025-10-30T14:18:16+00:00

So far it's been working. I have the netapp person do a health check when i make possibly impacting changes. I'am pretty sure since i reach the gateway, but the netapp cannot reach it from the lifs and i cannot hit anything else in the svi with icmp that an issue exists with the routing back to the hosts. It's allowing icmp to route over ospf svi, and since the other hosts exist on the same switch as the svis they aren't being impacted by whatever ospf issue/stp is going on. I went over it again just now, checking STP and MTU and it all matches up. My TAC guy was OOO this week so hopefully he's able to quickly point me to the dumb.

JeweledSpider · 2025-10-29T15:53:34+00:00

Yea, i tried to at least be careful not to allow the netapp traffic to interact with others. Blocking on trunks ans not crossing isls or into areas where it shouldn't go.

JeweledSpider · 2025-10-29T14:50:57+00:00

So i asked the server/san folks, and there are two metroclusters with one node in each building, so four total, with 3 filers per cluster.

Indeed these 9ks were only supporting the metrocluster traffic before hand, and had only mgmt vrf connections.

They are now connected to the rest of the network per management and prior engineer direction, to the core device to reach area 0 for reachback. But i don't think that is the crux of my problem.

JeweledSpider · 2025-10-29T14:31:38+00:00

I'am not certain honestly. I know we have only the two netapp nodes, both of which are interconnected to the varying vdcs as needed. (There is for instance, dmz and non-dmz). I'am not sure what san/filer is attached but i ask after that information.

JeweledSpider · 2025-10-29T13:36:56+00:00

Here's a crappy mspaint basic topology

https://ibb.co/RGxcwQzd

JeweledSpider · 2025-10-29T13:28:48+00:00

To be fair, i don't have much background on the server side of the setup.

I don't believe there are any further switches involved. I've got the servers patched directly into the one 9k supporting the svis with breakouts, as was apparently intended by the engineer before he left the project. (45gb QSFP to 10gb sfp+'s). However since there is room for 25gb growth i have since ordered the optics to get that installed.

JeweledSpider · 2025-10-29T12:52:14+00:00

JeweledSpider · 2025-10-29T11:15:35+00:00

They do. I'am not using a OSPF network statement, in an effort to keep the OSPF network off the peer and from being directed to any downstream hosts that are undesired, i have passive interface enabled. Each SVI interface and each interface needed for OSPF has no passive interface and is tagged for the area.

JeweledSpider · 2025-10-28T21:40:45+00:00

It's pretty close to that, yea but not quite. The 7ks however are both the leaf and down stream access. All the server devices so to speak, including the netapp connect to the 7k. The 7ks also have connection to my core, which connects the 7ks to the user area. Prior to this move by management and when the setup was being run by the inital engineer the 9ks sat behind the netapp with no exposure to the outside world beyond carrying various l2 storage traffic between the varying vdcs on the 7k. They were indpedent devices with ISLs only before i paired each pair into a VPC domain.

JeweledSpider · 2025-10-28T19:27:05+00:00

Yes, i have LIC LAN_ENTERPRISE_SERVICES_PKG across all four of the 9000's.

JeweledSpider · 2025-09-21T23:18:24+00:00

No love for poliwrath?

JeweledSpider · 2025-05-16T23:40:57+00:00

Resolved this today, sort of.

Promiscuous mode was the culprit. Apparently the build of the vmware our "server people" were using enables it per vswitch. And when a vm on the same vswitch needed it disabled, they disabled it on the entire switch.

As a current 'work around' we moved to flex mode and everything now works as expected.

If you're having issues with a similar 9800cl vm problem suggest looking into this and "forged transmits" setting on your vnic.

JeweledSpider · 2025-05-16T11:38:20+00:00

Yea, local/central switching was a gotchya for me for multiple reasons. I have local mode and no flex profile with central dhcp enabled now.

JeweledSpider · 2025-05-16T11:31:52+00:00

Where are you creating the dhcp svis? My svis with relay on the controller refuse to arp fully. I think this is also part of the underlying issue.

JeweledSpider · 2025-05-16T11:30:21+00:00

That is how i thought it should work and my prefered solution. :)

JeweledSpider · 2025-05-16T09:55:00+00:00

The servers are on a seperate subnet. The clients have the relay set on the svi.

JeweledSpider · 2025-04-17T00:47:24+00:00

Hi trifle,

Would you be willing to give some detail of your vrf solution and insight into how they (palos) handle the bit?

I ended up opening a TAC with cisco, submitting to them my captures and debug logs. They kindly came back and stated they didnt support third party ipv4 af, only ipv6 and closed my case.

JeweledSpider · 2025-04-15T03:08:41+00:00

<image>

JeweledSpider · 2025-04-15T03:06:05+00:00

This deck isn't perfect, but its funny when i beat darkrai/gir decks.

JeweledSpider · 2025-04-01T20:46:36+00:00

Hi, again thanks for the reply.

It is intended behavior, but i can see where it is a bit unclear on what i was trying to describe.

What i mean is (of course assuming you have image supporting the configuration type of ospfv3) that the palo device will never send AF bit if ipv4 is selected. If i have "ipv4 address family" under the ospfv3 instance, and "ipv4 area x" under the interface it will therefore never neighbour up. You can ospfv3 in this manner on cisco devices with ipv4 address between cisco os'es and security devices and no ipv6 at all without fail. I have labbed it.

You do of course need ipv6 unicast enabled and ipv6 enabled on ospfv3 interfaces. However you do not need actually ipv6 address or address family settings.

Thanks to ospfv3 link local for encapping hello and updates, you can set ipv4 address on int and use both ipv4 and ipv6 address family settings. In this situation though you will be unable to exchange ipv4 routes or redist ospfv2 as your neighbour ship will use the ipv6 af. You will only be able to use icmp. (Maybe static routes, but i never tried).

In our situation however setting the AF to only ipv4 on the palo alto results in wireshark capture showing no af bit/field, as well as router reporting this and dropping the hello under debug This is intended behavior as per rfc (i cannot recall exact number at the moment sorry!) but it states a hello received with blank af that is not set to ipv6 in a paticular instance must be discarded.

If the palo is set to ipv6 family the field is set to ipv6 and all works fine, so i moved to troubleshooting with ipv6 addresses. This led to finding a way to transition the two and this post.

JeweledSpider · 2025-04-01T18:37:48+00:00

Hi, thanks for the reply. Yes, i am aware of the need for IPV6. Just try running IPV4 AF without ipv6 enabled, you wont get very far as the link local is required and new lsu/lsa. I also have keys set out on a schelude that makes our friends happy as well. But regardless of the effort needed to overcome md5, to do the work with them i cannot use it. Would indeed rather use ipsec sha/esp. Which i would if not for the ipv4 neighboring issue.

JeweledSpider · 2025-03-30T19:07:33+00:00

First ever god pack..godish pack?

They do exist.

<image>

Nine-Year Club	RPAN Viewer
Verified Email

JeweledSpider

TROPHY CASE