[GRLUG] Two topics...multicast and traffic shaping.

[Adam Tauno Williams]

On Tue, 2011-07-12 at 13:57 -0400, Michael Mol wrote:
> With IPv6 up and working very well at home (6to4), I've got two things
> I want to get working properly on my network, next.

Sweet.

> The first is traffic shaping. With my current connection, I don't
> really face noticeable bandwidth limitations, but it's still something
> I'd like to get straight.
> My thought is, the majority of latency-sensitive traffic is going to
> be on UDP (VOIP, etc),

Define "latency-sensitive".  Multimedia is going to be almost entirely
UDP [for Voip it will probably be RTP].

>  or is going to be on TCP with small packets
> (ssh sessions and the like).

You'll notice latency with these, but latency won't 'break' anything.

>  So if I set up traffic shaping to give
> top priority to UDP packets and to small packets, I should broadly
> cover my common cases for low-latency traffic, correct? (Anticipated
> glitches: UDP VPNs and high-bandwidth UDP streams)

Correct.  Generally VPNs screw QoS royal.  QoS with VPNs in the mix is
nearly impossible [unless you just want to shuttle GRE traffic into a
low-priority bucket].  

I've been down this road with AT&T's MPLS 'cloud' networks.  You can get
QoS working in a meaningful way on tunneled traffic - but it will
consume a couple of head-down you-don't-eat-or-sleep days.

> The second is multicast. My impression is that Comcast's backbone
> supports multicast; DOCSIS 2 and DOCSIS 3 both have specific allowance
> for it, and it's recommended in manufacturer docs for cable ISPs
> wanting to deliver video. 

Yep.

> My firewall logs currently show that I'm
> dropping packets with multicast destination IPs, so I know I have some
> fixes to do, there. However, I don't expect that my router is
> currently routing multicast traffic through to my internal network.

I assume we are talking about IPv4 multicast;  the odds you'll
successfully get it across a NAT are low [you can't really NAT multicast
traffic].  You should be able to bring multicast traffic into the
network without much issue, but outbound multicast traffic will have a
source address of the private network [connection tracking doesn't work
for multicast traffic, so the typically awesome stateful-NAT provided by
iptables isn't effective - at least this *WAS* true a few years ago.] 

Getting around the NAT issue is the purpose of the
mrouted/pimd/igmpproxy service.

You can see the state of the multicast routing and established streams
in /proc/net
awilliam at linux-yu4c:/proc/net> cat ip_mr_cache
Group    Origin   Iif     Pkts    Bytes    Wrong Oifs
awilliam at linux-yu4c:/proc/net> cat ip_mr_cache
Group    Origin   Iif     Pkts    Bytes    Wrong Oifs
awilliam at linux-yu4c:/proc/net> 

Also watch the TTL of multicast packets since many services set this to
"1".  This means the 'range' of the packet is pretty much limited to the
LAN or immediately adjacent networks.

Also make sure multicast forwarding is even enabled.
  --- /proc/sys/net/ipv4/conf/all/mc_forwarding ---

> Does anyone have any experience with enabling multicast on a Debian
> system? I thought I just needed to install mrouted, but there isn't
> even a package for it.

I haven't played with multicast in awhile but I think mrouted was
obseleted by pimd.   If I recall correctly mrouted was a DVMRP service
not IGMP [but my notes are old].

Do you have any specific applications you want to use with multicast?
In general *local* multicast "just-works".  Avahi / Bonjour / ZeroConf
use multicast DNS to accomplish their thing.  Routed multicast is
another [rabid] animal entirely; it is yet another reason NAT is *EVIL*
and IPv4 must die.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.