× Get free training on Switching for AV over IP and receive AVIXA Credits. Sign up at NETGEAR.academy
Reply

NETGEAR M4250-26G4XF-POE++ communication issues with an existing Cisco SG350-28P

Clocktime00
Aspirant

NETGEAR M4250-26G4XF-POE++ communication issues with an existing Cisco SG350-28P

Hi,

  There was an existing Cisco SG350-28P switch installed with two (2) VLANs.  We added a NETGEAR M4250-26G4XF-POE++ to the system because we needed the POE++ because of the new camera's power requirements.  We can't get the video or audio to pass between the switches and the uplink (up and down) is not passing data.  

 

  Is this a known issue and if so what can we do to make the Cisco & Netgear switches to play nice together?

 

Aaron 

Message 1 of 5
Clocktime00
Aspirant

Re: NETGEAR M4250-26G4XF-POE++ communication issues with an existing Cisco SG350-28P

Attached is the network design functional drawing for reference.

Message 2 of 5
DaneA
NETGEAR Employee Retired

Re: NETGEAR M4250-26G4XF-POE++ communication issues with an existing Cisco SG350-28P

@Clocktime00,

 

Welcome to the community! 🙂

 

Since there are VLANs configured on the Cisco SG350-28P switch and M4250-26G4XF-POE++, the ports connecting the 2 switches should be set as tagged (trunk) with a PVID of 1.

 

What is the current firmware of the M4250-26G4XF-POE++?
 

Let me share the following guides that might help you:
 

Tech Tips: Deep Dive Into the NETGEAR M4250 Series AV User Interface
 

NETGEAR M4250 Switch Series Product Overview & Demo



Regards,

 

DaneA

NETEGAR Community Team

Message 3 of 5
Clocktime00
Aspirant

Re: NETGEAR M4250-26G4XF-POE++ communication issues with an existing Cisco SG350-28P

Hi,

 

  Thank you for your reply.  

 

I think i may have got it. I found 2 problems. The main one is that one of the cisco switches is serving dhcp and the firmware on the netgear has a bug where dhcp can lock up the switch and the only way back in is a factory reset. So i updated to the latest firmware to fix that.

The other issue i think has something to do with the dedicated 10G lag ports on the cisco. There are no such ports on the netgear so my guess is that going from a cisco 10G to a netgear 1G was not going to work. So i switched from using the cisco 10G to a regular 1G and the network seems to be stable now. Im not sure if this is going to be stable in the long term though. Its been running for a couple of hours.

Wouldn’t setting a pvid on a trunk port completely negate the purpose of the vlan separation by tagging all traffic through that port as the same vlan?

Let me know if i’m misunderstanding

 

Thank you & glad to be here!

also as of yesterday the firmware is the latest available online

Message 4 of 5
schumaku
Guru

Re: NETGEAR M4250-26G4XF-POE++ communication issues with an existing Cisco SG350-28P


@Clocktime00 wrote:

The other issue i think has something to do with the dedicated 10G lag ports on the cisco. There are no such ports on the netgear so my guess is that going from a cisco 10G to a netgear 1G was not going to work. So i switched from using the cisco 10G to a regular 1G and the network seems to be stable now.


Lots of misunderstanding here (and in many posts around the wild Internet) wildly mixing marketing and tech terms. 

 

Keep it simple: If a port is only 10 GbE, a link can't be established to any other port fixed or configured a different speed. so configuring the port link speed to a known rate like 1 GbE can "fix" things.

 

This is unrelated to whatever brand is printed on the device.

 

Some vendors designate a set of ports, typically supporting higher link rates, or ports with different technology (like SFP/SFP+) as LAG ports. These are rarely predefined for LAG usage (parallel connection, concurrent connections to allow aggregated speed). not saying there could not be certain specific presets or defaults.

 


@Clocktime00 wrote:

Wouldn’t setting a pvid on a trunk port completely negate the purpose of the vlan separation by tagging all traffic through that port as the same vlan?


Not at all. The PVID term is part of the standards. The PVID "Port VLAN ID" is a default VLAN id applied to frames coming to the port. on "ingress". This is a term commonly used for non-Cisco switches (what does not say that Cisco SMB switches don't make use of this standard term). Usually, untagged frames are assumed for a certain VLAN.

On the usual trunk configurations, you transport multiple VLANs on a trunk, so both ends must be configured equally, with the VLAN tagged. Say you have VLAN 10, 20, and 30 these must be configured on the switch, if you intend to carry these VLANs over a trunk, define the port (or LAG) for VLAN 10 [T]agged,  VLAN 20 [T]agged,  VLAN 30 [T]agged on both ends. Possible exception can be _one_ VLAN, let's say for example VLAN 1, which you can designate to be operated untagged (like for consumer routers, unmanaged switches, ...). Then you define each end as member of VLAN 1, [U]ntagged (making the VLAN 1 frames to be sent out from the switch as untagged, and to over the other direction of untagged frames flowing into the switch, you define the port for PVID 1, so these become associated with the VLAN 1 on the switch.

Message 5 of 5
Top Contributors
Discussion stats
  • 4 replies
  • 2349 views
  • 0 kudos
  • 3 in conversation
Announcements

AV over IP Switches by NETGEAR