RE: 802.17 RPR and L2 Ethernet interoperablity (Ethernet over RPR)
Hello: I think this is pretty provider-specific. However, we are doing this right now with a particular vendor using their flavor of RPR. The ring uses Q in Q tunneling in the core and all switches communicate directly to one another using .1Q encapsulated frames. Mike
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of sam_ml@spacething.org Sent: Tuesday, July 06, 2004 11:50 AM To: nanog@nanog.org Subject: 802.17 RPR and L2 Ethernet interoperablity (Ethernet over RPR)
Hi,
This is probably a fairly simply question, I'm probably just not quite groking the layers involved here.
If I had the following setup:
Endstation A -- Switch A === RPR Ring === Switch B -- Endstation B
could there be a VLAN setup such that Endstations A and B are both in it, and can communicate as if they are on the same LAN segment? (And I mean natively. ie. not using an MPLS VPN). ie. Will the switches involved tranlate the different framing formats in use? Is this vendor dependent?
Sam
Thanks for the reply. Pretty much everyone has told me that it's vendor specific, although the implementation mentioned below sounds nice. Any chance of naming that vendor? One question about this, the Q-in-Q tunnelling would have to take place on the switch connected to the ring - what happens if the packet has already been placed in a dot1Q tunnel? I haven't really worked much with dot1Q tunneling - are their any know problems with extra tags? (aside from MTU issues, but I imagine most rings will support at least 9bytes) Sam On Tue, 6 Jul 2004, Michael Smith wrote:
Hello:
I think this is pretty provider-specific. However, we are doing this right now with a particular vendor using their flavor of RPR. The ring uses Q in Q tunneling in the core and all switches communicate directly to one another using .1Q encapsulated frames.
Mike
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of sam_ml@spacething.org Sent: Tuesday, July 06, 2004 11:50 AM To: nanog@nanog.org Subject: 802.17 RPR and L2 Ethernet interoperablity (Ethernet over RPR)
Hi,
This is probably a fairly simply question, I'm probably just not quite groking the layers involved here.
If I had the following setup:
Endstation A -- Switch A === RPR Ring === Switch B -- Endstation B
could there be a VLAN setup such that Endstations A and B are both in it, and can communicate as if they are on the same LAN segment? (And I mean natively. ie. not using an MPLS VPN). ie. Will the switches involved tranlate the different framing formats in use? Is this vendor dependent?
Sam
On Wed, 7 Jul 2004, Sam Stickland wrote:
One question about this, the Q-in-Q tunnelling would have to take place on the switch connected to the ring - what happens if the packet has already been placed in a dot1Q tunnel? I haven't really worked much with dot1Q tunneling - are their any know problems with extra tags? (aside from MTU issues, but I imagine most rings will support at least 9bytes)
Most switches will only see the outer tag and will thus be transparent for Q-in-Q:ed packets. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Wed, 7 Jul 2004, Mikael Abrahamsson wrote:
On Wed, 7 Jul 2004, Sam Stickland wrote:
One question about this, the Q-in-Q tunnelling would have to take place on the switch connected to the ring - what happens if the packet has already been placed in a dot1Q tunnel? I haven't really worked much with dot1Q tunneling - are their any know problems with extra tags? (aside from MTU issues, but I imagine most rings will support at least 9bytes)
Most switches will only see the outer tag and will thus be transparent for Q-in-Q:ed packets.
That was my worry - the definition of most. 99% of switches or 60%? This isn't actually a standard is it, so I presume this behaviour is expected, but not required? Sam
On Wed, 7 Jul 2004, Sam Stickland wrote:
That was my worry - the definition of most. 99% of switches or 60%? This isn't actually a standard is it, so I presume this behaviour is expected, but not required?
The only way to make sure is to try, but with my (I guess) average insight in ethernet headers I don't see how a double tagged packet would be treated differently by a non Q-in-Q aware switch as long as there is no MTU issue. -- Mikael Abrahamsson email: swmike@swm.pp.se
participants (3)
-
Michael Smith -
Mikael Abrahamsson -
Sam Stickland