1 / 26

OS7000 Network Design and Configuration Guide

OS7000 Network Design and Configuration Guide. February 20, 2003. Version 4.0 Posted on the Intranet Website. From the IND home page: (aww.ind.alcatel.com) Select NIBU marketing Scroll down to sales and SE tools Click on “SE Corner” And “Voila!” The direct link is:

filia
Download Presentation

OS7000 Network Design and Configuration Guide

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. OS7000 Network Design and Configuration Guide February 20, 2003

  2. Version 4.0 Posted on the Intranet Website • From the IND home page: (aww.ind.alcatel.com) • Select NIBU marketing • Scroll down to sales and SE tools • Click on “SE Corner” • And “Voila!” • The direct link is: http://aww.ind.alcatel.com/nibu/se_corner.cfm • Versions 3.0 and 2.0 are also there for comparison

  3. What is This Document? • Reference document • Table of contents and reference links “hot” hyperlinks • Not designed to replace the user manual • Does not replace the release notes • Explains the current status of each feature • Limitations explained • Some detailed background • Workarounds presented when possible • Sample configurations • Table of contents has hot links to sub-chapters • Not intended to be read cover to cover • (Unless you need a solution for insomnia)

  4. What Does it Include? • Network design theory • Physical audit (Power, AC, cable types, traffic distribution) • Protocols (IP Addressing, VLAN architecture, AVLANs) • Capacity planning (Bandwidth requirements, future growth) • Management requirements (Logical & physical, secure access) • Security and Policies (Source control, physical and logical access) • Application prioritization (QoS) • Optimal network designs • Hierarchal (Edge, distribution, core) • Redundancy Methods (Link Agg., STP, RIP, OSPF, SLB) • Broadcast considerations • Scalability & Security

  5. Features Covered • Redundancy / high availability • CMM Redundancy • Virtual Router Redundancy Protocol (VRRP) • Server Load Balancing (SLB) • 802.3ad Dynamic Link Aggregation (LACP) • OmniChannel • Switching / Layer 2 • Multicast Switching • 802.1w Rapid Reconfiguration Protocol • 802.1D Spanning Tree Protocol (STP) • 802.1Q • Group Mobility

  6. Features Covered • Routing / Layer 3 • Open Shortest Path First (OSPF) • Routing Information Protocol (RIP) • Border Gateway Protocol (BGP) • Distance Vector Multicast Routing Protocol (DVMRP) • Protocol Independent Multicast Sparse Mode (PIM-SM) • UDP Relay • QoS (Quality of Service) • QoS Generalities • Differentiated Services Code Point (DSCP) • Type of Service (ToS) • 802.1p

  7. Features Covered • Security • Authenticated VLANS • Access Control Lists (ACLs) • Network Address Translation (NAT) • OS6600 specific functionality • Introduction • IP Switching • IP Telephony Primer • Bandwidth requirements for various codecs • Voice quality (delay, jitter, throughput, packet loss) • VoIP audit • QoS: What type and where • Deploying VoIP in a converged network

  8. Features Covered • System limitations • OS6600 • Stacking limited to 4 in first release • Group mobility: One VLAN per protocol per port • Link aggregation limited to one ASIC • Multicast routing, port mirroring • L3/L4 Classification requires IP Switching • System limitations • OS7000 • Link Aggregation • Port Mirroring • IP Multicast Routing • BGP Scalability

  9. Link Aggregation Issue • Broadcast traffic is forwarded in software • In some configurations the following can happen: • Broadcast traffic can be looped back and duplicated • Unwanted MAC address movement • Software fix for problem in 5.1.3. R01 • Release date first week in January • Retrofit into 5.1.1 R03 due out end of January • Ultimate fix is Coronado II • Current availability date is Q2 2003

  10. Network Mac2 PortA Switch ‘F’ Switch ‘S’ LnkAgg Mac3 Mac1 PortB How Does it Happen? • Packet sent from Mac 2 to Mac 1 • Mac 1 is unknown in switch “S” • Flooded to switch “F” over the aggregate • Switch “F” has previously learned Mac 1 on the aggregate

  11. How Does it Happen? Network • Load sharing algorithm can choose port A or B • If egress port == ingress port, Coronado drops the packet • If not, packet arrives in switch “S” and is a duplicate • Switch “S” now learns Mac 2 as source Mac on aggregate Mac2 PortA Switch ‘F’ Switch ‘S’ LnkAgg Mac3 Mac1 PortB

  12. Software Workaround • What was done in software? • Change made for Gigabit NIs only (10/100 still has problem) • Source learning was modified to detect when: • A Mac DA has a source port that is the same as the aggregate • In this case the destination queue ID is set to the drop queue. • Prevents frame duplication and unwanted Mac movement • Modifications are straightforward and hardware handles issue • No effect on the rest of the source learning logic • No configuration required - change is unconditional • All ports on the Coronado are part of the SAME aggregate • Any packet from a basic port to the aggregate will be dropped • QoS Rules for these Mac addresses cannot be used • The rules might modify the queue ID (not the drop queue)

  13. Configuration Work-Around • The problem described only occurs on bridged links • Configure the links as routed connections (separate subnets) • Must use command: “qos classifyl3 bridged enable” • Routed connections use MAC addresses of routers • Since MAC addresses are the same on both ends • Load sharing is not effective • Command causes load sharing to use IP instead of MAC addr. • Problem solved! • Other ports of Coronado not forced to be part of aggregate

  14. Port Mirroring • Coronado hardware can’t port mirror at wire speed • Egress wire speed, ingress software • Software modification: one port at a time to be monitored • Could handle two, but limited to one by configuration • Less than wire speed performance • Cumbersome to use • Problem corrected by Coronado II • Current schedule is Q2 2003 • With fix, four ports can be monitored at wire speed • Mixed configurations with Coronado I and Coronado II limited

  15. IP Multicast Routing - (Chapter 7.4 in Document) • Layer 2 traffic is ALWAYS sent at wire speed • Some routed multicast traffic sent via software • Performance: 32,000 - 37,000 packets per second • Conditions that require hardware routing to be turned off • Presence of 802.1Q trunks where traffic is routed • Fragmentation between ports with different MTU sizes • UDP packets with non-standard size headers (>20 bytes) • PIM encapsulated packets • Packets requiring translation (SNAP to Ethernet II) • Unicast tunnels transporting multicast traffic • IP multicast hardware-routing • IP multicast no hardware-routing

  16. IP Multicast Routing - (Chapter 7.4 in Document) • Software changes in AoS 5.1.3 R01 • Automatic detection of 802.1Q trunks • No longer necessary to turn off hardware routing manually • Other non-tagged connections remain wire speed • Unicast tunnels and PIM packets also detected automatically • Must turn off hardware routing for remaining conditions: • Fragmentation between ports with different MTU sizes • UDP packets with non-standard size headers (>20 bytes) • Packets requiring translation (SNAP to Ethernet II) • Other Fixes for multicast issues found a the TIC • Duplicate multicast streams routed by DVMRP routers • DVMRP not creating forwarding entries when metric modified

  17. 802.1Q Workaround - Add a Non-Tagged Trunk Disable MC routing on VLANs 1-4. Enable on VLAN 5. Traffic routed at wire speed! Video Server VLAN 7 Video Server Untagged Trunk (VLAN 5) VLAN 6 Main Switch MC Switching (No Routing) 1 2 End Users 3 4 802.1Q Tagged Trunk

  18. 802.1Q Workaround - One-Armed Router One-Armed Video Server MC Router VLAN 1 VLAN 1 2 3 Untagged Links Provides Wire Speed Multicast Routing 4 Main Switch MC Switching (No Routing) 1 2 End Users 3 4 802.1Q Tagged Trunk

  19. 802.1Q Workaround - Multiple Video Servers Video Server Video Server VLAN 1 VLAN 2 Video Server Layer 2 traffic is switched at wire speed! VLAN 3 Main Switch Video Server MC Switching VLAN 4 (No Routing) 1 2 3 End Users 4 802.1Q Tagged Trunk

  20. Multicast on OS6600 • Currently multicast routing not supported on OS6600 • Hardware limitations of Intel IXE2424 • When scr/dest flow is learned, additional flows don’t go to software • DVMRP can’t function correctly because it can’t prune • Engineering decided a partial DVMRP to be unwise • It is possible to deploy multicast with some restrictions: • Only one active interface at a time (configure precedence) with routers that could be looped • Router will dynamically select interface to provide redundancy • Cascaded leaf routers are OK

  21. Multicast on OS6600: An Example Switch2 Switch 1 VLAN 2 Video Server OS7000 DVMRP OS7000 DVMRP Configure VLAN 3 as preferred link (closer to video source) VLAN 3 VLAN 1 OS6600 DVMRP End Users End Users End Users OS6600 DVMRP End Users

  22. Multicast on OS6600: Why is this Important? • Without L3 multicast support, OS6600 needs to Q-tag to core • OS7000 routing is not wire speed on Q-tagged trunks • Once you tag to the core, why unicast route on the edge? • The OS6600 slowly becomes an L2 switch • It erodes the “advanced switch” story • Limitations are not unreasonable • If you need full DVMRP, use OS7000 • If the OS6600 did everything the OS7000 does, we wouldn’t sell OS7000! • Leverage OS6600 wire-speed delivery over Q-tagged trunks • Cascade 6124/6148 off of OS6600

  23. Patent Pending Method for MC Traffic Over Q Trunks • Utah team defined MC optimization method for Q trunks • Send one copy on one VLAN, duplication done downstream • Q-tag Multicast Optimization for Proactive Switching (QMOPS) • (That’s a joke! There is no formal name) • Only one “join” message sent upstream • Subsequent join requests managed by downstream switch • All packet duplication done in downstream switch • Traffic is not copied on Q trunks from OS7000 • Present to customers as optimization • Bandwidth is conserved: one packet across trunk, not multiple • Requested option to specify “primary” VLAN

  24. MC Traffic Optimization Over Q Tagged Trunks Video Server Video Server VLAN 1 VLAN 5 VLAN 1 MC Client VLAN 3 Main Switch MC Client MC Routing 1 2 VLAN 4 3 IPMS Only MC Client End Users 4 (No Router) 802.1Q Tagged Trunk

  25. IP Multicast Routing Information Resources • Chapter 7.4 in the document • Routing solutions Web page has great stuff! • FAQ pages, support info, white papers, presentations • IND home page > routing solutions (under Product information) • Web Address: http://aww.ind.alcatel.com/products/routing.cfm • Jeff Thomas is happy to answer any other questions • His e-mail address is: jeff.thomas@ind.alcatel.com

  26. That’s All Folks!!!!!!!!!!!!!!!!!!!!! • For those of you asleep at the Beginning: • From the IND Home Page: (aww.ind.alcatel.com) • Select NIBU marketing • Scroll down to sales and SE tools • Click on “SE Corner” • And “Voila!” • The Direct link is: http://aww.ind.alcatel.com/nibu/se_corner.cfm • Versions 3.0 and 2.0 are there for comparison • Questions Welcome!

More Related