<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: "Mackay, Scott" <SMackay,AT,progeny,DOT,net>
Subject: RE: CIPE & Linux bridging
From: Les Mikesell <les,AT,futuresource,DOT,com>
Date: Fri, 09 Apr 2004 21:27:31 -0500
Cc: cipe-l,AT,inka,DOT,de
In-reply-to: <D87E99FF33158340920A02117B96F5A41B21A2@es3.progeny.net>
References: <D87E99FF33158340920A02117B96F5A41B21A2@es3.progeny.net>

On Fri, 2004-04-09 at 09:30, Mackay, Scott wrote:
> Actually, I really just need something which can do both broadcast 
> and multicast in a tunnel sans encryption.  The tunel really just
> exists to carry those items across mediums which may not support
> multicast/broadcasts without it being in a tunnel.

I'd try to avoid anything that doesn't work over normal routing.

> I am not sure, but with tunnels (CIPE or others), is there latency
> introducted by the tunnel?  It would seem, if a tunnel places
> multiple original packets in a tunnel packet, that there may be
> some artificial latency while a tunnel 'waits' for packets to fill
> a buffer.

No, they just wrap encapsulation headers around each packet and
send.  The problem you'll see will be MTU related, not latency
since you'll get packets that are already the max allowed on
an ethernet and have to add encapsulation.

> I saw GRE (well, saw the title and how expandable it was) but
> was looking at CIPE because I really don't need huge things
> from a tunnel.  Thanks for any info in advance!!

GRE is about the simplest scheme that works and it will
interoperate with a Cisco endpoint which is good if the
Cisco is handling multicast for you, but you can't bridge
over the Linux version.  If you really need to bridge through
a tunnel, look at:
http://openvpn.sourceforge.net/bridge.html

---
  Les Mikesell
   les,AT,futuresource,DOT,com


<< | Thread Index | >> ]    [ << | Date Index | >> ]