Mailing List Archive: nsp: extreme

vman compatibility

Index | Next | Previous | View Threaded

Laurent.Henry at ehess

Nov 19, 2008, 11:33 PM

Post #1 of 8 (4968 views)
Permalink

vman compatibility

Hello,
Does anyone know the compatibility of extreme networks VMan
ethernet encapsulation with other vendors 802.1ad/QinQ ?

I've read 88a8 Ethertype is used which, i think, can't be understood by Cisco
or Juniper which can use 8100/9100/9200...

Thanks

_______________________________________________
extreme-nsp mailing list
extreme-nsp [at] puck
https://puck.nether.net/mailman/listinfo/extreme-nsp

nsubugr at itxpertz

Nov 19, 2008, 11:55 PM

Post #2 of 8 (4788 views)
Permalink

Re: vman compatibility [In reply to]

Hello Laurent,

> Does anyone know the compatibility of extreme networks VMan
> ethernet encapsulation with other vendors 802.1ad/QinQ ?
>

It's compatible and should be able to work with any other vendor
because it's an IEEE standard and implemented across, which model of
extreme networks are using?

> I've read 88a8 Ethertype is used which, i think, can't be understood by Cisco
> or Juniper which can use 8100/9100/9200...
>

Just out of curiosity do you have Jumbo frames enabled while OR before
configuring the Mac-in-Mac OR QinQ? STAG?

configure vman ethertype 0x9100 primary
configure vman ethertype 0x8100 secondary

Should be able to do the job.

Are you doing any multicasting?

--
Regards,

Ronald Nsubuga,
skype: nsptash

"I don't speak for anybody but myself - that's enough trouble"
_______________________________________________
extreme-nsp mailing list
extreme-nsp [at] puck
https://puck.nether.net/mailman/listinfo/extreme-nsp

Anders.Gustavsson at tdc

Nov 19, 2008, 11:57 PM

Post #3 of 8 (4816 views)
Permalink

Re: vman compatibility [In reply to]

Hi,

The Etertype is also configurable in Extreme Networks series of products..

Extremeware:
conf dot1q ethertype 9100
ena jumbo-frame ports all

In XOS you have to enter the Ethertype in Hex..

Regards
Anders Gustavsson

-----Ursprungligt meddelande-----
Från: extreme-nsp-bounces [at] puck [mailto:extreme-nsp-bounces [at] puck] För Laurent HENRY
Skickat: den 20 november 2008 08:33
Till: extreme-nsp [at] puck
Ämne: [e-nsp] vman compatibility

Hello,
Does anyone know the compatibility of extreme networks VMan ethernet encapsulation with other vendors 802.1ad/QinQ ?

I've read 88a8 Ethertype is used which, i think, can't be understood by Cisco or Juniper which can use 8100/9100/9200...

Thanks

_______________________________________________
extreme-nsp mailing list
extreme-nsp [at] puck
https://puck.nether.net/mailman/listinfo/extreme-nsp
_______________________________________________
extreme-nsp mailing list
extreme-nsp [at] puck
https://puck.nether.net/mailman/listinfo/extreme-nsp

Laurent.Henry at ehess

Nov 20, 2008, 12:08 AM

Post #4 of 8 (4783 views)
Permalink

Re: vman compatibility [In reply to]

Le Jeu 20 novembre 2008 08:55, Ronald Nsubuga a écrit :
> Hello Laurent,
>
>> Does anyone know the compatibility of extreme networks VMan
>> ethernet encapsulation with other vendors 802.1ad/QinQ ?
>>
>
> It's compatible and should be able to work with any other vendor
> because it's an IEEE standard and implemented across, which model of
> extreme networks are using?

A "small" summit 48si.

>
>> I've read 88a8 Ethertype is used which, i think, can't be understood by
>> Cisco
>> or Juniper which can use 8100/9100/9200...
>>
>
> Just out of curiosity do you have Jumbo frames enabled while OR before
> configuring the Mac-in-Mac OR QinQ? STAG?
>
> configure vman ethertype 0x9100 primary
> configure vman ethertype 0x8100 secondary

This means 0x9100 as the vman type and 0x8100 to keep encapsulated packet
type ?
>
> Should be able to do the job.
No jumbo frames yet (i don't think something could go wrong there), i
guess this is needed since packets are getting 4 bytes longer.

Neither such encapsulations yet, i am studying it seriously for future
uses before doing the jump.

i've read some doc which raised a big interrogation to me:
http://apps.extremenetworks.com/libraries/techbriefs/Metro_TG_vMAN.asp
especially "cons" part

>
> Are you doing any multicasting?
>
> --
> Regards,
>
> Ronald Nsubuga,
> skype: nsptash
>
> "I don't speak for anybody but myself - that's enough trouble"
> _______________________________________________
> extreme-nsp mailing list
> extreme-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/extreme-nsp
>

_______________________________________________
extreme-nsp mailing list
extreme-nsp [at] puck
https://puck.nether.net/mailman/listinfo/extreme-nsp

swmike at swm

Nov 20, 2008, 12:17 AM

Post #5 of 8 (4786 views)
Permalink

Re: vman compatibility [In reply to]

On Thu, 20 Nov 2008, Laurent HENRY (EHESS/CRI) wrote:

> A "small" summit 48si.
>
> This means 0x9100 as the vman type and 0x8100 to keep encapsulated packet
> type ?

On the i-chipset platform the "vman" is just a way to change the switches
behaviour when it comes to "what is a vlan encapsulated packet".

So changing it to 0x9100, means the switch will L2 switch 0x8100 like any
other packet, because it'll stop recognising standard .1q frames as being
.1q encapsulated.

--
Mikael Abrahamsson email: swmike [at] swm
_______________________________________________
extreme-nsp mailing list
extreme-nsp [at] puck
https://puck.nether.net/mailman/listinfo/extreme-nsp

Laurent.Henry at ehess

Nov 20, 2008, 1:10 AM

Post #6 of 8 (4796 views)
Permalink

Re: vman compatibility [In reply to]

Hi and thank you.

What i want to do is enabling vman/qinq on the outside to tunnel my
internal vlans ID through my provider network with the 48si and catch it
back on another network across my provider's one the same way.

So in what i understand today, it would be necessary to validate dot1q
jumbo, adjust primary/secondary vman tags to make ethernet encapsulation
possible, and configure a suitable primary vman ID on my provider access
port, let's say on only port number 1.

By the way, other switch ports with internal classic dot1q trafic don't
have to change at all and still recognize 0x8100, changes just have to
apply to outside access port to cross another network.

As it seems,it does not seem possible that way with this i-chip then...

Le Jeu 20 novembre 2008 09:17, Mikael Abrahamsson a écrit :
> On Thu, 20 Nov 2008, Laurent HENRY (EHESS/CRI) wrote:
>
>> A "small" summit 48si.
>>
>> This means 0x9100 as the vman type and 0x8100 to keep encapsulated
>> packet
>> type ?
>
> On the i-chipset platform the "vman" is just a way to change the switches
> behaviour when it comes to "what is a vlan encapsulated packet".
>
> So changing it to 0x9100, means the switch will L2 switch 0x8100 like any
> other packet, because it'll stop recognising standard .1q frames as being
> .1q encapsulated.
>
> --
> Mikael Abrahamsson email: swmike [at] swm
> _______________________________________________
> extreme-nsp mailing list
> extreme-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/extreme-nsp
>

_______________________________________________
extreme-nsp mailing list
extreme-nsp [at] puck
https://puck.nether.net/mailman/listinfo/extreme-nsp

swmike at swm

Nov 20, 2008, 1:19 AM

Post #7 of 8 (4785 views)
Permalink

Re: vman compatibility [In reply to]

On Thu, 20 Nov 2008, Laurent HENRY (EHESS/CRI) wrote:

> What i want to do is enabling vman/qinq on the outside to tunnel my
> internal vlans ID through my provider network with the 48si and catch it
> back on another network across my provider's one the same way.

It's not a per port feature on i-chipset, it's per box. So effectively,
you have to do it at the CPE level if you don't want to change your core,
so your core uses 0x8100, CPE uses 0x9100, to encapsulate the customer
0x8100 traffic (three vlan tags).

This of course means you have to do management of the CPE within the
provider vlan.

> As it seems,it does not seem possible that way with this i-chip then...

Correct.

--
Mikael Abrahamsson email: swmike [at] swm
_______________________________________________
extreme-nsp mailing list
extreme-nsp [at] puck
https://puck.nether.net/mailman/listinfo/extreme-nsp

Laurent.Henry at ehess

Nov 20, 2008, 1:39 AM

Post #8 of 8 (4798 views)
Permalink

Re: vman compatibility [In reply to]

This is not really what i was expecting since i have to find another way
to do what i need but many thanks for your grateful help.

Le Jeu 20 novembre 2008 10:19, Mikael Abrahamsson a écrit :
> On Thu, 20 Nov 2008, Laurent HENRY (EHESS/CRI) wrote:
>
>> What i want to do is enabling vman/qinq on the outside to tunnel my
>> internal vlans ID through my provider network with the 48si and catch it
>> back on another network across my provider's one the same way.
>
> It's not a per port feature on i-chipset, it's per box. So effectively,
> you have to do it at the CPE level if you don't want to change your core,
> so your core uses 0x8100, CPE uses 0x9100, to encapsulate the customer
> 0x8100 traffic (three vlan tags).
>
> This of course means you have to do management of the CPE within the
> provider vlan.
>
>> As it seems,it does not seem possible that way with this i-chip then...
>
> Correct.
>
> --
> Mikael Abrahamsson email: swmike [at] swm
> _______________________________________________
> extreme-nsp mailing list
> extreme-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/extreme-nsp
>

--
Laurent HENRY
Administrateur Systèmes & Réseaux/RSSI
EHESS - Centre de Ressources Informatiques
54 Boulevard Raspail 75006 Paris
01.49.54.23.61

_______________________________________________
extreme-nsp mailing list
extreme-nsp [at] puck
https://puck.nether.net/mailman/listinfo/extreme-nsp

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads