1 / 10

Design of a Diversified Router: Monitoring

Explore the design of a diversified router monitoring system for compelling demonstrations, easier debugging, and efficient data retrieval. Define the entities to monitor, their statistics, and how to access and maintain them for optimal network performance.

youngwalker
Download Presentation

Design of a Diversified Router: Monitoring

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. Design of aDiversified Router:Monitoring John DeHartjdd@arl.wustl.edu http://www.arl.wustl.edu/arl

  2. Revision History • 5/22/06 (JDD): • Created • 5/25/06 (JDD): • Updated LC physical interface counters • Updated LC Substrate and metalink counters.

  3. Monitoring • Being able to monitor counters, queue lengths, etc on our running systems is an important part of what we do. • This allows us to do • compelling demonstrations • Easier debugging • Etc. • We need to define: • What counters and other values we want to maintain • Where to maintain them • How to retrieve them.

  4. System View Substrate Router MLI-11_1 MLI-31_1 SL-11 SL-31 MLI-11_2 MLI-31_2 MLI-12_1 MLI-32_1 SL-12 SL-32 MLI-12_2 MLI-32_2 MI-2 MI-3 SL-12 SL-33 MI-1 MI-4 Physical Interface 1 Physical Interface 3 MR-1 SL-21 SL-41 MI-2 MI-3 MI-1 MI-4 SL-22 SL-42 MR-2 SL-23 SL-43 NP Blade LC-1 LC-2 Physical Interface 2 Physical Interface 4

  5. Monitoring • Entities/statistics we might want to monitor: • LC: • Users (Meta Net Developers/Providers): • Meta Links • # receive pkts/bytes • # transmit pkts/bytes • # Ingress drop pkts: queue overflow • # Egress drop pkts: queue overflow • Ingress queue length • Egress queue length • Us (Substrate network providers): • Physical Links: • These are available via RTM counters • # receive pkts/bytes • # transmit pkts/bytes • Substrate Links: • Some per metalink counters and the rest get aggregated into a common per substrate link counter. There is no total counter per substrate link. • # receive pkts/bytes • # transmit pkts/bytes • Total # counter touches per packet: 2 pkt cnts, 2 byte cnts, 2 queue lengths • 6 atomic increment SRAM operations per packet. • Do atomic operations take more SRAM cycles? • Worst case pkt rate: 16.45 Mpkts/s  98.7 M SRAM ops/sec • Perhaps we make the Physical and Substrate Link debug only.

  6. Monitoring • NP Blade: • Meta Interfaces • # receive pkts/bytes • # transmit pkts/bytes • # drop pkts: queue overflow • Queue length (1 on enqueue, 1 on dequeue) • Meta Routers • # drop pkts: header check error • Per filter/route hits (limited number supported) pkts/bytes • # mem touches per packet: 3 pkt cnts, 3 byte cnts, 2 queue length • 8 atomic increment SRAM operations per packet. • Worst case pkt rate: 8.225 Mpkts/s  65.8 M SRAM ops/sec

  7. Extra • The next set of slides are for templates or extra information if needed

  8. Text Slide Template

  9. Image Slide Template

  10. OLD • The rest of these are old slides that should be deleted at some point.

More Related