[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
On 1/10/2013 4:59 AM, Manuel Bouyer wrote:
> On Tue, Oct 01, 2013 at 04:50:31AM +1000, Darren Reed wrote:
>> On 30/09/2013 8:44 PM, Manuel Bouyer wrote:
>>> On Mon, Sep 30, 2013 at 06:56:54AM +1000, Darren Reed wrote:
>>>> On 29/09/2013 8:24 PM, Manuel Bouyer wrote:
>>>>> So, if I get it right, you want one bridge(4) per forwarding
>>>>> domain, not one bridge that handle several forwarding domain. How
>>>>> would one port belonging to several forwarding domains (via 802.1q
>>>>> encap for example) be represented ?
>>>> Create multiple vlan(4) interfaces per port and have each vlan(4)
>>>> interface be a member of a different bridge(4) domain.
>>> I'm not sure I like this. This is the opposite of how you manage a
>>> real switch (hp, cisco, etc ...). On these device, you have a single view
>>> of the switching fabric, with vlan tag information when pertinent.
>> Remember that what you're comparing here is the design of the underlying
>> system that you never see with a Cisco/HP switch. All that you see from
>> them is what the management interface presents.
> that's true, but I'd prefer to keep our management interface close to that,
> instead of the opposite. Because that's what peoples are used to.
> And BTW, I have some knowledge in electronics, and if I had
> to design such a device, I would go with a single switching fabric
> understanding vlan tags instead of multiple ones with dispatch based
> on tag from the input port, because multiplexing is always good for
> resource managements. Actually (from reading the docs) I suspect
> larger switches may have multiple switching fabrics (a few), but the dispatch
> is based on QoS classification instead of vlan tags.
Ok, I see what you're saying is missing: the ability to manage an
ACL for each port that specifies which VLANs are allowed and for
the bridge to take the VLAN tag into consideration when forwarding
Main Index |
Thread Index |