|
Posted by on March 2, 2006, 12:56 pm
If you were Registered and logged in, you could reply and use other advanced thread options
Albert Manfredi wrote:
> q_q_anonymous@yahoo.co.uk wrote:
> > Albert Manfredi wrote
> > > When one says "bridging if it can't route," what that means is that
> > > whatever frames arrive with an unknown Layer 3 header, or no Layer 3
> > > header at all, remain within the domain of the local Link Layer. In an
> > > IP example, that would mean they stay in the same IP subnet as the
> > > brouter port on which they arrived. They are switched through the
> > > brouter as if this were a bridge, using only the MAC address
> > > information, and not forwarded to the port(s) that lead beyond the IP
> > > subnet of the port on which these frames arrived.
> > >
> >
> > that sounds very odd.
> >
> > If the brouter sends the packet back out the interface where it came,
> > then preumably, it means it was a mistake for the comp to send it there
> > in the first place with that interface's Dest MAC.
>
> Let's say the brouter is acting as a bridge between multiple ports
> belonging to one particular IP subnet,
Ohhhh
I didn't realise a Brouter had that.
> and then it has a single port to
> another IP subnet somewhere else. Call the distant IP net "Subnet B,"
> and the local one "Subnet A."
>
> Any frame arriving at one of the Subnet A ports addressed to a Subnet A
> destination will clearly not go to that Subnet B port. It will be
> either flooded to all Subnet A ports (e.g. an ARP broadcast), or it
> will be switched to a particular Subnet A port which has been
> "learned," or it could be multicast to several ports, including
> possibly the Subnet B port.
>
> So what happens if a frame with unknown Network Layer address arrives
> at one of the Subnet A ports? It can't be sent to the Subnet B port, or
> the box wouldn't be much of a router. So I'm saying that frame with
> unknown Layer 3 address can be switched to other Subnet A ports of the
> brouter, just like any bridge would do, but not to the Subnet B port.
>
> > If the brouter knows the correct MAC then it must have MACs for that
> > funny layer 3 protocol, at every interface, for each comp on that
> > interface.
>
> How does it "know the correct MAC"? Because presumably it learned the
> MAC address by inspecting frames sourced from a particular port. MAC
> address xyz lives at port #5, let's say, and this port #5 is one of the
> Subnet A ports.
>
> Okay, so now take the legitimate case in which there are two identical
> MAC addresses xyz, one in Subnet A and one in that distant Subnet B. If
> a frame from one of the other Subnet A ports is addressed to MAC
> address xyz, but contains no Layer 3 header, how should the brouter
> handle that case?
>
> I'm saying, the brouter simply switches the frame from one Subnet A
> port to port #5, which also belongs to Subnet A, but not to the Subnet
> B port.
>
ok!
but then how is that different from a router with a switch connected at
each interface?
I see the logic is slightly different (no deciding if a protocol is
known/routable or not) but the effect is the same.
( I've think of my 'home router' as being like a 2 port router with a
switch at my side so everything hits the switch first. )
> > minor additional point - if by the brouter bridging you mean sending
> > back out the same interface , that is very unbridge like. Bridges send
> > out a diff interface. They choose the correct interface.
>
> Well ... There's typically no reason to send a layer 2 frame back to
> the same port from which it was received. Although this behavior is
> certainly possible for a router. Take the case of a router supporting
> two IP subnets on the same physical Ethernet. If a frame arrives
> addressed to the other IP subnet, the router will take in the frame and
> spit it right back out again on the same port on which it was received.
>
> So this too could happen with this brouter, if two IP subnets happen to
> live off the same port of the box.
>
is there a name for that?
many thanks
| 
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map