html5-img
1 / 30

Implementing Advanced Services Today – Routing & Multicast

Implementing Advanced Services Today – Routing & Multicast. ken lindahl Chair, Internet2 Routing Working Group lindahl@ack.berkeley.edu Campus Focused Workshop on Advanced Networking San Diego, CA 4 December 2000. Routing. Routing Working Group. Chair: ken lindahl, UC Berkeley

talib
Download Presentation

Implementing Advanced Services Today – Routing & Multicast

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. Implementing Advanced Services Today– Routing & Multicast ken lindahl Chair, Internet2 Routing Working Group lindahl@ack.berkeley.edu Campus Focused Workshop on Advanced Networking San Diego, CA 4 December 2000

  2. Routing Campus Focused Workshop on Advanced Networking

  3. Routing Working Group • Chair: ken lindahl, UC Berkeley • current topics: • Explicit Routing • Internet2 Routing Registry (I2db) • Internet2/Commodity Internet Routing Asymmetry • http://www.internet2.edu/routing/ Campus Focused Workshop on Advanced Networking

  4. Internet2 / Commodity Internet Routing Asymmetry • traffic between two Internet2 sites uses Abilene in one direction and commodity Internet in the other. • reduced performance: lower bandwidth, greater latency, greater jitter, higher packet loss • reported by Hank Nussbacher at Spring 2000 Members Meeting • http://www.internet-2.org.il/i2-asymmetry/ • very pronounced cases can be seen in the Abilene Connector mrtg graphs (Joe St Sauver) • http://monon.uits.iupui.edu/abilene/ Campus Focused Workshop on Advanced Networking

  5. Asymmetry example #1Abilene Connector mrtg graphs • e.g. Georgetown (NYCM Connector) 11/30/2000 in/ max in (to Abilene) out /max out(from Abilene) http://monon.uits.iupui.edu/abilene/nycm/georgetown-bits.html Campus Focused Workshop on Advanced Networking

  6. Asymmetry example #2Abilene Connector mrtg graphs • e.g. Cornell (NYCM Connector) 11/30/2000 in/ max in (to Abilene) out /max out(from Abilene) http://monon.uits.iupui.edu/abilene/nycm/cornell-bits.html Campus Focused Workshop on Advanced Networking

  7. Abilene Connector mrtg graphsLimitations • Abilene Connector mrtg graphs won’t show asymmetry in many cases, e.g.: • campus connects to a gigaPoP • Abilene graphs will show aggregated statistics for all campuses connected to the gigaPoP, tending to hide asymmetry for a single campus. • gigaPoP and campus graphs might reveal asymmetry. • but, some gigaPoPs offer “shared” ISP; campuses may have a single link to gigaPoP for both Internet2 and commodity traffic. • campus mrtg graphs won’t reveal asymmetry in this case. Campus Focused Workshop on Advanced Networking

  8. Abilene Connector mrtg graphsLimitations • Abilene Connector mrtg graphs won’t show asymmetry in many cases, e.g.: • parts of the campus network are routed asymmetrically • incorrect BGP configuration prevents some campus prefixes from being announced • some campus subnets don’t reach Internet2 connection; instead, follow campus default to commodity Internet. Campus Focused Workshop on Advanced Networking

  9. source: The Asymmetry of Internet2, Hank Nussbacher, March 2000, http://www.internet-2.org.il/i2-asymmetry/ Asymmetry example #3Asymmetry of Internet-2, slide 17 Campus Focused Workshop on Advanced Networking

  10. source: The Asymmetry of Internet2, Hank Nussbacher, March 2000, http://www.internet-2.org.il/i2-asymmetry/ Asymmetry example #4Asymmetry of Internet-2, slide 18 • slide 18 from Hank’s talk Campus Focused Workshop on Advanced Networking

  11. source: The Asymmetry of Internet2, Hank Nussbacher, March 2000, http://www.internet-2.org.il/i2-asymmetry/ Asymmetry example #5Asymmetry of Internet-2, slide 20 Campus Focused Workshop on Advanced Networking

  12. Routing Asymmetry • estimated 30% of Internet2 exhibits this sort of asymmetry • The Asymmetry of Internet-2, Hank Nussbacher, March 2000 • in some cases, campuses are aware of the issue; need to upgrade network equipment to fix. Campus Focused Workshop on Advanced Networking

  13. source: The Asymmetry of Internet2, Hank Nussbacher, March 2000, http://www.internet-2.org.il/i2-asymmetry/ Detecting Asymmetry Detecting AsymmetryNussbacher’s Looking Glass test Campus Focused Workshop on Advanced Networking

  14. Detecting Asymmetry • campus Surveyor or NLANR AMP might be able to detect asymmetry http://www.advanced.org/surveyor/ http://amp.nlanr.net/ • typically located near the campus Internet2 link, so might not detect asymmetries affecting interior subnets. • traceroute to Internet2 sites from interior subnets • will reveal instances where outbound data is via the commodity Internet. • time-intensive. • not available to network engineers at other sites. Campus Focused Workshop on Advanced Networking

  15. Detecting Asymmetry • Abilene Core Node Router Proxy can be used to check campus BGP announcements • doesn’t really show that data will be delivered correctly • … but if the BGP announcements are incorrect, packets are unlikely to take the desired path. • Summary: several incomplete and/or inadequate tools exist. Routing WG will investigate this issue and try to find a solution. • participants will be welcomed! to join, see http://www.internet2.edu/routing/ Campus Focused Workshop on Advanced Networking

  16. Interior routing • what’s to say? • encourage use of link-state IGP, e.g. OSPF, EIGRP (cisco proprietary). • generally, not necessary to redistribute external routes into IGP; instead use default to deliver packets to border router, let BGP do the work from there. • most importantly, make sure the packets are following intended paths. Campus Focused Workshop on Advanced Networking

  17. port duplex mis-matches • not routing, per se… • some think this is the most commonly seen performance killer in the Internet today. • often is the result of autonegotiation failure between connected devices. • YMMV, consider disabling autonegotiation; rely on manually configured speed and duplex... • … especially on switch-to-switch and switch-to-router links (how often do these change speed or duplex?) Campus Focused Workshop on Advanced Networking

  18. Multicast Campus Focused Workshop on Advanced Networking

  19. Multicast Working Group • Chair: Kevin Almeroth, UC Santa Barbara • currently focused on encouraging campus deployment of IP multicast • http://www.internet2.edu/multicast/ disclaimer: content of this presentation should be blamed on ken, not Kevin. Campus Focused Workshop on Advanced Networking

  20. Internet2 Multicast Architecture • PIM Sparse-Mode • avoids periodic flooding of all multicast groups; important for high-bandwidth Internet2 multicast applications. • MBGP on border routers • allows non-congruent unicast and multicast topologies; important when a site does not use it’s ISP for multicast. • MSDP between neighboring ASs • communicate Sender Active information to RPs in all external PIM domains. • for details, see NCNE Multicast page; • http://www.ncne.org/faq/multicast.html Campus Focused Workshop on Advanced Networking

  21. PIM issues • version: should be PIMv2 • vendor interoperability (e.g. Nortel: PIMv2 SM only) • cisco: requires IOS 12.0 or later • auto-RP vs. BootStrap Router (BSR) • auto-RP is cisco-proprietary; supports cisco’s v1/v2 interoperability mode; requires Sparse-Dense-Mode (interior interfaces only); works with administratively scoped zones • BSR is part of PIMv2 spec, supports vendor interoperability; may not work with administratively scoped zones (still true?) Campus Focused Workshop on Advanced Networking

  22. Monitoring Multicast • NLANR Beacon • loss • one-waydelay • jitter • out-of-orderarrivals • duplication Campus Focused Workshop on Advanced Networking

  23. Monitoring Multicast • NLANR Beacon • documentation and source (java), available at http://dast.nlanr.net/Projects/Beacon/ • Abilene Beacon page • http//palpatine.ucs.indiana.edu:9999/ • only two sites currently; not ready for prime-time? • suggestion: deploy Beacons around campus to monitor campus multicast; also one at/near border to peer with GigaPoP and other campuses. Campus Focused Workshop on Advanced Networking

  24. Monitoring Multicast • Abilene multicast tools • Multicast Route Viewer, MSDP logger, SDR Monitorhttp://www.abilene.iu.edu/index.cgi?page=multicast • SDR Monitor at UCSB • http://steamboat.cs.ucsb.edu/sdr-monitor/ • shows whether SDR announcements from your campus are getting out • also, gives an idea of what SDR announcements your campus should be able see • list of multicast monitoring and debugging tools http://www.ncne.nlanr.net/faq/mcast_eng_faq.html#42 Campus Focused Workshop on Advanced Networking

  25. Multicast bandwidth control usingrate-limiting • cisco routers support configurable rate-limits on interfacesip multicast rate-limit out 4000 ip multicast rate-limit in 4000 • limits total {in,out}bound multicast to 4Mbps • when configured limit is exceeded, multicast packets are dropped indiscriminately • some multicast is pretty important and should not be dropped: OSPF, PIM messages, NTP • can use access-lists to exempt well-known groups from rate-limiting Campus Focused Workshop on Advanced Networking

  26. Multicast bandwidth control using administratively scoped zones • parts of the campus network that are not able to handle high-bandwidth multicast (e.g. >10Mbps) need protection • if the sender is on your campus and you can influence the group address that is used, administratively scoped multicast boundaries can keep users in bandwidth-challenged parts of the network from joining high-bandwidth sessions. • but you probably can’t control sessions that originate from outside your campus. • configuration can be complicated, involving multiple RPs and multiple RP mapping agents, each carefully scoped. • c.f. Developing IP Multicast Networks, Beau Williamson, Cisco Press Campus Focused Workshop on Advanced Networking

  27. Constraining multicast flooding –IGMP Snooping vs CGMP • IGMP Snooping • switch inspects IGMP membership reports from hosts to determine which ports a group should be forwarded out • can be CPU intensive (switch must inspect all multicast packets). • implementations appear to differ among vendors. • CGMP • switch forwards IGMP membership reports to router; router uses CGMP to tell the switch which ports a group should be forwarded out • moves CPU load to the router (minimal) • cisco proprietary Campus Focused Workshop on Advanced Networking

  28. Constraining multicast flooding –IGMP Snooping vs CGMP • use one or the other on switched LANs that have connected hosts • Issue: leave latency • IGMPv1 hosts do not send IGMP Leave Group messages, so forwarding state on switch must time out. (Affects both IGMP snooping and CGMP). • Issue: does not work on router ports • routers don’t send host membership reports, so neither IGMP snooping nor CGMP works on router ports. Don’t use either on a backbone switch with only routers attached. Campus Focused Workshop on Advanced Networking

  29. the next thing: SSM • Source-Specific Multicast • addresses scalability issue of earlier forms of multicast • receivers specify desired source when joining group • source and group information learned via non-multicast means (e.g. web page) • requires IGMPv3 for (S,G) joins • some host implementations are available • requires support in last-hop router (cisco EFT images now, supported releases soon) • cisco offers 2 interim workarounds: IGMPv3lite and URD (URL Rendezvous Directory) Campus Focused Workshop on Advanced Networking

  30. the next thing: SSM • cisco informationhttp://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/dtssm.htm • U of Oregon SSM trialhttp://videolab.uoregon.edu/projects.html • IETF WGhttp://www.ietf.org/html.charters/ssm-charter.html Campus Focused Workshop on Advanced Networking

More Related