Mailing List Archive

Hi

Looks like you have "route-only" globally or on physical port applied. Try to do "no route-only" on physical port first.

Valeri Streltsov

-----Original Message-----
From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Franz Georg Kohler
Sent: Tuesday, March 1, 2016 11:53 AM
To: foundry-nsp@puck.nether.net
Subject: [f-nsp] Double-switched (looped) traffic on Netiron MLX

Hello,

I am currently seing traffic being blocked on a MLX setup where there are two VLANS:
First vlan (10 in this example) is a vlan with layer-3 ve interface.
Traffic is first sent via the internal VLAN to a firewall device.
Then it is switched using the external VLAN and finally being routed.
This is to make the traffic pass the firewall and not to switch it directly to the server, bypassing the firewall.

With this setup, MLX does not switch the traffic correctly until i set transparent-hw-flooding on the internal VLAN. ARP works but IP packets do not get forwarded.

Does anybody know why this is the case and if ther is any solution apart from setting transparent-hw-flooding?



+-------+
| | +-----------+
| ICX2 +---------------+ Server |
+------------+ | +-----------+
| +-------+
|
+-------+ |
| +-+
| MLX | VLAN 999
| +------------------+
+-------+ |
VLAN10/ve10 |
| +---+-------+
| | |
| | firewall |
+------------------+ |
+-----------+



Best regards,

Franz Georg Köhler
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

The MLX platform is not a layer2 switch by default, so there are two
ways to solve this problem:

a) Use a VLL-local to bridge VLAN 999 from the firewall, through the
MLX, to the ICX2. Then the MLX does not even learn the MAC addresses of
the packets which are passing through.

b) Perform a "no route-only" on all the interfaces which are involved in
layer2 switching.

On 03/01/2016 09:57 AM, Valeri Streltsov wrote:
> Hi
>
> Looks like you have "route-only" globally or on physical port applied. Try to do "no route-only" on physical port first.
>
> Valeri Streltsov
>
> -----Original Message-----
> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Franz Georg Kohler
> Sent: Tuesday, March 1, 2016 11:53 AM
> To: foundry-nsp@puck.nether.net
> Subject: [f-nsp] Double-switched (looped) traffic on Netiron MLX
>
> Hello,
>
> I am currently seing traffic being blocked on a MLX setup where there are two VLANS:
> First vlan (10 in this example) is a vlan with layer-3 ve interface.
> Traffic is first sent via the internal VLAN to a firewall device.
> Then it is switched using the external VLAN and finally being routed.
> This is to make the traffic pass the firewall and not to switch it directly to the server, bypassing the firewall.
>
> With this setup, MLX does not switch the traffic correctly until i set transparent-hw-flooding on the internal VLAN. ARP works but IP packets do not get forwarded.
>
> Does anybody know why this is the case and if ther is any solution apart from setting transparent-hw-flooding?
>
>
>
> +-------+
> | | +-----------+
> | ICX2 +---------------+ Server |
> +------------+ | +-----------+
> | +-------+
> |
> +-------+ |
> | +-+
> | MLX | VLAN 999
> | +------------------+
> +-------+ |
> VLAN10/ve10 |
> | +---+-------+
> | | |
> | | firewall |
> +------------------+ |
> +-----------+
>
>
>
> Best regards,
>
> Franz Georg Köhler
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp

--
Met vriendelijke groet / Kindest regards,
Martijn Schmidt


i3D.net performance hosting
*Martijn Schmidt | Network Architect*
Email: martijnschmidt@i3d.net <mailto://martijnschmidt@i3d.net> | Tel:
+31 10 8900070

*i3D.net B.V. | Global Backbone AS49544*
Van Nelleweg 1, 3044 BC Rotterdam, The Netherlands
VAT: NL 8202.63.886.B01

Website
<http://www.i3d.net/?utm_source=emailsignature&utm_medium=email&utm_campaign=home>
| Case Studies
<http://www.i3d.net/partners/?utm_source=emailsignature&utm_medium=email&utm_campaign=case-studies>
| LinkedIn <https://www.linkedin.com/company/i3d-net>

On Tue, Mar 01, 2016 at 09:59:02AM +0100, i3D.net - Martijn Schmidt wrote:
> The MLX platform is not a layer2 switch by default, so there are two
> ways to solve this problem:
>
> a) Use a VLL-local to bridge VLAN 999 from the firewall, through the
> MLX, to the ICX2. Then the MLX does not even learn the MAC addresses of
> the packets which are passing through.
>
> b) Perform a "no route-only" on all the interfaces which are involved in
> layer2 switching.

There is already no route-only set on the interfaces in question (I forgot to
mention that). The device is acting as switch & router. Otherwise, the
internal VLAN would not be switched with transparent-hw-flooding set as well.

I see that the switching does not work until transparent-hw-flooding is set. I
wonder if this is related to the same mac address showing up in two different
VLANs or some kind of loop detection. If transparent-hw-flooding is set, the
device just floods all the traffic without analyzing it.



Best regards,

Franz Georg Köhler
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

I had a similar problem with a VE in a VPLS. Try this:

device(config)# no ip icmp redirects

http://www.brocade.com/content/html/en/configuration-guide/NI_05800a_SWITCHING/GUID-04EDFD31-E5FB-4593-8434-0DF8EDB3249E.html

-Josh

On Tue, Mar 1, 2016 at 3:12 AM, Franz Georg Koehler <lists@openunix.de>
wrote:

> On Tue, Mar 01, 2016 at 09:59:02AM +0100, i3D.net - Martijn Schmidt wrote:
> > The MLX platform is not a layer2 switch by default, so there are two
> > ways to solve this problem:
> >
> > a) Use a VLL-local to bridge VLAN 999 from the firewall, through the
> > MLX, to the ICX2. Then the MLX does not even learn the MAC addresses of
> > the packets which are passing through.
> >
> > b) Perform a "no route-only" on all the interfaces which are involved in
> > layer2 switching.
>
> There is already no route-only set on the interfaces in question (I forgot
> to
> mention that). The device is acting as switch & router. Otherwise, the
> internal VLAN would not be switched with transparent-hw-flooding set as
> well.
>
> I see that the switching does not work until transparent-hw-flooding is
> set. I
> wonder if this is related to the same mac address showing up in two
> different
> VLANs or some kind of loop detection. If transparent-hw-flooding is set,
> the
> device just floods all the traffic without analyzing it.
>
>
>
> Best regards,
>
> Franz Georg Köhler
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>

Hi,

I have no solution for that beside using vpls/vll-local. I don't think
there is one.
We had that issue many years ago, we had to remove "router mpls" from an
MLX config because of not enough RAM and ran into the same issue.
We opened a support ticket and got an answer like "that is not a supported
setup".
They did not even tell us that transparent-hw-flooding solves this (we
found out later and used it).

btw, transparent-hw-flooding can override the "route-only" statement.
I had another issue where I forgot to disable it on an interface which
resulted in strange issue as long as transparent-hw-flooding was not set.
I was told by Brocade that this also disables some routing-stuff.
A route-only interface will switch traffic for vlans with
transparent-hw-flooding configured.

kind regards
Rolf

> On Tue, Mar 01, 2016 at 09:59:02AM +0100, i3D.net - Martijn Schmidt wrote:
>> The MLX platform is not a layer2 switch by default, so there are two
>> ways to solve this problem:
>>
>> a) Use a VLL-local to bridge VLAN 999 from the firewall, through the
>> MLX, to the ICX2. Then the MLX does not even learn the MAC addresses of
>> the packets which are passing through.
>>
>> b) Perform a "no route-only" on all the interfaces which are involved in
>> layer2 switching.
>
> There is already no route-only set on the interfaces in question (I forgot
> to
> mention that). The device is acting as switch & router. Otherwise, the
> internal VLAN would not be switched with transparent-hw-flooding set as
> well.
>
> I see that the switching does not work until transparent-hw-flooding is
> set. I
> wonder if this is related to the same mac address showing up in two
> different
> VLANs or some kind of loop detection. If transparent-hw-flooding is set,
> the
> device just floods all the traffic without analyzing it.
>
>
>
> Best regards,
>
> Franz Georg Köhler
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>


_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

On Tue, Mar 01, 2016 at 10:00:56PM +0100, "Rolf Hanßen" wrote:
> Hi,
>
> I have no solution for that beside using vpls/vll-local. I don't think
> there is one.

Interesting. vll-local could be a better solution than
transparent-hw-flooding. I am going to test it.


> We had that issue many years ago, we had to remove "router mpls" from an
> MLX config because of not enough RAM and ran into the same issue.
> We opened a support ticket and got an answer like "that is not a supported
> setup".
> They did not even tell us that transparent-hw-flooding solves this (we
> found out later and used it).

I am suprised to hear that. However, that explains why the setup does not work
with switching enabled. I suspected that the system gets irritated by seeing
the same packet/source mac on two different vlans and that there is some
configuration option to convince the system that this is OK.


Best regards,

Franz Georg Köhler

_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

On Tue, Mar 01, 2016 at 08:29:57AM -0700, Josh Galvez wrote:
> I had a similar problem with a VE in a VPLS. Try this:
>
> device(config)# no ip icmp redirects
>
> http://www.brocade.com/content/html/en/configuration-guide/NI_05800a_SWITCHING/GUID-04EDFD31-E5FB-4593-8434-0DF8EDB3249E.html

Hello,

I have already set no ip icmp redirects.

While this is not a default setting, it is generally a good idea to disable
icmp redirects because the system would otherwise tend to high CPU utilization
as it is analyzing traffic to send icmp redirects (at least if the traffic is
leaving on the same interface).
As most systems ignore ICMP redirects anyway, there is no benefit in keeping
the default option enabled and I strongly recommend to always disable it.



Best regards,

Franz Georg Köhler

_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

On Wed, Mar 02, 2016 at 09:31:30AM +0100, Franz Georg Köhler wrote:
> On Tue, Mar 01, 2016 at 10:00:56PM +0100, "Rolf Hanßen" wrote:
>> Hi,
>>
>> I have no solution for that beside using vpls/vll-local. I don't think
>> there is one.
>
> Interesting. vll-local could be a better solution than
> transparent-hw-flooding. I am going to test it.

Unfortunately, vll is point-to-point. I would need vpls-local....


Best regards,

Franz Georg Köhler
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

Or better yet, build a network without two gateways on the same LAN. (or set the default gateway to the actual exit point)
Redirects were used to stop extra hops in the broadcast domain.

90 percent of people disable these without knowing why.

-----Original Message-----
From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Franz Georg Köhler
Sent: 02 March 2016 08:39
To: foundry-nsp@puck.nether.net
Subject: Re: [f-nsp] Double-switched (looped) traffic on Netiron MLX

On Tue, Mar 01, 2016 at 08:29:57AM -0700, Josh Galvez wrote:
> I had a similar problem with a VE in a VPLS. Try this:
>
> device(config)# no ip icmp redirects
>
> http://www.brocade.com/content/html/en/configuration-guide/NI_05800a_S
> WITCHING/GUID-04EDFD31-E5FB-4593-8434-0DF8EDB3249E.html

Hello,

I have already set no ip icmp redirects.

While this is not a default setting, it is generally a good idea to disable icmp redirects because the system would otherwise tend to high CPU utilization as it is analyzing traffic to send icmp redirects (at least if the traffic is leaving on the same interface).
As most systems ignore ICMP redirects anyway, there is no benefit in keeping the default option enabled and I strongly recommend to always disable it.



Best regards,

Franz Georg Köhler

_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

I wonder if the issue is the fact that Brocade uses the same MAC
address for all VEs, and the device is doing the wrong thing.

Has anyone tried setting up vrrp on a ve in this topology (even though
it is a single device) to see if it does the right thing? That should
cause the traffic to the VRRP IP address to use a different MAC
address...

I think Frank proposed this as a solution to a different problem once,
although I never heard if it worked.

--
Eldon Koyle


On Wed, Mar 2, 2016 at 7:00 AM, Nick Cutting <ncutting@edgetg.co.uk> wrote:
> Or better yet, build a network without two gateways on the same LAN. (or set the default gateway to the actual exit point)
> Redirects were used to stop extra hops in the broadcast domain.
>
> 90 percent of people disable these without knowing why.
>
> -----Original Message-----
> From: foundry-nsp [mailto:foundry-nsp-bounces@puck.nether.net] On Behalf Of Franz Georg Köhler
> Sent: 02 March 2016 08:39
> To: foundry-nsp@puck.nether.net
> Subject: Re: [f-nsp] Double-switched (looped) traffic on Netiron MLX
>
> On Tue, Mar 01, 2016 at 08:29:57AM -0700, Josh Galvez wrote:
>> I had a similar problem with a VE in a VPLS. Try this:
>>
>> device(config)# no ip icmp redirects
>>
>> http://www.brocade.com/content/html/en/configuration-guide/NI_05800a_S
>> WITCHING/GUID-04EDFD31-E5FB-4593-8434-0DF8EDB3249E.html
>
> Hello,
>
> I have already set no ip icmp redirects.
>
> While this is not a default setting, it is generally a good idea to disable icmp redirects because the system would otherwise tend to high CPU utilization as it is analyzing traffic to send icmp redirects (at least if the traffic is leaving on the same interface).
> As most systems ignore ICMP redirects anyway, there is no benefit in keeping the default option enabled and I strongly recommend to always disable it.
>
>
>
> Best regards,
>
> Franz Georg Köhler
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp