Multicast-prac - Lecture notes 7 PDF

Preview

Summary

una buena practica de multicast...

Description

MULTICAST 0.4 IP multicast addresses and DNS 224.0.0.0/24 →Local Subnet, packets sent from all-hosts (224.0.0.1) with TTL=1, not forwarded by routers (224.0.0.2). 224.0.1.0/24→ widely-known protocols i.e. 224.0.1.1 is the NPT protocols 239.0.0.0/24→ Administratively Scoped $phyhost: host all-systems.mcast.net → all-systems.mcast.net has address 224.0.0.1 This command allows to send requests to the DNS server. The address 224.0.0.1 identifies all multicast hosts on the same network segment (TTL=1). $phyhost: host 224.0.0.22 22.0.0.224.in-addr.arpa domain name pointer igmp.mcast.net. This address identifies routers using IGMPv3 0.5 MAC multicast addresses $server: ping -c1 224.0.0.1→ the ping doesn’t receive response 1. How many ICMP packets can you see in SimNet3? What type of messages? One icmp-request packet. 2. In the IP header, which is the TTL of this packets? What does this mean? The TTL=1 this means server pings multicast hosts on his network segment. That is, the packets will only pass through 1 node (R2) before being discarded. Re-sent if fail is not wanted. 3. In the IP header, which are the source and destination addresses? @Ips:172.16.1.3 @Ipd:224.0.0.1 4. In the Ethernet header, which are the source and destination addresses? @MACs: fd:fe:00:00:03:01 @MACd: 01:00:5e:00:00:01 5. Can you see the direct mapping in the MAC destination address? @Ipd:224.0.0.1 0 1 2 3 4 5 6 7 8 9 15 16 23 24 31 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1

@MACd: 01:00:5e:00:00:01 01 0000 0001

00 0000 0000

5E 0101 1110

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1

$phyhost: ping -c1 232.0.0.1 1. In this ICMP packet, which is the destination MAC addresses? @MACd: 01:00:5e:00:00:01 (the same as last ping) 2. Can you see any ambiguity in this mapping? Which other addresses cause also this ambiguity? Yes, all the addresses with the structure 1110 XXXX. X000 0000. 0000 0000. That is, all the IP addresses that only differ in ambiguous (X) bits will be mapped to the same MAC address. 3. How can the system resolve this ambiguity? The host look to the multicast IP address (no ambiguity) and discards the packets with an unregistered IP.

$server: echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts → Tell Linux to don’t ignore broadcast/multicast icmp-echo messages. $server: ping -c3 224.0.0.1 → The three pings work. 1. Who is now answering to the ping? The server himself (172.16.1.3). 2. Can you see any reply message in SimNet3? No because the server answered himself. 3. Are the answer packets sent in a multicast way? Yes but only in the net of the server (TTL=1). $R2: echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts $server: ping -c3 224.0.0.1 1. Who is now answering to the ping? R2 (172.16.1.1) 2. Can you see any reply message in SimNet3? Yes, one for each request. 3. Are the answer packets sent in a multicast way? No, the answer packets are sent in a unicast way. Delivered directly from R2 to server. Note: Requests have TTL=1 but replies have default value TTL=64 because we forced that response. 0.6 Multicast transmission in a subnet 0.6.1 Multicast configuration A multicast group to send data: in our case you will use the multicast group 232.43.211.234. A multicast group to control and add reliability, and you will use 225.1.2.3. $server1: cat /prot/net/igmp Idx 1

Device lo

5

eth1

: Count Querier Group Users Timer : 1 V3 010000E0 1 0:00000000 : 1 V3 010000E0 1 0:00000000

Reporter 0 0

We can see the interfaces that are joined to certain groups. Eth1 and lo joined to010000E0 == 1.0.0.224 group. Note: we can do netstat -gn too. 0.6.3 udp-sender $server0: udp-sender server# udp-sender –file=./big_664.mpg --min-clients 1 --portbase 22345 --nopointopoint --interface eth1 --ttl 1 --mcast-addr 232.43.211.234 \ --mcast-all-addr 225.1.2.3 --file=./big_664.mpg Reads data to be transmitted from file. If this parameter is not supplied, data to be transmitted is read from stdin instead. --min-clients 1 Automatically start as soon as a minimal number of clients have connected.

--portbase 22345 Default ports to use for udpcast. Two ports are used: portbase and portbase+1 . Thus, Portbase must be even. Default is 9000. The same portbase must be specified for both "udp-sender" and "udp-receiver". --nopointopoint Don't use point-to-point, even if there is only one single receiver. --ttl 1 Sets the time-to-live parameter for the multicast packets. Should theoretically allow to use UDPCast beyond the local network, but not tested for lack of a multicast router. --mcast-addr 232.43.211.234 Uses the given address for multicasting the data. If not specified, the program will automatically derive a multicast address from its own IP (by keeping the last 27 bits of the IP and then prepending 232). --mcast-all-addr 225.1.2.3 Uses a non-standard multicast address for the control connection (which is used by the sender and receivers to "find" each other). This is not the address that is used to transfer the data. By default "mcast-all-addr" is the Ethernet broadcast address if "ttl" is 1, and 224.0.0.1 otherwise. This setting should not be used except in very special situations, such as when 224.0.0.1 can-not be used for policy reasons. 1. How many packets can you see? Which type of packets? We can see three packets. One UDP packet and two IGMP for contacting destination. 2. In the UDP packet, which is the destination address? and the TTL? On the UDP packet the destination is 172.16.1.3 (server)→225.1.2.3 (mc control address). The TTL=1(*) (set on udp-sender). 3. Which are the port numbers? 22346→22345 (*)In this particular case is optional, because applications that do not specify the TTL should put 1 as default value for multicast packets. However, remember to put the proper TTL when trying to reach remote destinations. 4. Can you see any IGMP packet? Which type of packet? Which is the IP destination address of this IGMP messages? We can see two igmp-membership-report/join-group 225.1.2.3 with destinations 172.16.1.3(server)→224.0.0.22(routers using IGMP). These messages aren’t answered because there isn’t any multicast router. $server1: cat /proc/net/igmp Idx Device : Count Querier Group Users Timer 1 lo : 1 V3 010000E0 1 0:00000000 5 eth1 : 2 V3 030201E1 1 0:00000000 010000E0 1 0:00000000

Reporter 0 0 0

Now we can see there is another group joined to eth1 030201E1 == 3.2.1.225 (mc control) When we stop the sender (Ctrl+C) appear two igmp-membership-report/leave-group 172.16.1.3(server)→ 224.0.0.22(routers using IGMP). The group is no longer at /proc/net/igmp.

0.6.4 udp-receiver $R2:cat /proc/net/igmp → we can see that eth1,eth2 and lo are joined to 224.0.0.1 group. $R2:udp-receiver --file=big_664.mpg --mcast-all-addr 225.1.2.3 --ttl 1 --portbase 22345 This command prepares R2 to receive a video via multicast, which should be stored locally with name big_664.mpg. In SN2(*): We can see two UDP packets 198.51.100.2 (R2 eth2) → 225.1.2.3 (mc control) with ports 22345→22346. The TTL=1. Those are sent to contact the server (not launched). Two igmp-membership-report/join-group 225.1.2.3 198.51.100.2 (R2 eth2) → 224.0.0.22 (routers igmp). Those are for joining control multicast group (but no multicast router). The petitions are sent to 224.0.0.2 (mcrouters identifier) but to join 225.1.2.3 group. (*):The udp-sender has an option to set the if to send packets. We didn’t set that so the app uses the default unicast route (for eth2). So we only see the packets on SN2. When we stop the udp-receiver the appear two igmp-membership-report/leave-group 0.6.5 Sending the video file in the subnet $server:udp-sender --file=./big_664.mpg --min-clients 1 --portbase 22345 --nopointopoint --interface eth1 --ttl 1 --mcast-addr 232.43.211.234 --mcast-all-addr 225.1.2.3 $R2:udp-receiver --file=big_664.mpg --mcast-all-addr 225.1.2.3 -ttl 1 --interface eth1 --portbase 22345 The transmission is OK. In SN3 we can see one UDP and two igmp-membership/join-group 255.1.2.3. • Let us start analyzing the four initial UDP packets of short-length. 1. What do you think is the purpose of these initial packets? Those are sent with the purpose to sender and receiver recognize themselves, exchanging key info for the transmission. 2. In the first UDP packet sent by server, which is the IP destination address? 172.16.1.3→ 255.1.2.3 Sent by the sender to probe the net (Hay alguien ahí?). 3. Do you recognize anything inside of the DATA field of this packet? Try to convert 232.43.211.234 in hex. E8.2B.D3.EA the HEX value of mc address chosen by the sender is inside the DATA (after 16 less sig bits). 4. At the time this first packet was sent by the server, was R2 listening at the control multicast address? NO, so the sender doesn’t get response. 5. What do you think is the purpose of the second and third UDP packets (the ones sent by R2)? Those are sent by R2 to probe the net (Hay alguien ahí?). Perque 2 cops? 6. At this time, does R2 know which is the data multicast group that server is going to use to send the video? No, this information is on the last UDP packet sent from server.

7. Have a look to the fourth UDP packet. Is it a multicast or unicast packet? What is the purpose of this message? Do you recognize anything in the data field of the packet? Before the fourth UDP packet, the server do ARP to know the R2 unicast address. So the fourth packet is sent unicast (max clients = 1). Server has to “send again” the first UDP packet, now with R2 listening. The main purpose is to inform R2 the data multicast group that has to join (in HEX on the header). Looking at igmp packets: I.172.16.1.3→ 224.0.0.22 igmp-membership/join-group 225.1.2.3 II.172.16.1.1→224.0.0.22 igmp-membership/join-group 225.1.2.3 III.172.16.1.1→ 224.0.0.22 igmp-membership/join-group 232.42.211.234 + anterior III.172.16.1.3→ 224.0.0.22 igmp-membership/join-group 225.1.2.3 • Regarding the transmission of the video (look at packets that are full of information): 1. Which is the destination IP address of these packets? The destination is 232.43.211.34 2. What is the size of most of this data packets? The size is mostly 1514 bytes. 3. There are some unicast packets from R2 to server. What do you think is the purpose of these feedback packets? After an ARP there are some unicast packets with a reliability purpose. There are several packets so it’s good to make sure that the receiver keeps alive. In the end of the transmission we can see a dialogue of 4 interlaced leave-group messages. 0.7 Multicast and routing $R2: iptunnel add tunnel0 mode gre local 198.51.100.2 192.0.2.2 dev eth2 $R2: ifconfig tunnel0 192.168.110.1 $R2: route add -net 192.168.0.0/24 dev tunnel0

remote

We can use the script to add all the tunnels: $phyhost: exec addtun $server: ping -c1 192.168.0.2 (host2) 1. Is the ping working? Yes, we are sending 56 bytes of data. 2. Can you see packets in the wireshark? What type of packets? Describe the headers you see. Analyzing SN2 we can see one icmp-request and one icmp-reply. Both packets have the following headers: Ethernet(14), IPo(20), GRE(4), IPi(20), ICMP(8). 3. Regarding the IP outer header, which are the source and destination addresses? If we observe IP outer header the addresses are 198.51.100.2→192.0.2.2 4. Which is the size of the GRE header? Is a fixed value of 4 bytes. 5. Which is the source and destination addresses in the inner header? 172.16.1.3→192.168.0.2 Send also a ping from the server to host4 to verify that tunnel1 works.

0.7.3 Multicast static routing: smcroute $R2: /proc/net/ip_mr_vif → Empty $R2: smcroute -d → Start the daemon Now if we take a look on ip_mr_vif file we can see the interfaces of R2 and the two tunnels connected to it. $R2: smcroute -a eth1 0.0.0.0 232.43.211.234 tunnel0 This command will route IP datagrams entering through eth1 with any origin address and destination address 232.43.211.234 (mc group) towards the tunnel (so they will reach the other island). $R2: smcroute -j eth1 232.43.211.234 Join the entry eth1 (also the tunnel0?) to the mc group If we look at /proc/net/igmp file we can see the devices lo,eth1,eth2,tunnel0 and tunnel1. The if eth1 have the “default host id” multicast adress and also the mc group adress. On SN3 we can see two igmp-membership/join from 172.16.1.1 (R2 eth1) to 224.0.0.22 (mc routers). $server: ping -c1 -t3 232.43.122.234 Send a ping from server to mc group with 3 hops scope. 1. Is the ping working? In which SimNets can you see ICMP packets? NO. We only see two packets in SN1 and one in SN2. 2. Can you see any encapsulation in the ICMP packet in SimNet1 and SimNet2? What is the size of a GRE header? Yes, in both SN we have the GRE encapsulation. The GRE is 4 bytes again. 3. Have a look again to file /proc/net/ip_mr_vif. Do you see any change in the statistics related to tunnel0? Yes, now we can see 168 “BytesOut” on the statistics of tunnel0. 4. Execute ip mroute show to see the Multicast Forwarding Cache. What is the meaning of all these parameters? (172.16.1.3, 232.43.211.234) Iif: eth1 Oifs: tunnel0 ??? 5. Why do you think R1 is not forwarding the packet The R1 router is not configured in a mc way so the packet is not processed and sent to SN0. Now we configure R1 as a mc router, entering through the tunnel with any origin address and destination address the multicast group 232.43.211.234 towards eth1: $R2: $R1: $R1: $R1:

echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts smroute -d smcroute -a tunnel0 0.0.0.0 232.43.211.234 eth1 smcroute -j tunnel0 232.43.211.234

$server: ping -c1 -t3 232.43.211.234

1. Can you see the packets in SimNet0? Which type of packets? On SN0 we observe one icmp-request packet. We see the join-group petitions on SN1 and also icmp-ttl-exceeded. 2. Can you see any ICMP Echo Reply? Why? There isn’t request in SN0 because the host is not running any app to respond that petition. We only see the reply in SN3 (subnet of the server) but sent from R2 unicast. 3. Which is the TTL value of this packet in SimNet0? TTL=1, that is 3-R2-R1 4. If you send the same ping from server but with TTL=2, would it work? The ping works because R2 answers???? with but we don’t see the message through SN0 so it doesn’t reach host2. 0.7.4 Testing Tools ssmping Allows to verify if a host can receive SSM (Source Specific Multicast) packets from another host, by sending unicast and multicast UDPpackets (remember that TCP does not support multicast traffic). $server(0): ssmpingd → We start the daemon and packets will be sent from here $server(1): netstat -gm → To view if server has joined to any mc group $host2(0): ssmping 172.16.1.3 (server) $host2(1): netstat -gm 1. What output can you see in host2? and in server? This messages alternated: multicast from 172.16.1.3, seq=16 dist=2 time=1.731 ms unicast from 172.16.1.3, seq=17 dist=2 time=3.006 ms ... This message all the time: received request from 192.168.0.2 ... 2. According to this output, do you consider that the multicast routing is working? Yes, the tool is testing both unicast and multicast routing. Host2 is making a request to server and he answers (unicast). Then server sends multicast packets to mc group. Notice that the behavior is periodical, and groups of three UDP packets are sent every second. 1. What is the destination and origin address of the first packet? Is a unicast or multicast packet? 192.168.0.2→172.16.1.3 UDP 80 33300 → 4321 Len=38 That’s an unicast packet from host2 to server. 2. And the second one? What is the purpose of these two packets? 172.16.1.3→192.168.0.2 UDP 80 4321 → 33300 Len=38 That’s also a unicast packet but from server to host2. The purpose are for testing the connection between the two machines before test multicast. 3. Is the third packet different? Who is the origin and destination? Unicast or multicast? So, what is this packet testing? Unidirectional or bidirectional? 172.16.1.3→232.43.211.234 UDP 80 4321 → 33300 Len=38

This packet is multicast and it goes from server to multicast group adress. So it tests multicast in a unidirectional way (from server to host2). Regarding IGMP packets: 1. In SimNet0, can you see any IGMP Message? What kind of message? Which is the multicast group involved? Two of this: 192.168.0.2→224.0.0.22 Membership Report / Group 232.43.211.234, new source {172.16.1.3} / Join group 232.43.211.234 for source {172.16.1.3} And also two: 192.168.0.2 224.0.0.22 Membership Report / Group 232.43.211.234, block source {172.16.1.3} when stopping the test application in host2. If we stop the daemon, host2 reports errors (connection refused) and when we stop he sends the block source too. 2. Is this information coherent with what you see using netstat -gn? Yes, there’s a line that indicates eth1 has joined mc group and when we stop ssmping that line disappears. 3. Is there any other IGMP message in the rest of networks? No, we only have igmp in the net of the machine who is being tested by the server (SN0). If we do the same test but in a reverse way (server requests host2), it works but only in the unicast way. We can see that server is sending (and being answered) unicast to host2. But despite host2 is sending UDP to mc group (and appears the join on netsat -gn of server), we don’t see the mc transmission on the server app. That’s because the configuration of the tree (smcroute) that is from R2 to R1, so the mc packets are lost. mcsender and emcast $server: mcsender -t3 232.43.211.234:12345 → Send packets to the multicast group 232.43.211.234 using the UDP port 12345 with a scope of three hops. $host2: emcast 232.43.211.234:12345→Join group 232.43.211.234 using UDP port 12345. 1. What output can you see in host2? And in server? This is the test message from mclab/mcsender. Nothing. 2. According to this output, do you consider that the multicast routing is working? Yes, the app emcast is working not reporting any error. If we look at netstat -gn eth1 joins mc group 3. What is the destination and origin address of the packets? Are they unicast or multicast? 172.16.1.3→232.43.211.234 (multicast) 4. Can you see any IGMP Message? Where? What kind of message? Which is the multicast group involved? Two of this: 192.168.0.2→224.0.0.22 Membership Report / Join group 232.43.211.234 for any sources And when we close the emcast two of this: 192.168.0.2→224.0.0.22 Membership Report / Leave group 232.43.211.234 We also see the UDP from server to mc group all transmission long.

0.7.5 Trees with multiples branches R2: smcroute -k R2: smcroute -d R2: smcroute -a eth1 0.0.0.0 234.43.211.234 tunnel0 tunnel1→Now we put the two tunnels as output inferfaces. R2: smcroute -j eth1 232.43.211.234 To test that configuration we use ssmping: $server: ssmpingd $host2: ssmping 172.16.1.3 $host4: ssmping 172.16.1.3 1. Is ssmping working? What output message can you see in host2? host4? And in server? Yes in both hosts. In host2 we can see the unicast/multicast output messages and in host4 only multicast. In server we can see “recieved request from” and the IP of both hosts alternated. 2. What will deduce from this output messages? What do you consider is missing? The only host who is really testing the multicast communication is host2. Host4 only works unicast because R3 branch configuration is missing. 3. Have a look to SimNet4, what type of messages can you see? unicast or multicast? And in SimNet5? In SN4 we can see the period formed by: two unicast messages (host4-server, server-host4) ant then two mc messages from server to mc group. In SN5 we only see periods of two unicast messages. To be able to test multicast in both islands, we have to configure R3: $R3: smroute -d $R3: smcroute -a tunnel1 0.0.0.0 232.43.211.234 eth1 $R3: smcroute -j tunnel1 232.43.211.234 Faltaria fer el test amb mcsender/emcast 0.7.6 Sending the video Assuming that we can flow mc traffic from SN3 to both SN0 and SN5 (group 232.43.211.234) now we have to configure routers for the mc control group with address 225.1.2.3. (Assuming that any tree is configured) R2:~# R2:~# R2:~# R2:~# R2:~#

smcroute smcroute smcroute smcroute smcroute

-d -a -j -a -j

eth1 eth1 eth1 eth1