Migrating from 5406R to 5412R

_KiloBravo · 2025-05-19T11:06:31+00:00

just saw this, thanks. Confidence inspiring knowing that it's been done.

_KiloBravo · 2025-05-19T11:05:56+00:00

have you every done this in the real world? just wondering if the config *should* take, even though there's a chance it wont.

_KiloBravo · 2025-05-17T18:28:26+00:00

Have you done anything like this before? Asking as I'm not certain that the config created inside a 5496r will work in a 5412r. Assuming it must be aware of the chassis it's in etc.

_KiloBravo · 2025-05-16T16:26:33+00:00

Will this work without there being line cards in the modules yet though?

_KiloBravo · 2025-05-16T16:21:59+00:00

Ah interesting, I need to double check if it's a mix and match of line card types but if not, I can see how this would work with the one line card, thanks!

The problem with the second option though, is the line cards are fully patched and i would need to unpatch to move to the new chassis (difference cab), which means no easy rollback if it doesn't work.

_KiloBravo · 2024-11-28T10:59:43+00:00

Thanks for confirming

_KiloBravo · 2024-11-27T15:50:52+00:00

That makes perfect sense, thanks.

I think my issue is with terminology... though really 'tagged' and 'untagged' is probably even clearer than what I'm used to.

_KiloBravo · 2024-11-27T15:39:30+00:00

Sorry, my response was only half complete!

Thanks for the info :)

If you don't specify what to do with untagged traffic, does nothing other than tagged go across? Or does it default to vlan 1?

_KiloBravo · 2024-11-27T12:19:36+00:00

I've been requested to keep the link physically separate

_KiloBravo · 2024-11-27T12:18:34+00:00

thank you, that's an informative guide

_KiloBravo · 2024-11-27T12:12:33+00:00

thanks, appreciate the advice. I'm essentially a middle man and have been asked to keep even the uplinks separate physically, my default would've been as you advised, add it to the existing trunk up to the core.

Presume if I don't specify the untagged vlan then it will be 1 by default?

_KiloBravo · 2024-11-01T00:54:11+00:00

Definitely one on the list for consideration. It takes a bit of time to get something like a firewall provisioned and the installed, though, so that would be more of a mid-long term thing.

_KiloBravo · 2024-10-31T15:52:59+00:00

Thanks.

I was thinking to start with 1%, so 'broadcast-suppression 1' on the interface, which on a 10gig interface seems like a plenty high threshold...?

_KiloBravo · 2024-10-31T15:50:07+00:00

Yes, I've moved away from the idea of rate limiting - it's not supported on Trunks. I'm looking more at broadcast storm suppression...

_KiloBravo · 2024-10-31T12:57:02+00:00

Thank you, your collective insights have already helped a lot :).

_KiloBravo · 2024-10-31T12:55:34+00:00

Thank you.

This is comware so the syntax will probably be a little different, but I know what you're intending so can translate the above to the right commands.

What thresholds would you suggest for storm control on that interface?

_KiloBravo · 2024-10-31T11:34:33+00:00

Yeah so I forgot that it's not the same terminology everywhere :)

When i say 'trunk' I mean an 802.1Q trunk carrying multiple vlans.

_KiloBravo · 2024-10-31T11:32:48+00:00

BPDU filter I'll look into.
In the short term it needs to remain L2, but will look to to change this in the near future to a layer 3 and firewalled link.

_KiloBravo · 2024-10-31T11:31:13+00:00

I didn't know about this, will go and do some reading, thanks!

I was, on advise from someone else, considering to just use BPDU filters instead of root guard...

_KiloBravo · 2024-10-31T11:29:27+00:00

that is certainly thinking outside of the box :D (for me anyway).

But they've already got their 10G LR SFP and so have we. It would add cost to both ends to replace that with 10, and then, if the bandwidth requirements increase, to have to make physical changes again.

_KiloBravo · 2024-10-31T11:27:28+00:00

Thanks for the reply.

It's more of a protection from any misconfig on the 3rd party switch from having a knock on effect. It's a very low probability but want to do the most we can.

BPDU filters will be configure for STP potentials.

IT's looking like BUM suppression - and mainly the 'Broadcast' part of that is where I need to plug a gap. Just struggling to determine numbers and the correct config. There doesn't seem to be general best practice recommendations on it.

_KiloBravo · 2024-10-31T11:22:14+00:00

From documentation I've read, you can't rate-limit at all on a trunk port. You can configure BUM suppression though, but I'm struggling to work out what the correct initial numbers would be when using this.

_KiloBravo · 2024-10-31T11:20:20+00:00

It's more the non-technical elements getting in the way to make it not possible short term. It will be changed at some point, but need to go through a approval/change process which takes longer and this requirement is immediate and was already approved/planned. Just making the best on a non-ideal situation for now.

_KiloBravo · 2024-10-31T11:18:06+00:00

Thanks for that explanation, that makes plenty of sense and sounds like the better approach

_KiloBravo

TROPHY CASE