Intra-switch VLANs Netgear

I've been going over and testing this vlan problem for a long time now and still can't get too far. I've read up a significant amount on how this should work and I'm mainly getting confused between Netgear and Cisco's interpretations of what each feature does. Here is a diagram of what I think I should have. Ideally, I have a GSM7324 switch with a whole class C cut up among it. This core switch feeds into (right now just one) layer 2 switch which has corresponding vlans. These switches talk to each other and out the gateway. The vlans right now can talk to each other via routing on the switch which is okay. I can do those ACLs after this step is completed. Here is an image of the basic structure:

http://157.238.136.5/cage-fixup.jpg The main problem is that I cannot get the two switches uplinked to each other. I need machines on vlan 17 to be able to talk to the layer 3 switch and therefore every other subnet on the layer 3 switch. If I uplink them as diagramed things start to act like a broadcast storm on the layer 3 switch. This shouldn't be the case because the ports that are uplinked are different and on different vlans. Netgear told me that there wasn't a feature like 'Cisco Trunking' on the switches so thats why the multiple uplinks. If there is a way to do it with one uplink cable that is obviously the preferred method. Everything on the layer 2 switch in vlan #3 can get to the layer 3 switch and the Internet. If I plug my laptop directly into vlan #17 on the layer3 switch that works as well. Let me know any ideas or thoughts on how I could have this wrong and make it right.

Thanks, Adam

Reply to
amattina
Loading thread data ...

It is documented as supporting trunks. ftp://downloads.netgear.com/files/gsm7312_gsm7324_fsm7326p_adminguide.pdf Chapter 3, examples #2 and #3 Also, the introduction in Chapter 3 says specifically,

"A given port may handle traffic for more than one VLAN, but it can only support one default VLAN ID."

If you cannot get the GSM7324 to handle multiple VLANs on the same port using the procedures documented there, then get a refund on the switch.

(Oh wait, this is Netgear, it is corporate policy that you *can't* get a refund on the switch; the most you can do is exchange in endless succession hoping that -eventually- you will get one that they have fixed the feature on.)

Reply to
Walter Roberson

Thanks for your response. Trust me, I know the frustration of working with half-ass quality equipment and poor documentation. This document you linked to didn't exist when this problem started. Its just time to get back around to solving this one now. I'll check it out.

Reply to
amattina

That document is endlessly confusing... The pictures don't match the commands...the interfaces are totally different and they don't mention what the configuration should be like on the other end of the switch. What about the layer 2 switch configuration? Its a near miracle that I got the IP configuration on this switch correct and that its actually routing inbetween the subnet interfaces.

Isn't the po> Thanks for your response. Trust me, I know the frustration of working

Reply to
amattina
[netgear GSM7324]

You were using multiple ports to communicate between the devices because Netgear told you there was no trunking facility... but there is. So you only need one cable between the two devices, and you want the ports set up to carry all the VLANs needed to trunk between the two.

Look in Chapter 5 "IP Routing Services" of the manual, and in particular at the section "VLAN Routing".

I draw particular attention to the command section of Example 2, which enables routing on the vlans, ending in "show ip vlan". The explanatory main text after that says,

This returns the logical interface IDs that will be used instead of slot/port in subsequent routing commands. Assume that VLAN 10 is assigned ID 3/1 and VLAN 20 is assigned ID 3/2.

What this is hiding is the fact that when you configure routing on a VLAN interface, there is no predetermined interface name that will be used to refer to the VLAN. For example, if you enable routing on VLAN 179, then there is NO interface created named anything like "vlan179" or "3/179", or any other fixed predictable interface name. Instead, what you get is the next available interface number in the

3 series on card 1, which is to say the next available number in the series starting 1/3/ . So the first VLAN created is 1/3/1, the second is 1/3/2, and so on, no matter what the VLAN tag numbers are. And those are the names you have to use to configure IP addresses and so on against.

Yes, this -does- mean that you cannot automate VLAN additions without using an "expect" script [or equivilent] smart enough to "show ip vlan" and pick out the interface numbers already in use and carefully fill in the holes. You have to pay close attention to "show ip vlan" because that's the only way to determine the interface number you have to configure the layer 3 information against.

If you want some real fun, try measuring the performance of vlan routing. Or better yet, run some multicasting...

Reply to
Walter Roberson

The document has been around and accessible since the GSM7324 was released a few years ago. I remember long nights of tearing out my hair...

Reply to
Walter Roberson

So if I have one port linnking the two switches together, this port has to be a member of all vlans that I want sent accross the link, correct? This port needs to be a tagged member of all those vlans correct?

Thanks for the help, I th> >

Reply to
amattina

Right.

Not necessarily: one of them could be the 'native' VLAN for the port, which would be sent across untagged.

It isn't uncommon to run into problems if the native vlan is left at 1 (the usual default) -- vlan 1 tends to be the one used for management traffic (some of which should not be leaking all over the LAN), and vlan 1 tends to be the one used when lower quality switches get confused about which vlan something should be put in (and if your switches are confused, you probably don't want the data getting very far.)

Some people want to be sure that everything that goes across the link is tagged. The proper way to do this is not Linksys's control statements that force everything to be tagged: the proper way is to use a native VLAN that is otherwise unused (so no traffic can be sourced into it, and no traffic will flow out of it on the other side if somehow traffic does get sourced into it.)

Reply to
Walter Roberson

Okay. I think I'm understanding this. Right now we're worrying about getting functionality out of this damn thing. Again, two ports on the

7324 in different VLANs, and four ports on the 726 with two in different vlans.

IE.

############# # 7324 # ############# | |

-----------------Port3, PVID3, VLAN3, Server Machine II Port 3 ------ Port17, PVID17, VLAN17, Server Machine PVID 3 VLAN 3 | | ########### # 726 # ########### | | | | PVID3 PVID17

Need to have PVID 3 needs to talk to PVID3 on both switches. So what I THINKI need to do is the following:

Include Port 3 on both VLANS on both switches. Make this port tagged on both switches in both VLANS. Will that get the two VLANS talking to each other accross the switches? Once I can do this to just the two vlans I have about 8 other vlans to 'transport' aaccross this 'trunk' link.

Let me know what you think.

Thanks for your help Walter.

- Adama Walter Robers> >

Reply to
amattina

I think you would do fine if you configured port 3 as follows:

- PVID 3 on both ends of the link

- Untagged for VLAN 3

- Member of VLAN 17 and tagged for that VLAN

In this way, VLAN 3's traffic gets around all over untagged while VLAN 17 is untagged on the access ports (at the bottom switch) and goes across the trunk link tagged. Any other VLANs that you want to add to the inter-switch link must also be tagged.

Anoop

Reply to
anoop

And PVID 17 as well.

That's not right: port 3 on the 7324 should be an untagged port that is only in PVID3. The port that needs to be a member of both PVID 3 and PVID 17 is the port which is the link from the 7324 to the 724, and on the 724 the port that would need to be in both would be the one that links to the 7324. [I can't tell from your earlier diagram or this one which ports are being used for the links, so I can't give exact port numbers.]

On each switch, the port the links across to the other switch should be a trunk which is a member of all the PVIDs that are to be carried across the link.

Usually only the trunk ports are tagged ports; the other ports are access ports that are members only of the PVID appropriate for the device connected to them.

Reply to
Walter Roberson

Great. Thanks for the patient explaination. I am going to try this out. Maint. window is a night next week so I will let you know how it goes.

Thanks guys.

- Adam Walter Robers> > >Again, two ports on the

Reply to
amattina

Everything went great. Thanks very much. Is this the same sort of setup/concept that a cisco or other brand switches would go through as far as port assignments?

I guess the next step is gett> Great. Thanks for the patient explaination. I am going to try this

Reply to
amattina

That's pretty much how it should work on any 802.1Q-compliant switch.

Anoop

Reply to
anoop

Yes, but the command structures can vary enough to make it -look- like you are doing something completely different. That's particularily the case when you start mixing port-based VLANs (i.e., a set of ports are bridged together at layer 2) with routing VLANs (i.e., the bridged set of ports is assigned a virtual interface that then has an IP assigned to it and participates in routing.)

What you can -do- with a port or a VLAN is much more advanced on some of the other devices such as a Cisco Catalyst 3750.

Also, some devices (e.g. Nortel Baystack series) allow packets to be automatically directed into different VLANs depending on the packet type -- so for example you might have an IPX VLAN on a port that is distinct from the 802.3 VLAN. e.g., no point sending NETBIOS traffic to a segment with no NETBIOS- capable devices.

Reply to
Walter Roberson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.