Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: foundry

Preserving double-tagged traffic on ICX6100

 

 

nsp foundry RSS feed   Index | Next | Previous | View Threaded


frnkblk at iname

Apr 20, 2012, 12:50 PM

Post #1 of 20 (2789 views)
Permalink
Preserving double-tagged traffic on ICX6100

We're having difficulty moving double-tagged traffic through the ICX6100.
The inner tag (235) is being removed somewhere inside the Brocade because
packet captures from the Brocade's ingress port (tagged 1048) show two tags
while the Brocade's egress port (tagged 1048) shows one tag (captures
attached). What's left is the outer tag (1048) with the contents of the
payload.

Both have tags have TPIDs of 0x8100.

Any reason why is this happening? Why is the switch doing anything with the
inner tag?

Frank


begin 666 double-tagged.pcap
MU,.RH0(`! ```````````/__```!````MIB13ZIY`@!$````1 ```/______
M_P`5K0HZ7X$`!!B!``#K" 8``0@`!@0``0`5K0HZ7PH`B!8````````*`(@>
2````````````````````````
`
end

begin 666 single-tagged.pcap
MU,.RH0(`! ```````````/__```!````59:13PX%``! ````0 ```/______
M_P`5K0HZ7X$`!!@(!@`!" `&! `!`!6M"CI?"@"(%@````````H`B!X`````
.````````````````````
`
end

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


foundry-nsp at ergens

Apr 22, 2012, 3:00 AM

Post #2 of 20 (2732 views)
Permalink
Re: Preserving double-tagged traffic on ICX6100 [In reply to]

>
> Any reason why is this happening?  Why is the switch doing anything with the
> inner tag?

What is your switch config?
I haven't had my hands on a ICX yet however it looks indeed like
something is wrong.
However maybe some tips could help... did you check jumbo-frames,
super-aggregated vlan support etc? Could you try with another tag-type
for the outer-vlan? I prefer using it that way (different tag-types
for inner and outer vlan).

regards, Igor

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


frnkblk at iname

Apr 22, 2012, 6:55 AM

Post #3 of 20 (2737 views)
Permalink
Re: Preserving double-tagged traffic on ICX6100 [In reply to]

I've turned jumbo-frames on, but have done nothing with super-aggregated
vlan support. My understand is that it's for Q-in-Q support, and my
application has double-tagged traffic that passes through the ICX, keyed on
the outer tag. As I've said before, why does the switch even look past the
outer tag?

I can't use another tag-type for the outer tag. Even if I could, I would
still say the ICX shouldn't be manipulating or caring about inner tags.

Frank

-----Original Message-----
From: igor [at] ergens [mailto:igor [at] ergens] On Behalf Of Igor Ybema
Sent: Sunday, April 22, 2012 5:00 AM
To: frnkblk [at] iname
Cc: foundry-nsp [at] puck
Subject: Re: [f-nsp] Preserving double-tagged traffic on ICX6100

>
> Any reason why is this happening?  Why is the switch doing anything with
the
> inner tag?

What is your switch config?
I haven't had my hands on a ICX yet however it looks indeed like
something is wrong.
However maybe some tips could help... did you check jumbo-frames,
super-aggregated vlan support etc? Could you try with another tag-type
for the outer-vlan? I prefer using it that way (different tag-types
for inner and outer vlan).

regards, Igor



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


frnkblk at iname

Apr 22, 2012, 7:08 PM

Post #4 of 20 (2734 views)
Permalink
Re: Preserving double-tagged traffic on ICX6100 [In reply to]

Thanks to the person who contacted me offlist -- I've been pointed to defect
377562, which I'm told is fixed on the FLS but not the ICX.

"Q-in-Q removes the original customer's tag for broadcast"

Frank

-----Original Message-----
From: foundry-nsp-bounces [at] puck
[mailto:foundry-nsp-bounces [at] puck] On Behalf Of Frank Bulk -
iName.com
Sent: Friday, April 20, 2012 2:51 PM
To: foundry-nsp [at] puck
Subject: [f-nsp] Preserving double-tagged traffic on ICX6100

We're having difficulty moving double-tagged traffic through the ICX6100.
The inner tag (235) is being removed somewhere inside the Brocade because
packet captures from the Brocade's ingress port (tagged 1048) show two tags
while the Brocade's egress port (tagged 1048) shows one tag (captures
attached). What's left is the outer tag (1048) with the contents of the
payload.

Both have tags have TPIDs of 0x8100.

Any reason why is this happening? Why is the switch doing anything with the
inner tag?

Frank


begin 666 double-tagged.pcap
MU,.RH0(`! ```````````/__```!````MIB13ZIY`@!$````1 ```/______
M_P`5K0HZ7X$`!!B!``#K" 8``0@`!@0``0`5K0HZ7PH`B!8````````*`(@>
2````````````````````````
`
end

begin 666 single-tagged.pcap
MU,.RH0(`! ```````````/__```!````59:13PX%``! ````0 ```/______
M_P`5K0HZ7X$`!!@(!@`!" `&! `!`!6M"CI?"@"(%@````````H`B!X`````
.````````````````````
`
end

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


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


foundry-nsp at ergens

Apr 23, 2012, 12:44 AM

Post #5 of 20 (2733 views)
Permalink
Re: Preserving double-tagged traffic on ICX6100 [In reply to]

> Thanks to the person who contacted me offlist -- I've been pointed to defect
> 377562, which I'm told is fixed on the FLS but not the ICX.
>
> "Q-in-Q removes the original customer's tag for broadcast"
>

Thanks for sharing. Will receive a couple of ICX's soon and I will
test this asap also. Hopefully Brocade will fix it soon.

regards, igor
_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp


foundry-nsp at ergens

Apr 23, 2012, 12:49 AM

Post #6 of 20 (2735 views)
Permalink
Re: Preserving double-tagged traffic on ICX6100 [In reply to]

>> Thanks to the person who contacted me offlist -- I've been pointed to
defect
>> 377562, which I'm told is fixed on the FLS but not the ICX.
>>
>> "Q-in-Q removes the original customer's tag for broadcast"
>>
>
> Thanks for sharing. Will receive a couple of ICX's soon and I will
> test this asap also. Hopefully Brocade will fix it soon.

Just checked the release notes for 7.4. This reports that is is fixed in
this release. It was introduced in 7.3. Could you try and upgrade?

regards, igor


Arjan at voiceworks

Apr 23, 2012, 12:59 AM

Post #7 of 20 (2729 views)
Permalink
Re: Preserving double-tagged traffic on ICX6100 [In reply to]

On 23 apr. 2012, at 09:49, Igor Ybema wrote:
>
> >> Thanks to the person who contacted me offlist -- I've been pointed to defect
> >> 377562, which I'm told is fixed on the FLS but not the ICX.
> >>
> >> "Q-in-Q removes the original customer's tag for broadcast"
> >>
> >
> > Thanks for sharing. Will receive a couple of ICX's soon and I will
> > test this asap also. Hopefully Brocade will fix it soon.
>
> Just checked the release notes for 7.4. This reports that is is fixed in this release. It was introduced in 7.3. Could you try and upgrade?

According to the TAC it has been fixed for the FCX, not for the ICX. I've been hitting the this issue as well. Since the TAC claimed it was not yet fixed for ICX I didn't bother upgrading but I'm curious for your testing results.

--
Met vriendelijke groet,

Arjan van der Oest
Senior Network Engineer / Security Officer

Voiceworks BV - Oplagestraat 1 - 1321 NK Almere
Attachments: smime.p7s (4.69 KB)


frnkblk at iname

Apr 23, 2012, 5:21 AM

Post #8 of 20 (2740 views)
Permalink
Re: Preserving double-tagged traffic on ICX6100 [In reply to]

I'm running 7.4 on the ICX:



UNIT 1: compiled on Mar 02 2012 at 11:41:58 labeled as FCXS07400

(5691971 bytes) from Primary FCXS07400.bin

SW: Version 07.4.00T7f1



As someone else stated, it was fixed in one code line but not the ICX.



Regards,



Frank



From: igor [at] ergens [mailto:igor [at] ergens] On Behalf Of Igor Ybema
Sent: Monday, April 23, 2012 2:50 AM
To: Frank Bulk
Cc: foundry-nsp [at] puck
Subject: Re: [f-nsp] Preserving double-tagged traffic on ICX6100





>> Thanks to the person who contacted me offlist -- I've been pointed to
defect

>> 377562, which I'm told is fixed on the FLS but not the ICX.

>>

>> "Q-in-Q removes the original customer's tag for broadcast"

>>

>

> Thanks for sharing. Will receive a couple of ICX's soon and I will

> test this asap also. Hopefully Brocade will fix it soon.



Just checked the release notes for 7.4. This reports that is is fixed in
this release. It was introduced in 7.3. Could you try and upgrade?



regards, igor


frnkblk at iname

Apr 23, 2012, 7:10 PM

Post #9 of 20 (2731 views)
Permalink
Re: Preserving double-tagged traffic on ICX6100 [In reply to]

My Brocade SE is telling me the ICX code for 7.4 has the fix. Can you pass
to me, offline the contact info for the TAC person who says it's not fixed
on the ICX?



Thanks,



Frank



From: Arjan Van Der Oest [mailto:Arjan [at] voiceworks]
Sent: Monday, April 23, 2012 2:59 AM
To: Igor Ybema
Cc: Frank Bulk; foundry-nsp [at] puck
Subject: Re: [f-nsp] Preserving double-tagged traffic on ICX6100



On 23 apr. 2012, at 09:49, Igor Ybema wrote:



>> Thanks to the person who contacted me offlist -- I've been pointed to
defect

>> 377562, which I'm told is fixed on the FLS but not the ICX.

>>

>> "Q-in-Q removes the original customer's tag for broadcast"

>>

>

> Thanks for sharing. Will receive a couple of ICX's soon and I will

> test this asap also. Hopefully Brocade will fix it soon.



Just checked the release notes for 7.4. This reports that is is fixed in
this release. It was introduced in 7.3. Could you try and upgrade?



According to the TAC it has been fixed for the FCX, not for the ICX. I've
been hitting the this issue as well. Since the TAC claimed it was not yet
fixed for ICX I didn't bother upgrading but I'm curious for your testing
results.



--
Met vriendelijke groet,

Arjan van der Oest
Senior Network Engineer / Security Officer

Voiceworks BV - Oplagestraat 1 - 1321 NK Almere


foundry-nsp at ergens

May 5, 2012, 2:44 AM

Post #10 of 20 (2670 views)
Permalink
Re: Preserving double-tagged traffic on ICX6100 [In reply to]

Hi All,
Just tested with an ICX 6430-24 running 7.4.00T311. Can not reproduce
the case right now.

With tag-type set to 0x9100, edge-port to untagged and uplink port to
tag, I see both outer and inner-tags on the uplink. (0x9100 outer,
0x8100 inner).
With tag-profile set to 0x9100, edge-port to untagged, tag-profile
enabled, uplink port to tag and tag-profile disabled, I see both outer
and inner-tags on the uplinks (this time both 0x8100 on the uplink)

All are broadcasts, arps. aggregated-vlan enabled

@frank: could you share your config part related to the double tagging?



regards, Igor
_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp


frnkblk at iname

May 5, 2012, 9:33 AM

Post #11 of 20 (2668 views)
Permalink
Re: Preserving double-tagged traffic on ICX6100 [In reply to]

Our regional Brocade reseller shared last week Friday during an onsite visit
that he had two other customers with the same issue. One of them is a
neighboring service provider and contacted me the other day.

Since my initial posting a lot of progress has been made. Brocade
reproduced the issue without using an ICX stack or LAG and it happens on
both 1G and 10G interfaces. Issue appears to be tied to broadcast packets.
Defect 400064 has been created to track this issue and a request has been
made to engineering for the fix to be worked into 7.3.0d and 7.4.0a.
Brocade has not completed the fix and there's no specificity in regards to
the release dates of those two new releases.

My testing used 0x8100 for both inner and outer and no aggregated-VLAN.
Nothing special about configuration --
vlan 1048
tagged ethe 1/3/1 ethe 2/3/1

Traffic goes in and out 1/3/1 and out 2/3/1. VLAN tag 235 is the inner tag.
Nothing about VLAN 235 is configured on the ICX6100 -- it doesn't need to
be. Yet VLAN tag 235 is stripped out.

Frank

-----Original Message-----
From: foundry-nsp-bounces [at] puck
[mailto:foundry-nsp-bounces [at] puck] On Behalf Of Igor Ybema
Sent: Saturday, May 05, 2012 4:45 AM
To: foundry-nsp [at] puck
Subject: Re: [f-nsp] Preserving double-tagged traffic on ICX6100

Hi All,
Just tested with an ICX 6430-24 running 7.4.00T311. Can not reproduce
the case right now.

With tag-type set to 0x9100, edge-port to untagged and uplink port to
tag, I see both outer and inner-tags on the uplink. (0x9100 outer,
0x8100 inner).
With tag-profile set to 0x9100, edge-port to untagged, tag-profile
enabled, uplink port to tag and tag-profile disabled, I see both outer
and inner-tags on the uplinks (this time both 0x8100 on the uplink)

All are broadcasts, arps. aggregated-vlan enabled

@frank: could you share your config part related to the double tagging?



regards, Igor
_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp


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


foundry-nsp at ergens

May 5, 2012, 10:19 AM

Post #12 of 20 (2670 views)
Permalink
Re: Preserving double-tagged traffic on ICX6100 [In reply to]

> My testing used 0x8100 for both inner and outer and no aggregated-VLAN.
> Nothing special about configuration --
> vlan 1048
> tagged ethe 1/3/1 ethe 2/3/1
>
> Traffic goes in and out 1/3/1 and out 2/3/1. VLAN tag 235 is the inner tag.
> Nothing about VLAN 235 is configured on the ICX6100 -- it doesn't need to
> be. Yet VLAN tag 235 is stripped out.


Ok I haven't tested this yet. Clearly you are using the ICX as a
provider core switch, not a prodider edge switch which I tested.
Will test this monday if I have some spare time.

Two questions though:
- Why aren't you using the aggregated-vlan feature? To my knowledge
this is needed to support q-in-q. Stripping unknown vlan's from
etherframes could be a 'normal' thing if this feature is disabled.
- Could you try and use another tag-type for the outer tag? Using
0x8100 for both outer and inner should work but it is used less and
less lately. Using 0x9100 or even better the standard for provider
bridging 0x88a8 will keep you and maybe your equipment from getting
headaches.

regards, Igor
_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp


frnkblk at iname

May 5, 2012, 11:39 AM

Post #13 of 20 (2671 views)
Permalink
Re: Preserving double-tagged traffic on ICX6100 [In reply to]

Yes, we're using it as an aggregation switch.

To your questions:
- I'm not sure how that feature is relevant to our situation. Typically the
Q-in-Q feature is used to describe a mechanism to take in double-tagged
traffic and deliver it non-tagged on access ports. That's not what we're
trying to do.
- while I think we could find a way to do that with the two other vendor
product that participate in this double-tagged circuit, I'd rather not
deviate from the default to compensate for this bug in ICX6100. It's always
mystified me why some L2 products seem to choke on double-tagged traffic
when all it should care about is the outer tag.

Thanks,

Frank

-----Original Message-----
From: igor [at] ergens [mailto:igor [at] ergens] On Behalf Of Igor Ybema
Sent: Saturday, May 05, 2012 12:20 PM
To: Frank Bulk
Cc: foundry-nsp [at] puck
Subject: Re: [f-nsp] Preserving double-tagged traffic on ICX6100

> My testing used 0x8100 for both inner and outer and no aggregated-VLAN.
> Nothing special about configuration --
> vlan 1048
> tagged ethe 1/3/1 ethe 2/3/1
>
> Traffic goes in and out 1/3/1 and out 2/3/1. VLAN tag 235 is the inner
tag.
> Nothing about VLAN 235 is configured on the ICX6100 -- it doesn't need to
> be. Yet VLAN tag 235 is stripped out.


Ok I haven't tested this yet. Clearly you are using the ICX as a
provider core switch, not a prodider edge switch which I tested.
Will test this monday if I have some spare time.

Two questions though:
- Why aren't you using the aggregated-vlan feature? To my knowledge
this is needed to support q-in-q. Stripping unknown vlan's from
etherframes could be a 'normal' thing if this feature is disabled.
- Could you try and use another tag-type for the outer tag? Using
0x8100 for both outer and inner should work but it is used less and
less lately. Using 0x9100 or even better the standard for provider
bridging 0x88a8 will keep you and maybe your equipment from getting
headaches.

regards, Igor


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


foundry-nsp at ergens

May 6, 2012, 1:35 AM

Post #14 of 20 (2664 views)
Permalink
Re: Preserving double-tagged traffic on ICX6100 [In reply to]

> - I'm not sure how that feature is relevant to our situation.  Typically the
> Q-in-Q feature is used to describe a mechanism to take in double-tagged
> traffic and deliver it non-tagged on access ports.  That's not what we're
> trying to do.

You are using jumbo frames then? I do hope so or else your max frames
will not get switched also.

> - while I think we could find a way to do that with the two other vendor
> product that participate in this double-tagged circuit, I'd rather not
> deviate from the default to compensate for this bug in ICX6100.  It's always
> mystified me why some L2 products seem to choke on double-tagged traffic
> when all it should care about is the outer tag.

Yes you are right. A switch which supports vlan's should only care
about the src mac, dst mac, (outer/first) ether type and vlan tag. It
should not in any way look into the payload of the frame. So, from
this perspective you could call it a bug what the ICX is doing.

However, with aggregated-vlan feature disabled I think it could be
plausible that the switch destroys the inner tag. It could be that the
switch is trying to be 'smart' and because it is seeing a vlan tag
which is not configured on the switch it destroyes that tag. But, when
following this thought, why this is only happening to broadcasts and
not to unicast is strange then.

So on each switch (aggregation or access) carrying q-in-q frames I
would always enable aggregated-vlan (and jumbo frames). And if I
notice strange behaviours after that, then I would call brocade and
let them figure out.

But we shall wait for Brocade to come with an answer. They, more then
anyone else, can tell us what the expected behaviour is and give us a
bugfix if needed.

regards, Igor

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


frnkblk at iname

May 6, 2012, 10:12 AM

Post #15 of 20 (2673 views)
Permalink
Re: Preserving double-tagged traffic on ICX6100 [In reply to]

Yes, we have jumbo frames turned on.

As one of the regular NANOG posters writes, products should work with the
element of "least surprise". "Least surprise" in this case would be for
Brocade to do nothing with the inside tags. VLAN aggregation is a specific
feature in which tagged traffic (inner tags) on switch A is dropped off on
an untagged port on switch B so that switch B can wrap an outer tag around.
That does not describe our use of the double-tagged traffic.

As wrote in another email, Brocade has already an answer: they generated a
defect for this issue and is working on a fix. There's no doubt in my mind
that this is a bug.

On a side note, it's always mystified me why vendors don't make switches
which allow untagged traffic to be picked up on an edge port and multi-tag
it with TPID of my choice, and vice-versa. For example:
gigaethernetport 1/1/1
description edge port
untagged
tag 135 8100 1089 9100
gigaethernetport 1/1/24
description trunk uplink
tagged 1089 9100
which could expect traffic to come in untagged on 1/1/1, but push two tags
on, namely inner tag 135 with TPID 8100 and outer tag 1089 with TPID 9100,
and that would go out the switch on 1/1/24.

Regards,

Frank

-----Original Message-----
From: igor [at] ergens [mailto:igor [at] ergens] On Behalf Of Igor Ybema
Sent: Sunday, May 06, 2012 3:36 AM
To: Frank Bulk
Cc: foundry-nsp [at] puck
Subject: Re: [f-nsp] Preserving double-tagged traffic on ICX6100

> - I'm not sure how that feature is relevant to our situation.  Typically
the
> Q-in-Q feature is used to describe a mechanism to take in double-tagged
> traffic and deliver it non-tagged on access ports.  That's not what we're
> trying to do.

You are using jumbo frames then? I do hope so or else your max frames
will not get switched also.

> - while I think we could find a way to do that with the two other vendor
> product that participate in this double-tagged circuit, I'd rather not
> deviate from the default to compensate for this bug in ICX6100.  It's
always
> mystified me why some L2 products seem to choke on double-tagged traffic
> when all it should care about is the outer tag.

Yes you are right. A switch which supports vlan's should only care
about the src mac, dst mac, (outer/first) ether type and vlan tag. It
should not in any way look into the payload of the frame. So, from
this perspective you could call it a bug what the ICX is doing.

However, with aggregated-vlan feature disabled I think it could be
plausible that the switch destroys the inner tag. It could be that the
switch is trying to be 'smart' and because it is seeing a vlan tag
which is not configured on the switch it destroyes that tag. But, when
following this thought, why this is only happening to broadcasts and
not to unicast is strange then.

So on each switch (aggregation or access) carrying q-in-q frames I
would always enable aggregated-vlan (and jumbo frames). And if I
notice strange behaviours after that, then I would call brocade and
let them figure out.

But we shall wait for Brocade to come with an answer. They, more then
anyone else, can tell us what the expected behaviour is and give us a
bugfix if needed.

regards, Igor



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


pcookbrcd at gmail

May 6, 2012, 11:21 AM

Post #16 of 20 (2661 views)
Permalink
Re: Preserving double-tagged traffic on ICX6100 [In reply to]

On Sun, May 6, 2012 at 7:12 PM, Frank Bulk <frnkblk [at] iname> wrote:
> As wrote in another email, Brocade has already an answer: they generated a
> defect for this issue and is working on a fix.  There's no doubt in my mind
> that this is a bug.

Do they have scheduled release date of version 7.4a (or any other
version) with fixed mentioned DEFECT ?

Paul

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


frnkblk at iname

May 6, 2012, 11:42 AM

Post #17 of 20 (2662 views)
Permalink
Re: Preserving double-tagged traffic on ICX6100 [In reply to]

No, not at this time. Our SEs are pressing to get a date.

If you're also experiencing this issue, please contact me offline so our SEs
can add your case to the list which will help to get this prioritized.

Frank

-----Original Message-----
From: foundry-nsp-bounces [at] puck
[mailto:foundry-nsp-bounces [at] puck] On Behalf Of Paul Cook
Sent: Sunday, May 06, 2012 1:21 PM
To: foundry-nsp [at] puck
Subject: Re: [f-nsp] Preserving double-tagged traffic on ICX6100

On Sun, May 6, 2012 at 7:12 PM, Frank Bulk <frnkblk [at] iname> wrote:
> As wrote in another email, Brocade has already an answer: they generated a
> defect for this issue and is working on a fix.  There's no doubt in my
mind
> that this is a bug.

Do they have scheduled release date of version 7.4a (or any other
version) with fixed mentioned DEFECT ?

Paul

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



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


foundry-nsp at ergens

May 7, 2012, 12:25 AM

Post #18 of 20 (2662 views)
Permalink
Re: Preserving double-tagged traffic on ICX6100 [In reply to]

Hi Frank,

Just tested on my ICX 6430-24's and it works as expected:

09:18:25.128275 00:24:38:4c:e7:40 > ff:ff:ff:ff:ff:ff, ethertype
802.1Q (0x8100), length 68: vlan 555, p 0, ethertype 802.1Q, vlan 10,
p 0, ethertype ARP, Request who-has 192.168.10.4 tell 192.168.10.75,
length 46

(in and out the same)


The config:

vlan 555 by port
tagged ethe 1/1/23 to 1/1/24
no spanning-tree
!
jumbo


Running SW: Version 07.4.00T311

regards, igor
_______________________________________________
foundry-nsp mailing list
foundry-nsp [at] puck
http://puck.nether.net/mailman/listinfo/foundry-nsp


frnkblk at iname

May 7, 2012, 5:35 AM

Post #19 of 20 (2659 views)
Permalink
Re: Preserving double-tagged traffic on ICX6100 [In reply to]

Thanks. I assume the ICX6430 and 6100 use different builds?

Frank

-----Original Message-----
From: igor [at] ergens [mailto:igor [at] ergens] On Behalf Of Igor Ybema
Sent: Monday, May 07, 2012 2:25 AM
To: Frank Bulk
Cc: foundry-nsp [at] puck
Subject: Re: [f-nsp] Preserving double-tagged traffic on ICX6100

Hi Frank,

Just tested on my ICX 6430-24's and it works as expected:

09:18:25.128275 00:24:38:4c:e7:40 > ff:ff:ff:ff:ff:ff, ethertype
802.1Q (0x8100), length 68: vlan 555, p 0, ethertype 802.1Q, vlan 10,
p 0, ethertype ARP, Request who-has 192.168.10.4 tell 192.168.10.75,
length 46

(in and out the same)


The config:

vlan 555 by port
tagged ethe 1/1/23 to 1/1/24
no spanning-tree
!
jumbo


Running SW: Version 07.4.00T311

regards, igor


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


pcookbrcd at gmail

May 7, 2012, 5:38 AM

Post #20 of 20 (2658 views)
Permalink
Re: Preserving double-tagged traffic on ICX6100 [In reply to]

On Mon, May 7, 2012 at 2:35 PM, Frank Bulk <frnkblk [at] iname> wrote:
> Thanks.  I assume the ICX6430 and 6100 use different builds?

Yes, both are using different images. Both also have different
hardware. 6610 uses same software build as FCX.

BTW. 6610, not 6100 :)

Paul

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

nsp foundry RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.