netdev
[Top] [All Lists]

RE: [PATCH] (3/4) bridge linkstate handling

To: <hadi@xxxxxxxxxx>
Subject: RE: [PATCH] (3/4) bridge linkstate handling
From: "Eble, Dan" <DanE@xxxxxxxxxx>
Date: Thu, 29 Jul 2004 12:36:38 -0400
Cc: "Stephen Hemminger" <shemminger@xxxxxxxx>, <bridge@xxxxxxxx>, <netdev@xxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
Thread-index: AcR1hY0W3lVJqpgiTWaiHUJVHXbchwAAlbgQ
Thread-topic: [PATCH] (3/4) bridge linkstate handling
> I must have misunderstood Stevens patch then. Are you saying 
> it opens a
> port that was previously blocked because a link was reinserted?
> Or the other way round: it would put a port that was 
> previously blocked
> into forwarding state because a previously forwarding link had a link
> going down?
> I think all this needs to be policy driven.

His patch ensures that when a port regains carrier, it is Blocked.
Before the patch, a Forwarding port would remain Forwarding if the other
end of the cable were unplugged and then plugged into some other place.



> 2) Other inputs like Links going up or down or VRRP state 
> changes for HA
> or somebody farting (pardon my language, just trying to drive a point)
> also need to feed to the same policy decision making engine. 
> The result
> of the policy engine is a STP state transition for a port.

I think I see.  So then when an event happens that might affect the port
state, the bridge should temporarily block traffic on the port (in case
the policy daemon will tell it to start blocking) and wait for the
daemon to respond with a "start blocking" or "continue forwarding"
decision.  Is that the idea, or have I completely misunderstood?


<Prev in Thread] Current Thread [Next in Thread>