1 / 69

Internet2 IPv6 Multicast Workshop Albuquerque, New Mexico February 2006

Internet2 IPv6 Multicast Workshop Albuquerque, New Mexico February 2006. TODO. Anyone want to provide some Juniper info? Some config examples for enabling embedded-RP, multicast BGP peerings and scope boundaries would be good Interdomain lab details

krock
Télécharger la présentation

Internet2 IPv6 Multicast Workshop Albuquerque, New Mexico February 2006

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Internet2IPv6 Multicast WorkshopAlbuquerque, New MexicoFebruary 2006

  2. TODO • Anyone want to provide some Juniper info? • Some config examples for enabling embedded-RP, multicast BGP peerings and scope boundaries would be good • Interdomain lab details • dbeacon details, beacon client and web access at NYSERNet? • vlc details, hopefully vlc stream from NYSERNet • Suggestions for other things to add? I think we got spare time, but I’m out of ideas • Anything that needs to be expanded or explained better? • Feel free to contribute slides or change mine • Or tell me what you think I should change

  3. Acknowledgements Stig Venaas Bill Owens UNINETT NYSERNet

  4. Preliminaries • Introductions • Instructors • Students • Who has Juniper experience? • Workshop schedule

  5. Contents • Overview and Addressing • Multicast on the LAN • Lab 1 • Intradomain Multicast • Lab 2 • Interdomain Multicast • Lab 3

  6. Overview and Addressing

  7. Current IPv6 multicast deployment • A tunneled multicast network called M6Bone was established in France in 2001 • Today more than 50 sites from four continents are connected • Networks like Abilene, GEANT and NORDUnet have native IPv6 multicast in their production networks and native peerings • E.g. NYSERNet in NY and UNINETT (the Norwegian academic network) have also native connectivity to Abilene and NORDUnet resp. So there is native IPv6 multicast all the way from NY to Norway • The M6Bone has both a web site and a mailing list for information and discussion on IPv6 multicast • Web site at http://www.m6bone.net/ • Mailing list m6bone@ml.renater.fr • The largest router vendors have IPv6 multicast support on most of their routers. Many other vendors have some support, or plan to offer support soon

  8. IPv6 multicast addresses Scopes: 0 Reserved 1 Interface local 2 Link local 3 Reserved 4 Admin local 5 Site local 6-7 Unassigned (admin) 8 Organization local 9-D Unassigned (admin) E Global F Reserved IPv6 multicast addresses are in the range FF00::/8 Flag bits: 0 R P T T = 0 – permanent IANA assigned address T = 1 – transient address (not IANA) P = 1 – derived from unicast prefix (RFC 3306) R = 1 – embedded-RP address (RFC 3956)

  9. Unicast prefix based addresses • Unicast prefix based addresses are defined in RFC 3306 • Flags are set to 3 (P=T=1) • Reserved must be 0 • Plen is the length of the prefix used • Prefix is a unicast prefix • The group ID consists of any 32 bits • In this way every site will have many multicast addresses unique to them • One can also use /64 prefixes to get addresses unique to a link • Example: • Site with unicast prefix 2001:db8:1::/48 • Example multicast address ff3e:30:2001:db8:1:0:dead:beef

  10. Embedded-RP addresses • Embedded-RP addresses are defined in RFC 3956 • Variation of the unicast prefix based addresses • Flags are set to 7 (R=P=T=1). R is a new flag for embedded-RP • Reserved must be 0 • RIID contains the last 4 bits of the RP address • Plen is the length of the prefix used • Prefix is a unicast prefix • The group ID consists of any 32 bits • One may use /64 prefixes as well to have an RP per link • Example: • Site with unicast prefix 2001:db8:1::/48 can pick RP address2001:db8:1::a • Example multicast address ff3e:0a30:2001:db8:1:0:dead:beef

  11. SSM addresses • SSM addresses are special subset of unicast prefix based addresses • Flags are set to 3 (P=T=1) • Reserved must be 0 • Plen is set to 0 • Prefix is set to all zeroes • The group ID consists of any 32 bits • This results in ff3x::/96 for SSM (where x is any scope)

  12. Group IDs • Should generally be 32 bits, although it is possible to use 112 bits when not using any of the specific addressing schemes • When mapping IPv6 multicast groups to link-layer destination addresses, the last 32 bits are used. So one should try to always have different group IDs for different groups. • RFC 3307 specifies a scheme with 32-bit IDs as follows • 0x00000001 - 0x3fffffff Groups assigned by IANA • 0x40000000 - 0x7fffffff Group IDs assigned by IANA • 0x80000000 - 0xffffffff Server/host allocation • Note that IANA may assign group IDs, not just groups. This is something like scope relative addresses for IPv4. • Whenever using unicast prefix based addresses, embedded-RP addresses or SSM, you should pick group IDs according to this scheme

  13. Multicast on the LAN

  14. Multicast on the LAN • IPv6 (also unicast) relies on multicast on links • Neighbor discovery uses a number of groups • ff02::1, all-nodes link-local multicast • ff02::1:ffxx:xxxx, solicited node multicast address • xx:xxxx are the last 24 bits of the unicast address • The mapping from IPv6 addresses to ethernet multicast mac addresses is done by setting the first two octets to 0x33 and the last four to the last four octets of the IPv6 address • Hence as we said on the previous slide, unique group IDs result in unique mac addresses

  15. MLD – Multicast Listener Discovery • MLD is used between hosts and routers to signal which groups (and sources) a host is interested in • Similar to IGMP for IPv4, but uses ICMP • MLDv1 – RFC 2710 supports only ASM, similar to IGMPv2 • MLDv2 – RFC 3810 also supports SSM, similar to IGMPv3 • Router with lowest address on link elected as querier • Querier periodically (125s default) sends queries to ff02::1 to see whether there still is interest for current groups • MLD is used for all groups of scope 2 or larger • Except for ff02::1 • For robustness messages are retransmitted • Both the robustness and the timers can be tuned by querier

  16. MLDv1 • When hosts receive a general query they set a timer for each group they are interested in to a random value (0-10s default), and sends a report per group when the group’s timer expires • No report is sent if the host receives another host’s report before timer expires • The report is sent to the group itself (the one being reported) • Host sends unsolicited report when it starts listening to a group • If host stops listening to a group, it sends done message to ff02::2 • When querier receives done message, it sends a multicast-address specific query to check if there still are listeners • Sent to the group itself • Hosts that are interested respond after random delay (with suppression)

  17. MLDv2 1/2 • When hosts receive a general query they wait for a random period of time (0-10s default), and then reports all state • There may be multiple groups in one packet • Reports are sent to ff02::16 and no suppression • This makes life easier for snooping switches • Host sends unsolicited report when listening state changes • No done message, reports are used • When querier sees that a host leaves a source/group, it sends a multicast-address specific query to check if there still are listeners • Sent to the group itself • All hosts that are interested respond after random delay

  18. MLDv2 2/2 • MLDv2 has two modes, INCLUDE and EXCLUDE • INCLUDE allows joining specific sources, SSM • For SSM, sources must be specified • EXCLUDE allows blocking specific sources, ASM • Normally for ASM you would block no sources • MLDv2 hosts and routers are backwards compatible with MLDv1 • MLDv2 routers and hosts fall back to MLDv1 for a given group if there are MLDv1 reports for the group • Hosts and routers fall back to MLDv1 on an interface (for all groups) if an MLDv1 query is received • The MLDv1 compatibility mode may expire

  19. MLD on Routers 1/4 To see group memberships we can do: cisco> show ipv6 mld groups MLD Connected Group Membership Group Address Interface Uptime Expires FF1E::1:F00D:BEAC FastEthernet1 3w1d 00:02:58 FF3E::BEAC FastEthernet1 3w1d not used juniper> show mld group Interface: fe-0/0/1.0 Group: ff1e::dead:beef Last Reported by: fe80::2e0:09ff:fe12:34ab Timeout: 213 Type: Dynamic • Note that the last one is an SSM group and we don’t see which sources are joined • Also, there is no expiry, because it’s the individual (S,G)-entries that expire

  20. MLD on Routers 2/4 To see group memberships including sources we can do: cisco> show ipv6 mld groups detail Interface: FastEthernet1 Group: FF1E::1:F00D:BEAC Uptime: 3w1d Router mode: EXCLUDE (Expires: 00:03:50) Host mode: INCLUDE Last reporter: FE80::211:D8FF:FE8F:1F9B Source list is empty Interface: FastEthernet1 Group: FF3E::BEAC Uptime: 3w1d Router mode: INCLUDE Host mode: INCLUDE Last reporter: FE80::211:D8FF:FE8F:1F9B Group source list: Source Address Uptime Expires Fwd Flags 2001:200:0:8001:250:4FF:FEB7:481D 3w1d 00:03:50 Yes Remote 4 2001:468:900:302:200:5AFF:FE9B:2C64 3w1d 00:03:50 Yes Remote 4 2001:468:901:A:204:76FF:FE3B:2E0B 3w1d 00:03:50 Yes Remote 4 2001:468:914:200::2 3w1d 00:03:50 Yes Remote 4 2001:630:D0:F104:230:48FF:FE2A:CDE 3w1d 00:03:50 Yes Remote 4 2001:630:241:204:211:43FF:FEE1:9FE0 3w1d 00:03:50 Yes Remote 4

  21. MLD on Routers 3/4 We can also check status for the interfaces or one specific cisco> show ipv6 mld interface fastEthernet 1 FastEthernet1 is up, line protocol is up Internet address is FE80::2E0:F7FF:FE26:9ADA/10 MLD is enabled on interface Current MLD version is 2 MLD query interval is 125 seconds MLD querier timeout is 255 seconds MLD max query response time is 10 seconds Last member query response interval is 1 seconds MLD activity: 70 joins, 56 leaves MLD querying router is FE80::2E0:F7FF:FE26:9ADA (this system) juniper> show mld interface fe-0/0/1 Interface: fe-0/0/1 Querier: fe80::280:42ff:fe12:23de State: Up Timeout: 0 Version: 1 Groups: 1

  22. MLD on Routers 4/4 In configuration mode there are a number of ipv6 mld commands for changing query intervals and timeout etc, doing static joins, access lists… MLD is enabled by default on interfaces, to disable: cisco(config-if)#no ipv6 mld router protocols { mld { interface fe-0/0/1.0; disable; }

  23. Multicast and ethernet switches • Some switches don’t correctly forward multicast • One problem that has been observed several times, is that hosts can receive multicast for a couple of minutes, and then it stops • The likely reason for this is that the initial unsolicited report from the host reaches the router, but the host is not receiving MLD queries from the router. Try upgrading your switch software if possible • In order to restrict the flow of multicast, one may want to use MLD snooping • The first switches supporting MLDv2 are now available • Not aware of MLDv1 snooping switches • Due to snooping switches, hosts should also use MLD for link-local groups like the solicited node address • Only exception is the all-nodes address ff02::1 • One drawback is that all IPv6 hosts join solicited node address (and usually unique), so the switch will get a lot of state. Some switches may choose to flood these groups or possibly all link-local multicast

  24. Lab 1Multicast on the LANTime: Approx. ½ hour

  25. MLD and host state • Run ethereal and see what happens when you run ssmping • You should see some MLD packets • Try to look at the content • Check state on host • netstat –ngl (on MacOS X, netstat –ain) • cat /proc/net/mcfilter6 • cat /proc/sys/net/ipv6/mld_max_msf • You can write to mld_max_msf to increase maximum number of source filters • Stop ssmping and see what happens

  26. MLD and router state • Run ethereal • Enable IPv6 multicast routing on the edge routers (Customer D and Customer E) • Do you see any MLD packets? • Check the MLD state on the router • Check what groups hosts have joined, including link-locals • Check with ethereal what happens when you now run ssmping • You should see some MLD packets • Try to look at the content • Check state on the router, do you see the ssmping source and group?

  27. Intradomain Multicast

  28. PIM-SM • PIM-SM is the most commonly used multicast routing protocol • There is also IPv6 Bidir PIM for some router software versions • In principle PIM is the same for IPv4 and IPv6 • A new version of PIM-SM from the IETF • draft-ietf-pim-sm-v2-new, should be finished, but not RFC yet • It seems several vendors are using the new spec for IPv6 and the old (RFC 2362) for IPv4 • There are some changes you should be aware of • Link-local addresses are used for PIM messages, including hello’s • A new PIM hello option for listing all addresses, see next slide • Tunnel interfaces are used for PIM registers, see later slide

  29. Basic PIM config on IOS/JUNOS ipv6 multicast-routing routing-options { rib-groups { mcast-rpf6-rg { import-rib inet6.2; } } } protocols { pim { rib-group { inet6 mcast-rpf6-rg; } interface all { mode sparse; version 2; } } }

  30. PIM-SM – Address List Hello Option • In many cases one has routes where the next-hop is a global address. In order to find RPF neighbor, the router will then need to know the neighbors global address • Since PIM uses link-local addresses for most PIM messages, including hello, an address list hello option was added so a router can learn all addresses of the neighbor’s interface

  31. Showing PIM Neighbors Showing PIM neighbors cisco> show ipv6 pim neighborNeighbor Address Interface Uptime Expires DR pri Bidir FE80::260:47FF:FED5:C300 Ethernet1 00:00:16 00:01:28 1 (DR) B FE80::984E:6C02 Tunnel100 17:05:36 00:01:19 1 B juniper> show pim neighbors Instance: PIM.master Interface IP V Mode Option Uptime Neighbor addr ge-2/0/0.0 4 2 HPG 4w3d23h 192.168.2.1 ge-2/1/2.0 4 2 HPLG 4w3d23h 192.124.2.117

  32. Showing PIM Neighbors Above we got only the link-local addresses. Below we ask to also see that additional addresses from the PIM Hello address list option cisco> show ipv6 pim neighbor detail Neighbor Address(es) Interface Uptime Expires DR pri Bidir FE80::260:47FF:FED5:C300 Ethernet1 00:08:02 00:01:37 1 (DR) B 2001:700:1:1000::1 FE80::984E:6C02 Tunnel100 17:13:22 00:01:28 1 B 2001:630:D0:F000::7:1

  33. PIM-SM – Register tunnels • To simplify the specification, tunnel interfaces are used for encapsulation/decapsulation of PIM register messages • E.g. IOS creates and removes tunnel interfaces as needed for RPs • There may be some operational issues with that • When an RP goes away (not in RP-set or there is no route for RP address), the interface may go down and be removed • When an RP is added (or returns) a new tunnel is created • This does not necessarily re-use previous interface name • It might be hard for management tools etc to distinguish between such interfaces and other interfaces going up and down

  34. Register tunnels on IOS 1/2 • Showing the register interfaces on IOS • encap tunnel interface for each RP address in RP-set • decap tunnel interface for each of our own RP addresses trd-gw4>show ipv6 pim tunnel Tunnel0* Type : PIM Encap RP : 2001:660:3007:300:1:: Source: 2001:700:0:501::4 Tunnel3* Type : PIM Encap RP : 2001:700:0:501::4* Source: 2001:700:0:501::4 Tunnel4* Type : PIM Decap RP : 2001:700:0:501::4* Source: -

  35. Register tunnels on IOS 2/2 • We can also use the normal interface show commands • Packet counters might be useful for debugging trd-gw4> show int tu0 Tunnel0 is up, line protocol is up Hardware is Tunnel … Tunnel source 2001:700:0:501::4 (FastEthernet0/0), destination 2001:660:3007:300:1:: Tunnel protocol/transport PIM/IPv6, key disabled, sequencing disabled … Last input never, output 9w0d, output hang never … 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec … 0 packets input, 0 bytes, 0 no buffer 25722 packets output, 3837176 bytes, 0 underruns

  36. Register tunnels on JUNOS • Juniper uses a hardware Tunnel Services PIC to handle PIM register encapsulation and decapsulation. The interface designation will depend on the slot that the PIC is installed in. juniper> show interface Physical interface: pd-0/3/0, Enabled, Physical link is Up Interface index: 150, SNMP ifIndex: 34 Type: PIMD, Link-level type: PIM-Decapsulator, MTU: Unlimited, Speed: 12800mbps Device flags : Present Running Interface flags: SNMP-Traps Input rate : 0 bps (0 pps) Output rate : 0 bps (0 pps) Logical interface pd-0/3/0.32772 (Index 84) (SNMP ifIndex 0) Flags: Point-To-Point SNMP-Traps 16384 LinkAddress 0-0---10020000000000000000000000000000 Encapsulation: PIM-Decap Input packets : 0 Output packets: 0 Protocol inet, MTU: Unlimited Flags: None

  37. PIM-SM – RP-set configuration • Routers can learn their RP-set via static configuration or BSR • Routers may also learn RPs from embedded-RP • Router learns the RP when it sees a multicast packet or a join/prune with embedded-RP address • Embedded-RP results in the RP-set being highly dynamic • IOS has started to use one fixed tunnel interface for embedded-RP to reduce amount of tunnel interfaces going up and down

  38. Embedded-RP tunnels on IOS • This router has a permanent embedded-RP tunnel oslo-gw8>show ipv6 pim tunnel Tunnel0* Type : PIM Encap RP : 2001:660:3007:300:1:: Source: 2001:700:0:F000::1 Tunnel5* Type : PIM Encap RP : Embedded RP Tunnel Source: 2001:700:0:F000::1

  39. RP-set configuration on IOS 1/2 • Here we have statically configured one RP • We use acl, else for ff00::/8 • Embedded-RP on by default ipv6 pim rp-address 2001:660:3007:300:1:: rpm6bone ! ipv6 access-list rpm6bone permit ipv6 any FF0E::/16 permit ipv6 any FF1E::/16 permit ipv6 any FF3E::/16 • This router has the above config, but is also an embedded-RP ipv6 pim rp-address 2001:660:3007:300:1:: rpm6bone ipv6 pim rp-address 2001:700:0:F000::1 rpemblo1 ! ipv6 access-list rpemblo1 permit ipv6 any FF7E:140:2001:700:0:F000::/96

  40. RP-set configuration on IOS 2/2 • Recommend leaving embedded-RP on, but can be disabled no ipv6 pim rp embedded • Some IOS versions support BSR, and is enabled by default. You probably want to block BSR on external interfaces • Although IOS may support scoped BSR where you may have your own internal RPs and learn RPs for only global groups externally interface … ipv6 pim bsr border

  41. RP-set configuration on JUNOS • Again, we have statically configured one RP • Embedded-RP off by default protocols { pim { rp { embedded-rp; static { address 2001:660:3007:300:1:: { group-ranges { ff0e::/16; ff1e::/16; } } } } }

  42. Checking RP-set on IOS • To check what RP-set is in use on IOS, use show ipv6 pim range-list • or show ipv6 pim group-map • This is particularly useful to check that you configured your embedded-RP correctly, or to see what embedded-RPs the router has learned.

  43. Inspecting router state • For most PIM debugging, inspecting the multicast routing state (MRIB) is essential show multicast route group <group> show multicast usage detail show multicast statistics show ipv6 mroute show ipv6 mroute active show ipv6 mroute count • We can also check state for specific group or source and group show ipv6 mroute <group-address> [<source address>] show ipv6 mroute <group-address> [<source address>] count • In IOS, there is also a similar command for looking at the forwarding state (MFIB), that takes similar arguments show ipv6 mfib

  44. RPF • As you know, RPF is essential for multicast • When things go wrong, it is usually due to incorrect routing and failed or wrong RPF • Hence verifying what the RPF interface and neighbor is for an RP address or source address is, is very useful for debugging • Below we see an example showing what the RPF is for an address, and what route was used to determine it cisco> show ipv6 rpf 2001:630::dead:beef RPF information for 2001:630::DEAD:BEEF RPF interface: POS2/0 RPF neighbor: FE80::2B0:C2FF:FE83:80 RPF route/mask: 2001:630::/32 RPF type: MBGP RPF recursion count: 1 Metric preference: 10 Metric: 10 juniper> show multicast rpf 2001:468:901::1 Multicast RPF table: inet6.2 , 75 entries 2001:468:900::/40 Protocol: BGP Interface: ge-2/0/0.0 Neighbor: 2001:468:ff:1549::2

  45. Site router configuration • In general no configuration apart from RP-set is needed • You may want to have a static RP for site scope • Some applications make use of FF05::/16 • E.g. the IANA assigned group FF05::1:3 for all the site’s DHCPv6 servers • Recommend configuring a loopback interface with an address that can be moved around, and static config on all site routers • Might use BSR for this • You may want to use embedded-RP • Only need to configure on the RP itself • On e.g. Juniper, embedded-RP must be enabled on each router • Recommend one for global scope if you will create ASM multicast sessions that should be received externally • Might also use with internal scopes • Edge routers need to use MLDv2 for SSM, normally default

  46. ssmping • A tool for testing multicast connectivity • Behavior is a bit like normal ping • A server must run ssmpingd • A client can ping a server by sending unicast ssmping query • Server replies with both unicast and multicast ssmping replies • In this way a client can check that it receives SSM from the server • And also parameters like delay, number of router hops etc. • Note that there is also a similar tool called asmping for checking ASM connectivity • See http://www.venaas.no/multicast/ssmping/

  47. How ssmping works Client Server User runs ssmping <S> Client joins S,G Clients sends unicast to S t t Server receives unicast ssmping query Responds with ssmping unicast reply and multicast reply to G Client receives replies and prints RTT and hops from server Client sends a new query every second

  48. Example IPv4 ssmping output (v6 supported) -bash-3.00$ ssmping -c 5 -4 ssmping.uninett.no ssmping joined (S,G) = (158.38.62.21,232.43.211.234) pinging S from 129.241.210.1 unicast from 158.38.62.21, seq=0 dist=15 time=72.874 ms unicast from 158.38.62.21, seq=1 dist=15 time=72.663 ms multicast from 158.38.62.21, seq=1 dist=9 time=76.502 ms unicast from 158.38.62.21, seq=2 dist=15 time=72.056 ms multicast from 158.38.62.21, seq=2 dist=9 time=73.556 ms unicast from 158.38.62.21, seq=3 dist=15 time=72.232 ms multicast from 158.38.62.21, seq=3 dist=9 time=73.579 ms unicast from 158.38.62.21, seq=4 dist=15 time=72.513 ms multicast from 158.38.62.21, seq=4 dist=9 time=73.256 ms --- 158.38.62.21 ssmping statistics --- 5 packets transmitted, time 5004 ms unicast: 5 packets received, 0% packet loss rtt min/avg/max/std-dev = 72.056/72.467/72.874/0.415 ms multicast: 4 packets received, 20% packet loss 0% loss since first multicast packet received (after 1077 ms) rtt min/avg/max/std-dev = 73.256/74.223/76.502/1.335 ms -bash-3.00$

  49. What does the ssmping output tell us? • 15 unicast hops from source, only 9 multicast, so tunneling likely • Multicast RTTs are larger and varies more • Difference in unicast and multicast RTT shows one way difference for unicast and multicast replies, since they are replies to the same request packet • Multicast tree not ready for first multicast reply, ok for 2nd after 1077ms • No unicast loss, no multicast loss after tree established

  50. Lab 2Intradomain MulticastTime: Approx. 1 hour

More Related