Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 1 Jul 2004 12:00:41 +0200 (CEST)
From:      Harti Brandt <harti@freebsd.org>
To:        Donatas.Gendvilas@lrtc.net
Cc:        net@freebsd.org
Subject:   Re: 2 Harti
Message-ID:  <20040701115027.U81202@beagle.kn.op.dlr.de>
In-Reply-To: <OF1658085C.C249081B-ONC2256EC4.002D7114-C2256EC4.002D7124@lrtc.net>
References:  <OF1658085C.C249081B-ONC2256EC4.002D7114-C2256EC4.002D7124@lrtc.net>

next in thread | previous in thread | raw e-mail | index | archive | help

Hello,

On Thu, 1 Jul 2004 Donatas.Gendvilas@lrtc.net wrote:

> Your supplied exampel of connection between two bsd/hatm machines using NG
> nodes and Inet hooks works fine.
> But those 2 machines works as an IP Bridge. We need Ethernet bridge. So
> we've tried to connect hatm<->em adapters through netgraph and this
> connection also works fine. We have an ethernet bride now.
> We've extended vpi bits as you suggested, but one problem stil remains.
> the control message
> "msg hatm0: cpcsinit {name="sig1" aal=5 vci=5} sets default flag to
> 0x10<NG>.
> This configuration works between 2 BSD Machines, but doesn't when one of
> the is for example ATM Switch with RFC 1483 feature. Would you provide us
> with some information of how to make Ethernet bride connection between
> FreeBSD and other vendor supporting RFC 1483 (usin netgraph).
> We've tried to change connection parameter for vcc channel usig:
> "msg hatm0: cpcsinit {name="sig1" flags=xxxxxx aal=5 vci=5}, where xxxxx
> was 0x0002, and many others, but found that atmconfig always shows only
> 0x10<NG>.

I don't fully understand what you want to do. If you want just to route 
your traffic through the FreeBSD machine, then that should work without
any additional flags:

<machine1> ----------- <FreeBSD> ------------- <ATM-switch>

If machine1 and ATM-switch speak RFC1483 and you just need to tunnel the
traffic through the FreeBSD that you should be fine with just connecting 
the hooks from the en0 and the hatm0 together and cpcsinit both with aal=5 
and no flags. This way the FreeBSD machine transparently moves the AAL5 
frames between the two links (think of a poor man's ATM switch with a 
PVC). The FreeBSD's IP stack doesn't see any of the traffic in this case.

The LLC flag comes into the game if you want to pass the AAL5 frames 
to/from the FreeBSD's IP stack. The LLC encapsulation is done just above 
the AAL layer and below the IP layer. But in this case you need to route 
the packets through FreeBSD's IP layer.

What you cannot easily do is have the packets transparently routed between
machine1 and ATM-switch AND see them in FreeBSD's IP layer. That would be 
a kind of hub at the AAL layer.

If you want to speak with the ATM switch from FreeBSD per RFC 1483:

<FreeBSD> -------------- <ATM-switch>

then you can just use the 'atm natm' command. The LLC flag (0x2) is 
attached to the route, not the VC in the driver, because the LLC 
encapsulation is done above the driver (see also natmip(4) byte 0 of the 
LL address in the route command) so you wont see it in atm's output of the 
VC table, but you'll see it in netstat -r output.

harti



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040701115027.U81202>