1 / 25

The Open Network Lab

The Open Network Lab. Ken Wong, Jonathan Turner, et. al. Applied Research Laboratory Computer Science and Engineering Department http://www.arl.wustl.edu/~kenw kenw@arl.wustl.edu http://www.onl.wustl.edu (ONL) National Science Foundation ANI-023826. The Open Network Laboratory (ONL).

kellii
Download Presentation

The Open Network Lab

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. The Open Network Lab Ken Wong, Jonathan Turner, et. al.Applied Research LaboratoryComputer Science and Engineering Departmenthttp://www.arl.wustl.edu/~kenw kenw@arl.wustl.edu http://www.onl.wustl.edu (ONL) National Science Foundation ANI-023826

  2. The Open Network Laboratory (ONL) • Provide hands-on experience with real network • Makes education more concrete, provides reinforcement • Supports experiment/observation approach • Labs can lead to insights and greater understanding through experimentation and real-time observations • Student can change configuration settings and observe effect on network traffic • Extensive monitoring facility supports direct observations • Easy-to-use Remote Laboratory Interface • Provide access to advanced router features • Gbps links, filters, packet scheduling • Program insertion along packet data path • Open laboratory facility • Remote access, unsupervised learning possible • Integrated course material (coming soon)

  3. People Who Make it Happen Charlie WisemanWeb site, OpsDist. Sched. Ken WongAdmin, Web site, Dist. Sched. Jyoti ParwatikarRLI, Software development Stephen LevinePlugins, Apps. John DehartFPX hardwareSystem integration Fred KuhnsSPC softwareFPX hardware

  4. 3 GigabitEthernetSwitch 16 2 3 3 2 GigE GigE 2 NetworkConfigurationSwitch GigE GigE 3 2 4 ONL Lab Overview • Gigabit routers • easily configured thru Remote Lab Interface • embedded processors for adding new features • PCs serve as hosts • half on shared subnets • Net configuration switch • link routers in virtual topologies • traffic generation • Tools for configuration and collecting results • monitoring traffic • data capture and playback • Open source • all hw & sw sources on web

  5. Internet usr CP CP CP CP 16 2 2 2 3 2 3 3 3 GE GE GE GE 2,3 2,3 2,3 2,3 0 0 0 0 1 1 1 1 NSP4 NSP1 NSP3 NSP2 Testbed Organization SSH tunnel YOU netBSD serversfor plugin prep onl server Remote Lab Interface (RLI) control network 4-7 4-7 4-7 4-7 experiment network configurationswitch

  6. PP SPC ATMSwitchCore pluginenv. SPC FPX CP PP FPX externallinks . . . . . . . . . . . . to/fromlinks to/fromswitch core Lookup PP Gigabit Router Architecture Fast Path • Scalable architecture built around ATM switch core. • core provides 2 Gb/s bandwidth per port (2x speedup) • Port processors (PP) implement packet processing • Field Programmable Port Extender (FPX) implements routine packet processing • Smart Port Card (SPC) hosts programmable extensions • Control Processor (Linux PC) handles configuration • can support routing protocols, OA&M, etc.

  7. After Logging in • Public links • Tutorial • Get account www.onl.wustl.edu or onl.arl.wustl.edu • User links • getting started • status • reservations

  8. Sample ONL Session Bandwidth Usage Network Configuration Routing Table Queue Table Queue Length Filters Packet Drops

  9. Configuring Topology Add hosts and links as needed. Default routing table for all ports Drag icons to improve visual layout Port 0 used for Control Processor. Spin handle rotates ports. Cluster includes router, gigE switch and fixed set of hosts

  10. Configuring Topology (cont.) Darker color means commit done “Commit” to request actual resources n2p3 is name.192.168.2.48 is IP address. Also, has external name and IP address to control network Save config. to a file for use in later session.

  11. Routes, Filters and Rates Set link rate, relative service rates and queue sizes Configure Routes Click on port 6 to access route table (and other stuff). Filters direct pkts to separate queues for service

  12. Monitoring Traffic/Real-Time Displays peak per ping packet select desired monitor variable customized label select which queue select polling rate

  13. sndr2 rcvr1 sndr1 rcvr2 Port 2 Port 3 Port 7 Port 6 Port 1 Port 4 Example (1 NSP, 2 TCP Flows) bottleneck • sndr2 starts 10 sec after sndr1 • Bottleneck • Port 6 egress • 100 Mbps • Routing (2 flows) • Through port 6 • Reserved flow queues • QIDs 300 and 301 • Equal service rates • 32,000 byte queues • Delay plugins (optional) • Delay ACK pkts • Port 2 egress,25 msec • Port 4 egress,50 msec

  14. Traffic Generation Scripts urcvrs-1nsp script Exports control network names to environment Environment variable: Control network name (e.g., onl21) usndrs-1nsp script internal host interface iperf traffic generator

  15. SPC pluginenv. FPX . . . . . . . . . to/fromlinks to/fromswitch core Lookup Adding Features with SPC Plugins SPC uses qid to direct pkt to plugin plugins are kernel modules on egress, pkt mapped to per-flow queue on ingress, pkt mapped to VOQ filter directs pkt to SPC queue

  16. Adding SPC Plugins pre-defined plugins with numerical identifier outgoing link queue 136 =8+128 filter directs pkt to SPC queue 8

  17. Observe Effect of Delay on TCP longer congestion control cycle (50 msec vs 25 msec)

  18. 50 ms delay plugin acting as propagation delay delay increases as queue grows Larger Queues (320,000 Bytes) ping pkts travel along same path as iperf TCP traffic growing queues

  19. Standard Plugins (Growing Number) • qsnap (soon) • Queue length seen by arriving pkts • fpxCtrsAndRegs • Read FPX counters/registers on demand • udpdump (soon) • Send part of pkt to logging daemon • Creates UDP pkt • psyndemo • SYN flood mitigation plugin • Monitors traffic for SYN flood pkts • Installs EM filter in back channel • Sends RESET pkts to Web server • nullPlugin • Just forward pkts • COUNTER • Count and forwards pkts • stats • Count ICMP/TCP/UDP pkts and drop • Uses auxillliary filter • stringSub • Substitute “adieu” for “HELLO” • Recomputes TCP checksum • multicast • Multicast pkts to all ports • Create packet copies • Manipulate shim

  20. Course Usage • Spring 2005 • A few WUSTL graduate students doing graduate networking protocols projects • Fall 2005 • About 35 WUSTL Intro networking students • Basic routing lab exercise near end of semester • About 15 SIUE intro network programming students • Basic routing lab exercise near end of semester • Spring 2006 • About 16 UMass graduate Intro Networking • Basic routing lab and Basic bottleneck lab exercises • About 20 WUSTL graduate Network Protocols • Routing and Bottleneck lab exercise • Planned: Router plugins lab exercise

  21. UMass Survey • Required grad course for non-networking students • Most knew a little about networking but not much • Survey after first lab exercise on basic routing • Good comments (Summarized) (About 16 Students) • Good hands-on learning … can see effect of config on actual traffic • Liked its compactness, the skill it demands and its well organised pattern • Good tutorial pages • Good comments (Instructor: Tilman Wolf) • “Great … can offer lab assignment with very little effort” • Difficulties • Need more routers in the testbed • Making the first SSH tunnel was troublesome for some • Less networking experience  More time on lab

  22. A Successful First Experience • Instructor/Grader tried ONL and worked on some exercises before writing own assignment • Even better to do the assignment to be given out • Wrote clear instructions and assignment • UMass assignment was a cleaned up version of one from the ONL Web site • Supplied caveats (based on instructor’s experience) • Biggest one was ONL reservation times were CST • Fix is to use local time (coming soon) • Limited assignment to 1 NSP • Emphasizes core ideas and limits encountering “gotchas” • Student questions filtered through instructor/graders • Backstop was testbed-ops@onl.arl.wustl.edu • Keeps instructor in tune with students • Helps ONL developers address real problems instead of noise

  23. Current or Near Future Work • Current • Supporting 2 courses • Web tutorial pages • Course material • More examples • Various topics (e.g., Distributed Queueing) • More standard plugins • Experiments with Xen to support multiple TCP stacks • Near Future • Replace APIC interfaces with gigE • Upgrade OSes • Replace electronic patch panel • Firewall

  24. Possible Future Extensions • Improve router functionality. • improved link queueing, dynamic packet discards • include TCP flags in packet filters • sampling filters for netFlow type applications • Different OSes (and therefore TCP stacks) • Hardware plugin modules. • insert hardware processing modules into links • implemented using extra FPX modules • user-specified FPGA bit-files • Hardware support for user-specified link delays • Expand testbed with NP-based routers. • 10 port router implemented with pair of IXP 2850s • enable construction of larger networks • enable users to more easily modify core router functions • queue management, route lookup, packet classification

  25. The End onl.wustl.edu or www.onl.wustl.edu

More Related