[LARTC] Linux bridging and cascaded switches

[LARTC] Linux bridging and cascaded switches

[Greg Scott]

Hi -
 
Still plugging away at my Linux bridge/firewall and thinking through the
consequences.  In a normal firewall situation, the Internet is on one
side, the internal LAN on the other. Duh!  But now, with a Linux bridge
in the middle, the whole thing becomes one big messy LAN.  So we have a
scenario that looks like this:

Internal---User---Core-----Firewall---Internet---Internet router
Servers   switch  switch  (Bridged)    switch   (and default GW for
                                                 internal servers)

The scenario is a little more complex than I drew above because the
internal side has more than one LAN segment participating in the bridge.
I'm working on a way to simulate all this here - before going into
production - but I have a big question;

That firewall/bridge is no longer a router - it's a bridge.  Well, a
bridge that also does a bunch of stateful IP layer 3 filtering.  So now,
it will participate in a spanning tree setup with all those switches, on
both sides of it - right?  I'm guessing I want to turn off STP in this
case.  Am I on the right track?

Thanks

- Greg Scott
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Linux bridging and cascaded switches

[Alex Samad]

[-- Attachment #1.1: Type: text/plain, Size: 1786 bytes --]

On Tue, Jun 19, 2007 at 05:54:46PM -0500, Greg Scott wrote:
> Hi -
>  
> Still plugging away at my Linux bridge/firewall and thinking through the
> consequences.  In a normal firewall situation, the Internet is on one
> side, the internal LAN on the other. Duh!  But now, with a Linux bridge
> in the middle, the whole thing becomes one big messy LAN.  So we have a
> scenario that looks like this:
> 
> Internal---User---Core-----Firewall---Internet---Internet router
> Servers   switch  switch  (Bridged)    switch   (and default GW for
>                                                  internal servers)
> 
out of curiosity why would you want to bridge at the firewall.  is this meant 
to be a drop in-line firewall appliance



> The scenario is a little more complex than I drew above because the
> internal side has more than one LAN segment participating in the bridge.
> I'm working on a way to simulate all this here - before going into
> production - but I have a big question;
> 
> That firewall/bridge is no longer a router - it's a bridge.  Well, a
> bridge that also does a bunch of stateful IP layer 3 filtering.  So now,
> it will participate in a spanning tree setup with all those switches, on
> both sides of it - right?  I'm guessing I want to turn off STP in this
> case.  Am I on the right track?

if there is only 1 way to connect from the corporate (private LAN) to the 
public (internet) then I don't think you will need STP - it was meant to stop 
loops in ethernet segments.

If you have multiple paths you might still need it


> 
> Thanks
> 
> - Greg Scott
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> 

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

RE: [LARTC] Linux bridging and cascaded switches

[Greg Scott]

> out of curiosity why would you want to bridge at the firewall.  is
this meant to be a drop in-line firewall appliance

Long story but yes, it is essentially a drop in-line system.  It's a
mess.  

So will that Internet router really see 4 "switches" - a switch, a
bridge, and 2 switches - between it and the internal servers?  I don't
remember all my LAN rules but that feels way too deep to me.  

- Greg
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

RE: [LARTC] Linux bridging and cascaded switches

[Greg Scott]

> On the bridged firewall - The simplest/ easiest/ well tested 
> method would be to run ebtables. A more complex method used 
> before the arrival of ebtables involved pseudo-bridging.

Yes - thanks.  I've been trying some ebtables experiments.  Layer 2
filtering - takes some getting used to!   

More fundamentally, can I cascade these switches and my bridge/firewall
this deep?  How do the Internet router and internal servers find each
others' MAC addresses when they are 4 "hops" (OSI layer 2 hops)
separated?  Or am I making this too complicated?

> Internal---User---Core-----Firewall---Internet---Internet router
> Servers   switch  switch  (Bridged)    switch   (and default GW for
>                                                  internal servers)

Thanks

- Greg



-----Original Message-----
From: Mohan Sundaram [mailto:mohan.tux@gmail.com] 
Sent: Tuesday, June 19, 2007 9:53 PM
To: Greg Scott
Subject: Re: [LARTC] Linux bridging and cascaded switches

Greg Scott wrote:
> Hi -
>   
> Internal---User---Core-----Firewall---Internet---Internet router
> Servers   switch  switch  (Bridged)    switch   (and default GW for
>                                                  internal servers)
> 
> The scenario is a little more complex than I drew above because the 
> internal side has more than one LAN segment participating in the
bridge.
> I'm working on a way to simulate all this here - before going into 
> production - but I have a big question;
> 
> That firewall/bridge is no longer a router - it's a bridge.  Well, a 
> bridge that also does a bunch of stateful IP layer 3 filtering.  So 
> now, it will participate in a spanning tree setup with all those 
> switches, on both sides of it - right?  I'm guessing I want to turn 
> off STP in this case.  Am I on the right track?
> 
> Thanks
> 
> - Greg Scott
 From what you have drawn, it seems like we will not have multiple paths
in the LAN and so STP will not be needed.

On the bridged firewall - The simplest/ easiest/ well tested method
would be to run ebtables. A more complex method used before the arrival
of ebtables involved pseudo-bridging.

Mohan
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Linux bridging and cascaded switches

[Alex Samad]

[-- Attachment #1.1: Type: text/plain, Size: 681 bytes --]

On Tue, Jun 19, 2007 at 06:35:46PM -0500, Greg Scott wrote:
> > out of curiosity why would you want to bridge at the firewall.  is
> this meant to be a drop in-line firewall appliance
> 
> Long story but yes, it is essentially a drop in-line system.  It's a
> mess.  
> 
> So will that Internet router really see 4 "switches" - a switch, a
> bridge, and 2 switches - between it and the internal servers?  I don't
> remember all my LAN rules but that feels way too deep to me.  
I think that was the old 5-4-3 or was it 4-3-2 ... I think that was more in the 
days of repeater and broadcast hubs.  Modern day switch I believe allow for a 
lot more.

> 
> - Greg
> 

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Linux bridging and cascaded switches

[John Default]

Hi

Greg Scott wrote:
> More fundamentally, can I cascade these switches and my bridge/firewall
> this deep?  How do the Internet router and internal servers find each
> others' MAC addresses when they are 4 "hops" (OSI layer 2 hops)
> separated?  Or am I making this too complicated?
>
>   
i was taught that you should have no more than 4 switches between any 
two LAN nodes, so this should work. STP should be ok, but not needed 
until you have some redundant links between bridge/fw and core switches 
(if you have more core switches, you would probably like to use more 
links for redundancy).
[you would probably want the core switch to become STP root then.. ]

when switch doesn't know destination it works like hub, so at the 
beginning your network will be flooded with frames and this way all 
switches will learn mac addresses no matter how many hops. (frame will 
be broadcasted to all corners of LAN).

servers and router will search for each other's MAC using ARP 
broadcasts, which will get to every node in LAN (if you don't filter 
them out : ) ). Therefore they will certainly find each other.
 
(( 4 switches add constant delay to your traffic that i think you would 
like to avoid.  if you could make internet router a firewall (you 
probably can't : ) ), that would remove 2 layers of bridging, would be 
more simple and allow more control.

servers--distribution_switch--core_switch--router/firewall
                                                     |
                                                internet switch
))
>> Internal---User---Core-----Firewall---Internet---Internet router
>> Servers   switch  switch  (Bridged)    switch   (and default GW for
>>                                                  internal servers)
>>     
>
> Thanks
>
> - Greg
>   
___________________________________

S pozdravom / Best regards

John Default
__________________________________

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Linux bridging and cascaded switches

[Grant Taylor]

On 6/19/2007 11:07 PM, Alex Samad wrote:
> I think that was the old 5-4-3 or was it 4-3-2 ... I think that was 
> more in the days of repeater and broadcast hubs.  Modern day switch I 
> believe allow for a lot more.

To the best of my knowledge (including inquiries with colleagues) the 
proverbial "3,4,5" rule for Ethernet was prior to switches, as in a 
store and forward, mechanism.  I think the rule was mainly to help 
timing and to prevent signal degradation, which switches help take care of.

So, now, at least in theory, you could have a bridged network the world 
over in one really big broadcast domain.  The problem would be that it 
is one really big broadcast domain which has its own down sides to 
consider and mitigate.



Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Linux bridging and cascaded switches

[Grant Taylor]

On 6/19/2007 10:31 PM, Greg Scott wrote:
> More fundamentally, can I cascade these switches and my 
> bridge/firewall this deep?  How do the Internet router and internal 
> servers find each others' MAC addresses when they are 4 "hops" (OSI 
> layer 2 hops) separated?  Or am I making this too complicated?

Yes, you probably can cascade the switches like that, though I question 
is that what you really want to do or not.

As you have indicated, the switches operate at (OSI) layer 2.  Thus they 
pass (sans filtering) any and all non-broadcast traffic that they do not 
know the destination for out all ports except for the one that it came 
in on.  At least this is the standard operating procedure of most switches.

Seeing as how ARP requests are broadcast they are forwarded out all 
interfaces except for the one they come in.  So, if you ARP on one 
switch, it will forward it to the next switch, which will in turn 
forward it on to the next, and so on until there are no more ports to 
forward the traffic out.  ARP replies are unicast from the MAC of the 
ARPed system back to the ARPing system.  This return path is when the 
intermediary switches learn of the MAC address of the ARPed system.  So, 
subsequent packets to the ARPed system will pass out the switches based 
on the target MAC address which was previously learned during the ARP.

Incidentally, this is why some systems, especially load balancers and 
the likes, will send out a "Gratuitous ARP" (a.k.a. GARP) packet to 
pre-populate (if you will) the switches (MAC) address table(s).

Hope that helps shed some light on the subject.



Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Linux bridging and cascaded switches

[Grant Taylor]

On 6/20/2007 3:58 PM, John Default wrote:
> when switch doesn't know destination it works like hub, so at the 
> beginning your network will be flooded with frames and this way all 
> switches will learn mac addresses no matter how many hops. (frame 
> will be broadcasted to all corners of LAN).

This is also why it is a bad idea to have an overly large broadcast domain.

This is also why you do not want to bridge across a WAN link if you 
don't have to.  Usually the broadcasts are local to the LAN and need not 
go across the WAN link.



Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc