[KLUG Members] multicast

[John Pesce]

Hello all,

I hope this is of interest to a lot of you. It is getting long, so please 
let me know if I should take this off list.

On Fri, 5 Sep 2003, Peter Buxton wrote:

> Netfilter is the greatest thing since sliced bread. It is also a source
> of nefarious bugs. One Linux install at KLUG came to a stop when someone

Bugs are bad. This is a really important project.


> If you enter `iptables-save -c`, you get a [packets:bytes] bracket

[root@rts rc.d]# iptables-save -c
# Generated by iptables-save v1.2.7a on Fri Sep  5 09:27:30 2003
*filter
:INPUT ACCEPT [119545:47058540]
:FORWARD ACCEPT [27:1623]
:OUTPUT ACCEPT [113624:50229844]
:RH-Lokkit-0-50-INPUT - [0:0]
[146749:51725695] -A INPUT -j RH-Lokkit-0-50-INPUT
[67:4023] -A FORWARD -j RH-Lokkit-0-50-INPUT
[8:224] -A RH-Lokkit-0-50-INPUT -m pkttype --pkt-type multicast -j ACCEPT
[36:5570] -A RH-Lokkit-0-50-INPUT -s 192.168.2.1 -p udp -m udp --sport 53 --dport 1025:65535 -j ACCEPT
[5:300] -A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
[0:0] -A RH-Lokkit-0-50-INPUT -i eth0 -p udp -m udp --sport 67:68 --dport 67:68 -j ACCEPT
[0:0] -A RH-Lokkit-0-50-INPUT -i eth1 -p udp -m udp --sport 67:68 --dport 67:68 -j ACCEPT
[4603:2087642] -A RH-Lokkit-0-50-INPUT -i lo -j ACCEPT
[40:2400] -A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 0:1023 --tcp-flags SYN,RST,ACK SYN -j REJECT --reject-with icmp-port-unreachable
[0:0] -A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 2049 --tcp-flags SYN,RST,ACK SYN -j REJECT --reject-with icmp-port-unreachable
[22552:2573419] -A RH-Lokkit-0-50-INPUT -p udp -m udp --dport 0:1023 -j REJECT --reject-with icmp-port-unreachable
[0:0] -A RH-Lokkit-0-50-INPUT -p udp -m udp --dport 2049 -j REJECT --reject-with icmp-port-unreachable
[0:0] -A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 6000:6009 --tcp-flags SYN,RST,ACK SYN -j REJECT --reject-with icmp-port-unreachable
[0:0] -A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 7100 --tcp-flags SYN,RST,ACK SYN -j REJECT --reject-with icmp-port-unreachable
COMMIT
 
> Try this line:
> 
> iptables -I 1 RH-Lokkit-0-50-INPUT -m pkttype --pkt-type multicast -j ACCEPT
> rule chain at the very start. Try `ping 224.0.0.1` and tell me what
> hosts answer on the two LANs, if any.

Same response from just eth2:

[root@rts rc.d]# ping -c 2 224.0.0.1
PING 224.0.0.1 (224.0.0.1) 56(84) bytes of data.
64 bytes from 192.168.2.3: icmp_seq=1 ttl=64 time=0.258 ms
64 bytes from 192.168.2.12: icmp_seq=1 ttl=64 time=0.267 ms (DUP!)

I can do:

[root@rts rc.d]# ping -c 2 224.0.0.1 -I eth0
PING 224.0.0.1 (224.0.0.1) from 192.168.3.1 eth0: 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_seq=1 ttl=64 time=0.207 ms
64 bytes from 192.168.3.107: icmp_seq=1 ttl=64 time=0.262 ms (DUP!)

and:

[root@rts rc.d]# ping -c 2 224.0.0.1 -I eth1
PING 224.0.0.1 (224.0.0.1) from 10.7.35.2 eth1: 56(84) bytes of data.
64 bytes from 10.7.35.2: icmp_seq=1 ttl=64 time=0.238 ms
64 bytes from 10.7.35.1: icmp_seq=1 ttl=255 time=0.920 ms (DUP!)

and:

[root@rts rc.d]# ping -c 2 224.0.0.1 -I eth2
PING 224.0.0.1 (224.0.0.1) from 192.168.2.4 eth2: 56(84) bytes of data.
64 bytes from 192.168.2.12: icmp_seq=1 ttl=64 time=0.251 ms
64 bytes from 192.168.2.26: icmp_seq=1 ttl=64 time=0.259 ms (DUP!)

 
> If nothing else, you have to ensure that Netfilter isn't causing your
> problem now:

My multicast app uses ports 10000-10050.

I'm not too concerned with blocking traffic right at the moment, just 
quickly getting multicast flowing.


> What do you see with the commands: `ip mroute show ; ip maddr show`?

[root@rts rc.d]# ip mroute show
[root@rts rc.d]#

[root@rts rc.d]# ip maddr show
1:      lo

        inet  224.0.0.1
2:      eth0

        link  01:00:5e:00:00:01

        inet  224.0.0.1
3:      eth1

        link  01:00:5e:00:00:01

        inet  224.0.0.1
4:      eth2

        link  01:00:5e:00:00:01

        inet  224.0.0.1



> > talk to all the multicast machines over all the interfaces????
> 
> That is somewhat beyond the limits of linux route, and more in the
> domain of a traffic router like mrouted, Zebra or pimd.

ok. maybe that is what I need?
 
>    you can also transport multicast traffic and IPv6 through a GRE
>    tunnel.
> 
>     -- http://lartc.org/howto/lartc.tunnel.gre.html
> 
> So this might be an option to your 10.7.35.1 box, if they let you tunnel
> GRE to it. But you haven't said if they do. Also, full ip tunneling is a
> high-overhead solution. A dedicated pimd/Zebra/mrouted process would
> probably be more efficient. See two below.

Overhead is probibly bad. I need a very fast low delay solution for the 
multicast.

> Netfilter and ip route both have their uses, and are part of potential
> solutions, but depending on exactly what your problem is, you may need
> the full solution of a router daemon. See below.
> 
> > As I said above, 10.7.35.1 is the ethernet side of the T1 on my side that 
> > is plugged into my rts's eth1. It also runs PIM-DM like everything else on 
> > the other side of the T1. Anything destined for 10.7.* gets directed to 
> > 10.7.35.1 and it deals with them.
> 
> You need to write down everything to do with 10.7.35.1:

Well, how about this:

IOS (tm) C2600 Software (C2600-IK9S-M), Version 12.2(15)ZJ2

2 FastEthernet/IEEE 802.3 interface(s)
1 Serial network interface(s)
1 Virtual Private Network (VPN) Module(s)

Hardware is AmdFE, address is 000d.29cd.7340 (bia 000d.29cd.7340)
  Internet address is 10.7.35.1/24
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, 
  Encapsulation ARPA, loopback not set

Hardware is PQUICC with Fractional T1 CSU/DSU
  Description: Sprint FR port
  MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec, 
  Encapsulation FRAME-RELAY, loopback not set

Hardware is PQUICC with Fractional T1 CSU/DSU
  Description: PVC to McLean
  Internet address is 172.16.200.2/30
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, 
  Encapsulation FRAME-RELAY

Hardware is Virtual Access interface
  MTU 1492 bytes, BW 100000 Kbit, DLY 100000 usec, 
  Base PPPoE vaccess, loopback not set

Hardware is Tunnel
  Description: IPSEC tunnel Here-to-there
  Internet address is 172.17.200.2/30
  MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, 
  Encapsulation TUNNEL, loopback not set
  Tunnel source 172.16.200.2, destination 172.16.200.1
  Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
  Tunnel TTL 255
  Checksumming of packets disabled,  fast tunneling enabled

 
> 1. Will it accept straight multicast packets, and forward them via 
>    PIM-DM to the foreign networks, or

They say it will except any multicast traffic on the 10.7.35.0 subnet and 
forward it to the other sites. Also it will bring multicast traffic from 
the other sites and drop it on the subnet.
 
> 2. Does it (or its admins) expect you to speak *only* PIM-DM to it? (PIM
>    sounds like it routes multicast packets by tunneling via standard IP 
>    packets, and is not multicast itself.)

hmm. not sure, but I see that it has GRE tunnel over the T1. They also are 
using IPSec over the T1 to encrypt the data.
I'm not sure what you mean by "speak PIM-DM to it"?
I was under the impression PIM-DM on a router meant that it took any 
multicast traffic on a port and dumped it on all its other ports whether 
there was a multicast client on that port or not.


> And let's face it: if you're going to need to run a PIM router daemon to
> 10.7.35.1 anyway, you may as well skip everything else and have it route
> your multicast packets between your two LANs and use iptables to block
> other traffic.

Is it easy to start up a router daemon and just tell it to toss any 
multicast over the wall as fast as it can?

> If, on the other hand, your answer is yes to 1, then we have other
> options. For instance, what other services does rts provide besides
> linking the two LANs and the T1? If the answer is 'None,' then perhaps

The answer is none. It only forwards packets between the subnets.
I was planning to run ethereal on it to monitor traffic flow.

Thanks,
John