1 / 28

Testbed

Testbed. Why a testbed?. Verify if the OS upgrade impacts the functionality/services. Compatibility between different router vendors. Test of new services and features. Testbed. The testbed will be available for the NRENs

atira
Download Presentation

Testbed

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. Testbed

  2. Why a testbed? • Verify if the OS upgrade impacts the functionality/services. • Compatibility between different router vendors. • Test of new services and features.

  3. Testbed • The testbed will be available for the NRENs • Testbed consists of several Cisco and Juniper routers distributed on GÉANT. • three M-20s, two 7000s and one GSR • interconnection between test routers via the MPLS/CCC functionality (carrying L2 frames across GÉANT).

  4. Testbed • the tests routers are connected to the GÉANT routers via STM-1. • Additional equipment: • Linux based PCs • Traffic generators (SmartBits) • Ideally, should have a routes generator. • Comments?

  5. Testbed example

  6. DSCP transparency

  7. DSCP transparency • Currently, any BE packet retag with DSCP 0 • IETF states that the domains should be DSCP transparents • prevents two end-users use a specific DSCP value to differentiate their packets • Avoid remarking the packets which are not using a “GÉANT service tag”

  8. Marking on Juniper M-series • Marking only on an output-queue • Four output-queues per port (in general) • For each output-queue, two loss-priorities (doesn’t mean they are defined or different ) • For one pair <output-queue, loss-priority>, one tagging value is applied to all the packets in this output-queue and with this loss-priority (or no re-tagging)

  9. How to do it? • Current queue utilisation • Remove the rewrite-rule for <Q0, low loss-priority>

  10. How to do it? • Easy => no: • the marking to BE on GÉANT is used to change the unauthorised Premium IP and DWS to BE. • need to find an unused <queue, loss-priority> for remarking the packets. Unused queue: • <queue2, loss-priority high> • <Premium queue, high> (not good bcs of Premium protection) • <queue3, high> (difficult to move network control traffic - internal to JUNOS)

  11. Solution

  12. Implications • Once LBE service deployed (queue 2) • the unauthorised Premium IP and DWS will be receive the same treatment as LBE on the first GÉANT router • then, on the next routers, they will be treated as BE • > to be kept in mind • Acceptable solution? • if congestion, dangerous of Premium if bad configuration • ECN bits kept unchanged.

  13. Less than Best Effort test results

  14. Less than Best Effort - definition • Traffic class able to use the un-utilise by other higher traffic classes bandwidth in the network. • if competition for resources, LBE packets are discarded before any other. • Equivalent to the Internet2 scavenger service. • Use the DSCP 001000 (decimal 8) - same as Internet2.

  15. LBE • In case of congestion, no guaranty • high packet loss • no bandwidth guaranty • Service oriented for • huge data transfer volume • traffic without time constraints • What the hell would you use this service for???

  16. LBE utilisation example • FTP mirroring • GRID data transfer • experimental data transfer • network backup

  17. Implementation • A small percentage of capacity is allocated to this service (0% or 1%)

  18. LBE Test on GÉANT • August 2002 in collaboration with the DataGrid project. • Congestion of two STM-16 interfaces with LBE traffic • fr1.fr interface to es1.es and • es1.es interface to it1.it • Congestion created with two SmartBits SMB-600 from Spirent (STM-16 interfaces).

  19. LBE Test on GÉANT • Test done with three classes of services: Premium, BE and LBE. • One way delay, jitter, throughput, packet losses.

  20. Test topology STM-16

  21. Test - next steps • End-to-end LBE tests • FTP mirroring tests between • Uninet and • the University of Southampton

  22. Delays - load variation • Delays are pretty stable for BE and LBE for load between 5 and 45% of an STM-16.

  23. Delay - congestion • Increase of the LBE delay 1.5ms (1500us). • Slight increase of BE delay when congestion - 400us

  24. Packet loss • No BE packet was lost at any time during the tests (SMB or drop on the routers). • BE load up to 60% of STM-16 load (int cong) • LBE losses increase with the load.

  25. Throughput • The Premium IP, BE throughput are preserved. • As long as their capacity is not higher than the interface capacity.

  26. Re-ordering • The smaller the packets constituting the flow, the higher the re-ordering . • The higher the load in a class, the higher the re-ordering. • Re-ordering higher in case of congestion.

  27. Conclusions • Large amount of LBE traffic don’t have any impact on the BE and the Premium IP. • No packet losses • one-way delay increase almost negligible • IPDV not particularly affected • LBE delay increase of 1ms, packet losses

  28. Useful tool • Feature of the NANOG traceroute to discover the DSCP changes along the path.

More Related