Re: enabling if_bridge STP

2007-12-07 Thread Silver Salonen
On Thursday 06 December 2007 17:00, Nikos Vassiliadis wrote:
 On Thursday 06 December 2007 15:37:21 Silver Salonen wrote:
  In my case there's a straight connection between bridge1 
  and bridge2 too, so that they don't have to communicate through
  root-bridge.
 
 Yes, but that also can create a loop and according to STP must be
 eliminated.
 
 Perhaps you can use some inventive IP addressing scheme, to force
 direct communication... some ifconfig option(the edge option?) to
 force forwarding... a tunnel... or some other weirdness(TM) ;)

Well, I just discovered STP, so I might expect too much from it.

I thought that in my scenario (circular VPNs), STP would just discover what's 
the shortest way (ie. whitch VPN-connection to go) from 192.168.1/24 to 
192.168.2/24, from 192.168.1/24 to 192.168.3/24, from 192.168.2/24 to 
192.168.3/24 etc, and then just lets all the packets (including layer 2 ones) 
pass the right bridge, and block them on other bridges, eliminating 
possibility for loops. If it's not what STP does, then I'm a little confused, 
what does STP do.

-- 
Silver
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


enabling if_bridge STP

2007-12-06 Thread Atrox

Hello!

I've just built myself a VPN-network for testing bridge STP. I installed 3
FreeBSD boxes (2 FreeBSD-6.2 and 1 FreeBSD-6.1) and connected all of them
with OpenVPN with TAP-bridging:
* 1st box is OpenVPN server only and has tap0 bridged with its inner
interface (192.168.1.1).
* 2nd box is OpenVPN client only and has tap0 and tap1 bridged with its
inner interface (192.168.2.1).
* 3rd box is both OpenVPN client and server and has also bridged tap0, tap1
and its inner interface (192.168.3.1).

So now the question is on which interfaces should I enable STP in such
setup? I tried enabling it on all interfaces (well, besides the external
ones ;) like this:
=
ifconfig bridge0 create addm tap0 stp tap0 addm sk0 stp sk0 addm tap1 stp
tap1 up
=

But after doing so, all the interfaces just stay disabled, a'la:
=
bridge0: flags=28143UP,BROADCAST,RUNNING,PROMISC,MULTICAST,PPROMISC mtu
1500
ether ac:de:48:46:d3:ef
priority 32768 hellotime 2 fwddelay 15 maxage 20
member: tap0 flags=7LEARNING,DISCOVER,STP
port 7 priority 128 path cost 55 disabled
member: tap1 flags=7LEARNING,DISCOVER,STP
port 9 priority 128 path cost 55 disabled
member: sk0 flags=7LEARNING,DISCOVER,STP
port 1 priority 128 path cost 55 disabled
=

Am I doing smth wrong?

--
Silver
-- 
View this message in context: 
http://www.nabble.com/enabling-if_bridge-STP-tf4954594.html#a14188023
Sent from the freebsd-questions mailing list archive at Nabble.com.

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: enabling if_bridge STP

2007-12-06 Thread Nikos Vassiliadis
On Thursday 06 December 2007 10:17:36 Atrox wrote:
 Am I doing smth wrong?

Hm, are these FreeBSD boxes you are trying to bridge,
on the same ethernet?

STP will create a tree by disabling some ports
to eliminate loops in the topology. If you have
a loop-free topology, all ports should be active.

ASCII art time! What's your topology?

Nikos
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: enabling if_bridge STP

2007-12-06 Thread Atrox


Nikos Vassiliadis-2 wrote:
 
 On Thursday 06 December 2007 10:17:36 Atrox wrote:
 Am I doing smth wrong?
 
 Hm, are these FreeBSD boxes you are trying to bridge,
 on the same ethernet?
 

Yes, all these boxes are connected to our LAN with their ext_ifs. Also, one
of them has a switch and a PC connected to its int_if, other int_ifs are
status: no carrier.


 STP will create a tree by disabling some ports
 to eliminate loops in the topology. If you have
 a loop-free topology, all ports should be active.
 

Well, as I understand, in my case, STP should be enabled mainly on
TAP-interfaces as it would eliminate the scenario where, for an example,
ARP-requests from 192.168.1.1 for 192.168.3.1 reach 192.168.2.1. Have I
understood it correctly?



 ASCII art time! What's your topology?
 

Well, let's try ;)
The machines stand like this:

192.168.8.15/24
  - GW/NAT - 
192.168.1/24
   ||   192.168.8.16/24
== 192.168.8/24 == == - GW/NAT -
   ||192.168.2/24
192.168.8.17/24
 - GW/NAT -
192.168.3/24
-- 
View this message in context: 
http://www.nabble.com/enabling-if_bridge-STP-tf4954594.html#a14189511
Sent from the freebsd-questions mailing list archive at Nabble.com.

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: enabling if_bridge STP

2007-12-06 Thread Nikos Vassiliadis
On Thursday 06 December 2007 12:20:18 Atrox wrote:
 Well, as I understand, in my case, STP should be enabled mainly on
 TAP-interfaces as it would eliminate the scenario where, for an example,
 ARP-requests from 192.168.1.1 for 192.168.3.1 reach 192.168.2.1. Have I
 understood it correctly?

It sounds like you want to isolate the ethernets, not bridge them.
Bridging is not what you need, if I have understood correctly.

You want to keep ARP and broadcasts to the relevant boxes, right?
You have to use VLANs on your switch to achieve this, not bridging.

HTH, Nikos
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: enabling if_bridge STP

2007-12-06 Thread Silver Salonen
On Thursday 06 December 2007 13:21, Nikos Vassiliadis wrote:
 On Thursday 06 December 2007 12:20:18 Atrox wrote:
  Well, as I understand, in my case, STP should be enabled mainly on
  TAP-interfaces as it would eliminate the scenario where, for an example,
  ARP-requests from 192.168.1.1 for 192.168.3.1 reach 192.168.2.1. Have I
  understood it correctly?
 
 It sounds like you want to isolate the ethernets, not bridge them.
 Bridging is not what you need, if I have understood correctly.
 
 You want to keep ARP and broadcasts to the relevant boxes, right?
 You have to use VLANs on your switch to achieve this, not bridging.

Actually the final target is to connect all the 3 LANs over VPN, so that they 
can browse eachother networks etc. When I did it, I could see duplicate 
packets looping through all bridges, so I thought I'd bring in STP. That's 
what it's for, right?

-- 
Silver
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: enabling if_bridge STP

2007-12-06 Thread Nikos Vassiliadis
On Thursday 06 December 2007 13:31:38 Silver Salonen wrote:
 On Thursday 06 December 2007 13:21, Nikos Vassiliadis wrote:
  On Thursday 06 December 2007 12:20:18 Atrox wrote:
   Well, as I understand, in my case, STP should be enabled mainly on
   TAP-interfaces as it would eliminate the scenario where, for an
   example, ARP-requests from 192.168.1.1 for 192.168.3.1 reach
   192.168.2.1. Have I understood it correctly?
 
  It sounds like you want to isolate the ethernets, not bridge them.
  Bridging is not what you need, if I have understood correctly.
 
  You want to keep ARP and broadcasts to the relevant boxes, right?
  You have to use VLANs on your switch to achieve this, not bridging.

 Actually the final target is to connect all the 3 LANs over VPN, so that
 they can browse eachother networks etc. When I did it, I could see
 duplicate packets looping through all bridges, so I thought I'd bring in
 STP. That's what it's for, right?

Not really, STP must be used/needed in a dynamic environment to
eliminate loops. Your environment doesn't seem dynamic to me. You
can create a loop-free topology like this:

http://users.teledomenet.gr/nvass/topology.png

1) 10.0.0.0/24 is the shared network.
2) bridge1 bridges eth0 and tap0 which is the VPN to the root-bridge.
3) bridge2 bridges eth0 and tap0 which is the VPN to the root-bridge.
4) root-bridge bridges eth0, tap0 and tap1.

If you want STP, which you shouldn't normally using this topology,
increase root-bridge's priority manually, in order to win the elections
and be the root bridge.

Note that the external interfaces are not participating in the bridge.

HTH, Nikos
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: enabling if_bridge STP

2007-12-06 Thread Silver Salonen
On Thursday 06 December 2007 15:01, Nikos Vassiliadis wrote:
 On Thursday 06 December 2007 13:31:38 Silver Salonen wrote:
  On Thursday 06 December 2007 13:21, Nikos Vassiliadis wrote:
   On Thursday 06 December 2007 12:20:18 Atrox wrote:
Well, as I understand, in my case, STP should be enabled mainly on
TAP-interfaces as it would eliminate the scenario where, for an
example, ARP-requests from 192.168.1.1 for 192.168.3.1 reach
192.168.2.1. Have I understood it correctly?
  
   It sounds like you want to isolate the ethernets, not bridge them.
   Bridging is not what you need, if I have understood correctly.
  
   You want to keep ARP and broadcasts to the relevant boxes, right?
   You have to use VLANs on your switch to achieve this, not bridging.
 
  Actually the final target is to connect all the 3 LANs over VPN, so that
  they can browse eachother networks etc. When I did it, I could see
  duplicate packets looping through all bridges, so I thought I'd bring in
  STP. That's what it's for, right?
 
 Not really, STP must be used/needed in a dynamic environment to
 eliminate loops. Your environment doesn't seem dynamic to me. You
 can create a loop-free topology like this:
 
 http://users.teledomenet.gr/nvass/topology.png
 
 1) 10.0.0.0/24 is the shared network.
 2) bridge1 bridges eth0 and tap0 which is the VPN to the root-bridge.
 3) bridge2 bridges eth0 and tap0 which is the VPN to the root-bridge.
 4) root-bridge bridges eth0, tap0 and tap1.

Is all the traffic pass through the root-bridge in this case, so that if 
bridge1 wants to talk to bridge2, it has to go through root-bridge and not 
straight? In my case there's a straight connection between bridge1 and 
bridge2 too, so that they don't have to communicate through root-bridge.

-- 
Silver
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: enabling if_bridge STP

2007-12-06 Thread Nikos Vassiliadis
On Thursday 06 December 2007 15:37:21 Silver Salonen wrote:
 Is all the traffic pass through the root-bridge in this case, so that if
 bridge1 wants to talk to bridge2, it has to go through root-bridge and
 not straight? 

Yes, they'll have to go through the root-bridge. STP will create a
tree by shutting down ports causing loops. That's how STP works.
It's all about avoiding loops...

Not following the shortest path is not very important for a layer two
device. Creating a loop in the topology and bringing the network down
because of it, is.

 In my case there's a straight connection between bridge1 
 and bridge2 too, so that they don't have to communicate through
 root-bridge.

Yes, but that also can create a loop and according to STP must be
eliminated.

Perhaps you can use some inventive IP addressing scheme, to force
direct communication... some ifconfig option(the edge option?) to
force forwarding... a tunnel... or some other weirdness(TM) ;)

Nikos
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: enabling if_bridge STP

2007-12-06 Thread RW
On Thu, 6 Dec 2007 15:37:21 +0200
Silver Salonen [EMAIL PROTECTED] wrote:


 Is all the traffic pass through the root-bridge in this case, so that
 if bridge1 wants to talk to bridge2, it has to go through root-bridge
 and not straight? In my case there's a straight connection between
 bridge1 and bridge2 too, so that they don't have to communicate
 through root-bridge.

The problem is that, even with switched ethernet, some packets have to
be broadcast, which can lead to packets going round in loops or
multiplying into a broadcast storm. STP prevents this by disabling 
connections to remove loops in the network.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]