Moving Servers to a new switch

[BIS]

Hi All,

Soon I will be moving the CM servers to a new switch.

Each server has 2 ports connected, plus the duplication cable. ETH0 and ETH2.

When I look at how the ports are currently configured (on a cisco 3750), I notice a mix of access ports and trunk ports.

Does anyone know the recommended switch port settings for the servers?

 

[kyle555]

depends on the models and software versions and connectivity. R6 system platform? IPSIs? Dedicated/redundant control networks for the IPSIs?

autonegotiate is recommended now, wasn't before. Google "avaya communication manager administration network connectivity" for your release

 

[BIS]

CM6.3 with 4x G650 IPSIs (2 standby) if that helps.

 

[kyle555]

then they're probably just access ports on the duplex servers, check system platform for how those nics are configured - maybe you've got bonded nics on each server and want to avoid a switching loop. I'd say just follow whatever you were doing on the old switches or check the network connectivity guide to make darn sure.

 

[BIS]

Yeah I will do that - the problem is in this case the netwrok was set up by someone else :-(

SO I have a mix of access and trunk ports. As an example, the CLAN that CMS uses is a trunk port, but all the rest are access ports.

Server A has one trunk port, one access port.
Server B the same.

Its a mess.

I will set it up properly, and update this thread should anyone else want to know...

 

[phoneguy55]

I only use access ports these days. Haven't used a trunk port in a LONG time...

 

[BIS]

thanks phoneguy55 - I will go that way then

 

[BIS]

I am running in to a strange issue here...

For example, a standard VAL board (but the same thing happens on a standby IPSI board).
From a laptop I have a continuous ping running.
Switch ports are configured identical on the new switch as on the old.
I unplug the cable from the VAL – ping stops responding
Plug in the new cable – nothing happens
Wait a bit, still nothing
Plug the old cable back in again, and ping resumes responding.

I have tried with several cables so it is not a cable issue.
I have configured a laptop to be in the exact same subnet (for example, VAL is 10.2.132.13, I make laptop 10.2.132.23), and on the laptop the new port works as expected.

So something is happening on the PBX level – any idea?

Do I need to busy out a board just to plug it in to a new network switch?

This is pure layer 2 stuff by the way.

 

[Wanebo]

Sounds like trunking to the new switch from your network is not set up correctly.

 

[BIS]

I thought about that as well.

I patched the standby CM server though, also on the 10.2.133.0/24 network on the new switch, and that works just fine.

 

[kyle555]

What about cabled right to the VAL board from your laptop? Does it take the same time to resume? What about with a laptop on it's data switch in it's VLAN and trying again?

Maybe it's just layer 2 convergence stuff like old spanning tree is on and not RSTP.

https://networkengineering.stackexc...t-a-big-ball-of-semantics-whats-the-main-diff

Maybe one of your lan guys read up on Avaya gateways, saw 450's, noticed they had a data switch in 'em, and considers everything on your G650 to potentially be a data switch and he has old school spanning tree on just to make sure your VAL board causes a switching loop.

 

[BIS]

After much trial and error, we found that we had to disable portfast and bpduguard on the old 3750 stacks for this to work. Who knew a VAL board sends bpdus...

We still can't get it to work on the new nexus 9000 series though.

We have this cryptic reply:
" Note: the newer Cisco switches with the NX-OS operating system like the Cisco 9000 have an issue detecting older low level devices like CLANS and NIUs. There is an auto setting within the Cisco the needs to be turned off."

Anyone know what auto setting this is?

 

[kyle555]

I think they're saying lock the interface at 100Full and not autodetect?

And hey, I guess I was on the right track, but thanks for the heads up. I had no idea VAL boards sent BPDUs. Ha.

 

[BIS]

Actually I got this working. The mystery command, should anyone else run into this is

no negotiate auto

Here is the port config of the Nexus

interface Ethernet1/10
switchport access vlan [your vlan]
spanning-tree port type normal
duplex full
speed 100
no negotiate auto
service-policy type qos input TRUSTED-N3K2

Without the no negotiate auto, the port wouldn't even light up.