[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: system/964: system change-request - integrated routing andbridging



The following reply was made to PR system/964; it has been noted by GNATS.

From: op21@squish.org
To: cliftonr@lava.net
Cc: gnats@openbsd.org
Subject: Re: system/964: system change-request - integrated routing and
 bridging
Date: Thu, 4 Nov 1999 08:47:05 -0800 (PST)

 what happens when you try to put an ip address on the ethernet interface(s)
 instead of the bridge interface?
 
 
 On Wed, 3 Nov 1999 cliftonr@lava.net wrote:
 
 //
 //>Number:         964
 //>Category:       system
 //>Synopsis:       bridging and routing can not be combined
 //>Confidential:   no
 //>Severity:       serious
 //>Priority:       medium
 //>Responsible:    bugs
 //>State:          open
 //>Class:          change-request
 //>Submitter-Id:   net
 //>Arrival-Date:   Thu Nov  4 01:20:01 MST 1999
 //>Last-Modified:
 //>Originator:     Clifton R
 //>Organization:
 //LavaNet
 //>Release:        2.5
 //>Environment:
 //	
 //	System      : OpenBSD 2.5
 //	Architecture: OpenBSD.i386
 //	Machine     : i386
 //>Description:
 //
 //I am attempting to configure a firewall based on the Ethernet bridge 
 //pseudo-device, as the documentation seems to imply is possible using 
 //bridging and IP filters.  However, it does not seem possible to then
 //give the OpenBSD server itself an address within the network.  I try 
 //to configure that with the combination of "brconfig bridge0" and 
 //"ifconfig bridge0 inet ....." as noted below.
 //
 //The inet address is not added to the bridge interface, and IP addresses
 //within the network are not reachable unless the inet class address is 
 //configured directly onto the individual Ethernet interface.  This seems
 //to preclude any use of the bridge pseudo-device in combination with 
 //normal routing, unless IP addresses are allocated across the bridged 
 //networks exactly as they would be if routing between them, so that the 
 //OpenBSD machine is assigned a unique address on each interface, each
 //interface has its own network address and netmask, etc.
 //
 //This renders the bridge device much less useful in constructing a 
 //transparent firewall, which was one of my goals.  It would be desirable
 //if this worked closer to Cisco's "Integrated Routing and Bridging" in
 //concept, so that an inet class address could be assigned to the bridge0
 //pseudo-device, allowing the entire bridged network to be treated as a 
 //single interface from the IP perspective.  All my attempts to configure 
 //this with the existing configuration interfaces have failed.
 //
 //>How-To-Repeat:
 //
 //  ifconfig ne3 up media 10baset
 //  ifconfig ne4 up media 10baset
 //  brconfig bridge0 add ne3 add ne4
 //  ifconfig bridge0 inet xxx.yyy.zzz.www [etc]]
 //
 //  ifconfig -a
 //
 //>Fix:
 //
 //  More complete implementation of the bridge pseudo-device such that it 
 //interoperates more completely with ifconfig and IP routing.  I believe
 //this would be extremely useful.
 //
 //>Audit-Trail:
 //>Unformatted:
 //