case study debugging multicast problems from an applications perspective
Download
Skip this Video
Download Presentation
Case Study: Debugging Multicast Problems from an Applications Perspective

Loading in 2 Seconds...

play fullscreen
1 / 20

Case Study: Debugging Multicast Problems from an Applications Perspective - PowerPoint PPT Presentation


  • 64 Views
  • Uploaded on

Case Study: Debugging Multicast Problems from an Applications Perspective. Steven Senger, Ph.D. Dept. of Computer Science University of Wisconsin - La Crosse. HAVnet Project. Parvati Dev, PI, Stanford SUMMIT National Library of Medicine, NGI & SII programs since 1999.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Case Study: Debugging Multicast Problems from an Applications Perspective' - sahara


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
case study debugging multicast problems from an applications perspective

Case Study: Debugging Multicast Problems from an Applications Perspective

Steven Senger, Ph.D.

Dept. of Computer Science

University of Wisconsin - La Crosse

havnet project
HAVnet Project
  • Parvati Dev, PI, Stanford SUMMIT
  • National Library of Medicine, NGI & SII programs since 1999.
  • Applications of high-performance networks to anatomical and surgical education.
  • http://havnet.stanford.edu
  • http://visu.uwlax.edu
other apps and components
Other Apps and Components
  • Information Channels
    • Multicast based announcement/discovery mechanism.
    • Supports other app requirements such as logging.
  • Access Grid
potholes along the way
Potholes Along the Way
  • Stanford / CENIC
    • Multicast setup delay
  • WiscNet
    • Conflict between sender and receiver
  • Michigan / Merit
    • Multicast setup delay
    • Inbound flow stops after 209 secs
stanford cenic
Stanford / CENIC …
  • Longstanding problem (observed in ‘01).
  • Large delays (~15 min) in multicast setup.
  • Stanford / La Crosse / NLM
    • Significant delays except for La Crosse / NLM
  • Originally thought to be at Stanford Border and RP.
  • 04 hardware/ios upgrades at Stanford.
  • Situation improved.
stanford cenic1
Stanford / CENIC …
  • Only Michigan to Stanford delayed, ~6 mins.
  • Oct 04, Phone calls, Stanford, CENIC, Vendor support, La Crosse. Escalate through 3 layers of vendor support.
  • Test/Debug every couple of weeks through March ‘05.
  • Identified as MSDP propagation delay related to encap/unencap data received by MSDP.
stanford cenic2
Stanford / CENIC
  • Delay occurred at each CENIC router.
  • At some point problem had been internally found and resolved by vendor.
  • Solution: upgrade OS on CENIC routers.
la crosse wiscnet
La Crosse / WiscNet …
  • First observed spring 05 using AccessGrid.
  • La Crosse sender and Stanford receiver OK.
  • Starting a La Crosse receiver breaks the flow.
  • WiscNet identified problem router.
  • Vendor support engaged.
  • Discovered rpd restart sufficient to fix.
  • Reoccurs every 2 months.
la crosse wiscnet1
La Crosse / WiscNet …
  • When failing
    • Upstream interface on router gets set to unreasonable value.
    • Sender continues to send data in encapsulated PIM-register messages.
    • Router never sends register-stop messages.
la crosse wiscnet2
La Crosse / WiscNet
  • Problem has survived router chassis upgrade.
  • No solution as yet.
u michigan merit
U. Michigan / Merit …
  • Discovered after CENIC problem solved.
  • Small delay in setup for Michigan to Stanford.
  • Varies between 0 and 60 sec.
  • Similar behavior for Milwaukee to Stanford.
  • Does not appear to be in CENIC?
u michigan merit1
U. Michigan / Merit …
  • Presence of other receivers seems to change the setup delay.
  • Merit engaged in isolating problem.
  • No solution as yet.
u michigan merit2
U. Michigan / Merit
  • Discovered Jan ‘06 using AccessGrid.
  • Traffic from Stanford to MCBI/Merit starts correctly but stops after 208 seconds.
  • When stopped IPLSng shows as pruned.
  • Merit identified problem with a switch in Chicago not allowing streams to setup correctly.
  • Problem resolved with OS upgrade.
diagnostic help
Diagnostic Help
  • Debugging strategies
  • Tools
  • Monitoring
ad