search

troglobit / pimd

PIM-SM/SSM multicast routing for UNIX and Linux
http://troglobit.com/projects/pimd/
BSD 3-Clause "New" or "Revised" License
197 stars 87 forks source link

Tunnel interfaces with multicast #43

Closed greenpau closed 9 years ago

greenpau commented 9 years ago

I have a tunnel interface 

26: tun1@NONE: <POINTOPOINT,MULTICAST,NOARP,ALLMULTI,UP,LOWER_UP> mtu 1460 qdisc noqueue state UNKNOWN 
    link/gre 10.10.1.1 peer 192.168.16.66
    inet 10.254.0.12 peer 10.254.0.11/32 scope global tun1
       valid_lft forever preferred_lft forever

I can see PIMv2 Hello packet being send out of tun1 interface.

11:35:52.554834 IP ny-rt01 > igmp.mcast.net: igmp v2 report igmp.mcast.net
11:35:54.074839 IP ny-rt01 > pim-routers.mcast.net: igmp v2 report pim-routers.mcast.net
11:35:58.394837 IP ny-rt01 > all-routers.mcast.net: igmp v2 report all-routers.mcast.net
11:36:12.189511 IP ny-rt01 > pim-routers.mcast.net: PIMv2, Hello, length 10
11:36:42.220039 IP ny-rt01 > pim-routers.mcast.net: PIMv2, Hello, length 10

The interface is registered to forward multicast traffic. 

# cat /proc/net/ip_mr_vif 
Interface      BytesIn  PktsIn  BytesOut PktsOut Flags Local    Remote
 2 tun1              0       0         0       0 00000 0C00FE0A 0B00FE0A
 3 pimreg            0       0         0       0 00004 0C00FE0A 00000000
#

However, the packets never make it to the physical interface and to the other end of that tunnel. Unicast traffic, i.e. BGP and ICMP, works without any issue.

Any idea why that is happening?

troglobit commented 9 years ago

My bet would have been on the MTU, but what's listed above is plain control traffic so it should work. The packet counters look very much at zero though ... have you tried tcpdump:ing tun1, or forcing out any multicast with regular old ping? 

ping -I tun1 225.1.2.3

With a tcpdump in another terminal

tcpdump -i tun1
greenpau commented 9 years ago

@troglobit , I see it:

sending:

ping -I tun1 225.1.2.3

capturing:

13:39:34.693214 IP ny-rt01 > 225.1.2.3: ICMP echo request, id 11083, seq 1, length 64
13:39:35.692925 IP ny-rt01 > 225.1.2.3: ICMP echo request, id 11083, seq 2, length 64
13:39:36.694013 IP ny-rt01 > 225.1.2.3: ICMP echo request, id 11083, seq 3, length 64
13:39:37.693925 IP ny-rt01 > 225.1.2.3: ICMP echo request, id 11083, seq 4, length 644

MTU size is 1460:

26: tun1@NONE: <POINTOPOINT,MULTICAST,NOARP,ALLMULTI,UP,LOWER_UP> mtu 1460 qdisc noqueue state UNKNOWN mode DEFAULT
greenpau commented 9 years ago

@troglobit , the issue is resolved. It was TTL value on the tun1.

Added the following to interface configuration:

MTU=1460
TTL=10

Now, I can see the hellos:

18:18:55.685932 IP 10.254.0.12 > pim-routers.mcast.net: PIMv2, Hello, length 10
18:19:25.626935 IP ip-192-168-16-66 > pim-routers.mcast.net: PIMv2, Hello, length 10
18:19:25.626969 IP ip-192-168-16-66 > pim-routers.mcast.net: PIMv2, Hello, length 10
18:19:25.692172 IP 10.254.0.12 > pim-routers.mcast.net: PIMv2, Hello, length 10

What is the command to get the list of PIM neighbors?

troglobit commented 9 years ago

Aha, didn't know about TTL being limited like that on tun interfaces.

There isn't any specific command for that (yet), but you can see neighbors with pimd -r or sending SIGUSR1 to the running pimd. The pimd -r sends SIGUSR1 for you and then dumps the contents of /run/pimd/pimd.dump on stdout. Hope this helps!

greenpau commented 9 years ago

@troglobit , it does :+1: It makes me want to be a better coder :smile_cat: so I can fix it :smoking: