Switching

First off, I'm new to Juniper (and to most networking) so if I'm being stupid just say so and point me to what I'm missing.

I'm on 11.3R2.4.

I just got off the phone with Juniper support as I couldn't understand what was going on with mvrp. I have 4 switches where I created a few VLANs on the first one, set up 3 trunks, connected the other 3 switches to it and turned on mvrp.

I saw that the VLAN IDs had gotten passed around the other switches, but I can't use them for assignment. They show up in a show vlans from the standard prompt but from the configure prompt there's nothing there.

From JWeb if you try to change the VLAN config for a port, they show up in the list of available ones, but the commit fails.

So...what good is mvrp if all it does is pseudo copies the VLAN IDs around the network?

The switch will transport the vlans over trunks when it learns it by mvrp and vlan all isn't configured.

You have to configure vlans you will use on the local switch, but by default any switch that is just moving traffic on trunks won't know about the vlans and will not accept them on 802.1q trunks. mvrp allows those middle switches to know about the vlans and thus handle their traffic.

In a small environment, you may not find this useful. It can be a life saver in a huge switching environment. vlan pruning is also supported with mvrp, so if a vlan doesn't need to be on a trunk, it is not enabled on the trunk. This is the primary function of MVRP.

http://www.juniper.net/techpubs/en_US/junos/topics/example/bridging-mvrp-ex-series.html EX config example with 2 access switches and a distribution switch. You'll notice the vlans aren't configured on the distribution switch, but it will still switch the vlan traffic from one trunk to the other.

noob, So let me restate that so I know I'm getting it.

The purpose of mvrp is not end to end VLAN, it's just to fill in the spaces in between the core and edge switching? But then you don't turn on mvrp at the edge, you manually add the vlans so you can actually use them in assigning access ports?

This is a dev network, so while small, I'm actually trying to learn and understand things above: plug it in, oh look it's routing, next on the list.... ETA: and why does this forum insist I edit every post for paragra

You almost had it. It's configured at the edge, to propogate vlans through the core.

Consider, mvrp is defined in IEEE 802.1ak. It is an extention to 802.1q trunking for automatic management of those trunks (ie, this vlan needs to be on this trunk, this one doesn't). It is not a switch management protocol (unlike Cisco's proprietary VTP).

I hope that clarifies.

Gotcha.  The tech mentioned VTP...That sounds exactly like what I was hoping it did.  I mean, technically the system could do it as the propagation is already happening.  All it's missing is putting that info into the config so it can be assigned to trunks and access ports.  You'd be missing the original naming unless it got added to the protocol but at this point I'd settle for just being able to assign based on tag.

Thanks again.

There are pros and cons to the method. VTP suffers from "one idiot to crash them all" syndrom. It's the nature of the client/server model that it uses. MVRP is closer to a peer to peer model. By configuring a vlan locally on a switch and applying it to an access port, you've declared yourself an originator of the vlan. So long as there are 2 originators, they can be linked together automatically via MVRP. All unnecessary trunks will prune the vlan.There is no "freeze" of the vlan management when a switch goes offline.

Consider also that edge switches may not support as many vlans as the core switches. VTP fails in these scenarios. You have to kick the smaller switches into transparent mode or run multiple domains. I had this problem with C2950 switches.

I tend to agree with the sentiment that if you want every switch to contain every vlan (or subset) even when it's not using those vlans, an external configuration server is the way to go. It can, of course, be scripted as well.

@ Imanoob: Great contribition to the discussion! Kudos from me!