DOCSLIB.ORG

Catalyst 6500 Update

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Catalyst 6500 Update Catalyst 6500 update Per Jensen [email protected] DRAFT Version © 2010 Cisco Systems, Inc. All rights reserved. Cisco Confidential 1 Agenda • SUP2T + software update • 12.2(33)SXI4 update • 12.2(33)SXJ update DRAFT Version © 2010 Cisco Systems, Inc. All rights reserved. Cisco Confidential The New 2 Terabit Catalyst 6500-E Sup2T and 6513-E 69xx Series 80Gbps 68xx/67xx Service Modules 8p 10G Series 40Gbps WiSM-2 4p 40G/16p 10G 1GbE Fiber: 24p/48p ASM-SM Built-in DFC4 10/100/1000: 48p NAM-3 10GBASE-T: 16p ACE-30 Early Adopter Release: 10G Fiber: 16p Feature Parity with 12.2(33)SXI3 Built-in DFC4 Innovation Cat6500-E Investment Protection ALL E-Series Upgrade Option All 61XX Legacy Service Chassis for 67xx Line Cards POE/ POE+ Modules © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 3 Performance with Network Services 4T VSS (with Quad-Sup VSS*) VSS 4T 40G Ready Next Gen Cat6k/ Tunnels, L3VPNomGRE CORE Sup2T L3SGT For TrustSec Interoperability OTV, Trill Ready Sampled Netflow 4T VSS VSS 4T Integrated NG Svcs (WisM2, ASA, NAM, Next Gen Cat6k/ ACE-30), Multicast HA Sup2T Smart Install Director* OTV, Trill Ready Flexible Netflow, Egress Netflow DISTRIBUTION DISTRIBUTION TrustSec Next Gen EnergyWise Cat4k/ Sup7-E NGPoE (60W) Ready Cat3k/ 3750X Flexible Netflow ACCESS Cat2K/2960S IPv6 First Hop Sec. Secure Robust Simple VDI Ready Resilient Virtualized Video Optimized Turn Key IPv6 © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 4 Wireless Service Adaptive Security M Service Module (ASA- O Module 2 (WiSM 2) B SM) I L • 500 access points, I 1.7x better • 16 Gbps per blade, 3x S T E Y better C • 10 Gbps throughput U • Industry-leading price/ R • Control and data I T plane encryption performance Y • Consistency with entire ASA product family Network Analysis Module 3 (NAM-3) Application Control M A Engine 30 (ACE 30) N N • 10+ Gbps throughput, E A A P T G 10x better • 30,000 SSL transactions P E W E P R O M per second, 2x better L F R E • Advanced hardware I O K C R N filters • Lower TCO - industry’s A M T T A only virtualized application I N • High performance O C packet captures delivery controller N E Designed to Deliver Borderless Services for Next 10 Years DRAFT Version © 2010 Cisco Systems, Inc. All rights reserved. Cisco Confidential © 2011 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 6 Borderless Networks CatalystNew Innovations6500 Family Architecture Delivers the Borderless Experience Borderless End-Point/User Services Mobility Workplace Video Experience AnyConnect Borderless Network Services Borderless Management Infrastructure and Policy Video: Green: Security: Performance Mobility Medianet EnergyWise TrustSec Energywise VSS Quad Multicast IPv6 security Service Phase 1 Sup Uplink Service Architecture Phase 2 TrustSec IPv6 Forwarding Reflection Framework (SAF) DRAFT Version © 2010 Cisco Systems, Inc. All rights reserved. Cisco Confidential 7 Catalyst 6500 12.2(33)SXI4 New Borderless Features Video Green Security Performance Mobility Medianet Policy . Service . EnergyWise . IPv6 HSRP Global . VSS Quad Sup . Industrial Architecture Phase 1 & 2 Address Uplink Forwarding Ethernet DHCP Framework . VSS support for Server Port . Cisco . IPv6 Port Access (SAF) SIP-400 Based Address Orchestrator Control List . Service Allocation . Multicast software (PACL) support Advertisement Service support . Advanced VPLS . IPv6 Policy-Based Framework (SAF) Reflection support for Routing . Fast UDLD SIP-400 . Performance . IPv6 RA-Guard . VPLS MAC Monitoring MIBS Host Mode Address . 10G BASE-T Withdrawal . TrustSec IPv6 16-Port 10 Gigabit SGT Learning Ethernet Copper . New support for from Data-Path Module MPLS Egress . SFP+ LRM optics netflow. LACP Auto . Netflow Data Interleaved Port Export to a Priority collector in a . NAM Visibility into VRF Virtual Machine DRAFT Version © 2010 Cisco Systems, Inc. All rights reserved. Cisco Confidential Networks 8 Catalyst 6500 12.2(33)SXI4 New Borderless Features Video Green Security Performance Mobility Medianet . Service . EnergyWise . IPv6 HSRP Global . VSS Quad Sup . Industrial Architecture Phase 1 & 2 Address Uplink Forwarding Ethernet DHCP Server Port Framework . VSS support for . Cisco . IPv6 Port Access Based Address (SAF) SIP-400 Orchestrator Control List Allocation . Multicast software (PACL) support . Fast UDLD Service support . Advanced VPLS . IPv6 Policy-Based . Performance support for Reflection Routing Monitoring MIBS SIP-400 . IPv6 RA-Guard . 10G BASE-T . VPLS MAC Host Mode 16-Port 10 Gigabit Address . TrustSec IPv6 Ethernet Copper Withdrawal Module SGT Learning . New support for from Data-Path . SFP+ LRM optics MPLS Egress netflow. LACP Auto Interleaved Port . Netflow Data Priority Export to a collector in a VRF DRAFT Version © 2010 Cisco Systems, Inc. All rights reserved. Cisco Confidential 9 Multicast Service Reflection Translate external multicast feeds Conform to internal addressing policy Receive redundant feeds. Financial News Subscriber to Broadcaster Financial News Service MSR translation occurs at the edge of your company DRAFT Version © 2010 Cisco Systems, Inc. All rights reserved. Cisco Confidential 10 Multicast Service Reflection Translates multicast source and destination address in the IPv4 header. 239.1.1.1 239.2.1.1 Multicast Src Solves multicast address overlap Multicast Src Receive multicast streams from External different companies Manage internal multicast groups Hardware support Multicast Src Internal 239.2.1.1 Multicast Receiver Multicast Receiver Supported in 12.2(33)SXI4 DRAFT Version © 2010 Cisco Systems, Inc. All rights reserved. Cisco Confidential 11 Multicast Service Reflection ip multicast-routing ! Src: Dst: Payload interface Loopback0 72.163.225.70 239.2.1.1 description Rendezvous Point for Public Net ip address 2.2.2.2 255.255.255.255 interface Gig2/1 ip pim sparse-mode ! interface gig2/1 description “ip nat inside” not required ip address 10.0.0.1 255.255.255.0 ip pim sparse-mode interface … ! interface gig2/48 description “ip nat outside” not required ip address 20.20.20.1 255.255.255.0 ip pim sparse-mode interface Gig2/48 ! Src: Dst: Payload interface Vif1 72.163.225.70 239.2.1.1 ip address 1.1.1.1 255.255.255.0 ip pim sparse-mode ip service reflect Ethernet0 destination 239.2.1.1 to 230.2.1.1 mask-len 32 source 1.1.1.2 Src: Dst: Payload ip igmp static-group 239.1.1.239 1.1.1.2 230.2.1.1 ! ip pim rp-address 2.2.2.2 DRAFT Version © 2010 Cisco Systems, Inc. All rights reserved. Cisco Confidential 12 Catalyst 6500 12.2(33)SXI4 New Borderless Features Video Green Security Performance Mobility Medianet . Service . EnergyWise . IPv6 HSRP Global . VSS Quad Sup . Industrial Architecture Phase 1 & 2 Address Uplink Forwarding Ethernet DHCP Server Port Framework . VSS support for . Cisco . IPv6 Port Access Based Address (SAF) SIP-400 Orchestrator Control List Allocation . Multicast software (PACL) support . Fast UDLD Service support . Advanced VPLS . IPv6 Policy-Based . Performance support for Reflection Routing Monitoring MIBS SIP-400 . IPv6 RA-Guard . 10G BASE-T . VPLS MAC Host Mode 16-Port 10 Gigabit Address . TrustSec IPv6 Ethernet Copper Withdrawal Module SGT Learning . New support for from Data-Path . SFP+ LRM optics MPLS Egress netflow. LACP Auto Interleaved Port . Netflow Data Priority Export to a collector in a VRF DRAFT Version © 2010 Cisco Systems, Inc. All rights reserved. Cisco Confidential 13 IPv6 Market Drivers Address space depletion National IT Strategy . Slow down of Internet Technologies U.S. Federal Mandate . Limiting expansion of enterprise into IPv6 Task Force and promotion councils: emerging markets Africa, India, Japan, Korea,… China Next Generation Internet (CNGI) project European Commission sponsored projects IP NGN Architecture Requires IPv6 IPv6 “on” & “preferred” by default DOCSIS 3.0, FTTH, HDTV, Quad Applications only running Play over IPv6 (P2P framework) Mobile SP – 3G, WiMax, PWLAN Networks in Motion Networked Sensors, ie: AIRS NAT Overlap – M&A MSFT Vista & Server 2008 Infrastructure Evolution DRAFT Version © 2010 Cisco Systems, Inc. All rights reserved. Cisco Confidential 14 Catalyst 6500 IPv6 Software Leadership Comprehensive IPv6 Feature Set IPv6 HA • IPv6 with VSS • ACL, DHCPv6 Snooping* • HSRPv6 , GLBPv6 • IPv6 First Hop Security* • BFD for OSPFv3* • TrustSec with IPv6* • NSF/SSO IPv6 forwarding* IPv6 Tunneling Multicast • MLDv1, access group, PIM SSM, • Configured, Automatic & ISATAP BSR, PIM embedded RP tunnels (RFC 2893) • Multicast over 6VPE with Inter-AS • 6to4 (RFC 3056) and Extranet Support* • IPv6 over GRE/IPv4/MPLS (6PE) • Multicast over GRE • Native IPv6 VPNs (6VPE) IPv6 Routing IPv6 QoS • Support for following protocols: • Full support for classification Static routes, RIPng IS-IS , MP- policing, queuing of IPv6 packets BGP4, OSPFv3, Neighbor • IPv6 CoPP* discovery (RFC 2461) Applications & Mgmt • OSPFv3 Authentication* • IPv6 PBR, PBR Set VRF* • Telnet, TFTP, DNS resolver, HTTP, ping, traceroute, SSH, SNMP*, Forwarding Syslog*, TACACS+*, NTPv4*, Radius*, AAA*, NAM Support* • Unicast and Multicast IPv6 in • FlexNetFlowfor IPv6 in hardware Hardware (RFC 2460), CEFv6/ • ICMPv6 (RFC 2463) dCEFv6 • DHCPv6 and DHCP Relay • VRF Aware Svcs* , ECMP • IPv6 Stats and Counters* • 200Mpps+ HW forwarding • IPv6 DHCP Helper Address MIB* • WCCP v3 with IPv6 support* DRAFT Version © 2010 Cisco Systems, Inc. All rights reserved. Cisco Confidential Note: items marked with (*) indicate features under development Security - IPv6 PACL support (IPv4 Parity) IPv4 IPv6 RACL VACL PACL RACL VACL PACL PFC/DFC 3A ✔ ✔ ✔ ✔ ✔ 12.2(33)SXI4 PFC/DFC 3B ✔ ✔ ✔ ✔ ✔ 12.2(33)SXI4 PFC/DFC 3BXL ✔ ✔ ✔ ✔ ✔ 12.2(33)SXI4 PFC/DFC 3C ✔ ✔ ✔ ✔ ✔ 12.2(33)SXI4 PFC/DFC 3CXL ✔ ✔ ✔ ✔ ✔ 12.2(33)SXI4 VSS ✔ ✔ ✔ ✔ ✔ 12.2(33)SXI4 . Catalyst 6500 supports IPv6 PACL by programming IPv6 ACEs into layer 3 forwarding engine security TCAM, same capabilities as IPv6 RACL. IPv6 PACL is an ingress security feature. IPv6 PACL requires advance ip service IOS feature set or above. Port based ACL (PACL) provides a mechanism to filer the incoming packets based on layer 2-4 parameters at layer 2 port level.
Load more

Recommended publications
  • IEEE 802.1Aq Standard, Is a Computer Networking Technology Intended to Simplify the Creation and Configuration of Networks, While Enabling Multipath Routing
    Brought to you by: Brian Miller Yuri Spillman - Specified in the IEEE 802.1aq standard, is a computer networking technology intended to simplify the creation and configuration of networks, while enabling multipath routing. - Link State Protocol - Based on IS-IS -The standard is the replacement for the older spanning tree protocols such as IEEE 802.1D, IEEE 802.1w, and IEEE 802.1s. These blocked any redundant paths that could result in layer 2(Data Link Layer), whereas IEEE 802.1aq allows all paths to be active with multiple equal cost paths, and provides much larger layer 2 topologies. 802.1aq is an amendment to the "Virtual Bridge Local Area Networks“ and adds Shortest Path Bridging (SPB). Shortest path bridging, which is undergoing IEEE’s standardization process, is meant to replace the spanning tree protocol (STP). STP was created to prevent bridge loops by allowing only one path between network switches or ports. When a network segment goes down, an alternate path is chosen and this process can cause unacceptable delays in a data center network. The ability to use all available physical connectivity, because loop avoidance uses a Control Plane with a global view of network topology Fast restoration of connectivity after failure, again because of Link State routing's global view of network topology Under failure, the property that only directly affected traffic is impacted during restoration; all unaffected traffic just continues Ideas are rejected by IEEE 802.1. accepted by the IETF and the TRILL WG is formed. Whoops, there is a problem. They start 802.1aq for spanning tree based shortest path bridging Whoops, spanning tree doesn’t hack it.
    [Show full text]
  • TRILL Deployment Nears
    TRILL Deployment Nears August 3rd – 5th 2010 Introduction An exciting milestone on the road to TRILL deployment occurred from August 3rd to 5th 2010 at the University of New Hampshire InterOperability Laboratory (UNH-IOL), as a group of companies attended the first multi-vendor TRILL plugfest. The plugfest was successful in demonstrating interoperability between TRILL devices. It was a first step towards wide deployment of TRILL and valuable knowledge for increasing TRILL interoperability was gained through the event. The UNH-IOL is excited to be hosting another TRILL plugfest in Q1 of 2011. This whitepaper discusses the TRILL protocol to help inform potential TRILL equipment customers about the benefits of adoption of TRILL in their networks along with describing what this plugfest means for those looking towards the deployment of TRILL. The Need for a Replacement for Spanning Tree In 2002, the Beth Israel Deaconess Medical Center in Boston, MA had a massive system failure caused by a Spanning Tree Protocol loop (1). This led Radia Perlman, the inventor of Spanning Tree Protocol (2), and others to come up with the concept of a “Routing Bridge” (RBridge) (3) and the protocol TRansparent Interconnection of Lots of Links (TRILL). Most of TRILL, the intended replacement for Spanning Tree Protocol, has been approved as a standard and the last part recently went into working group last call, meaning full standardization is nearly complete. For now, let’s see how Spanning Tree contributed to “one of the worst health-care IT disasters ever.” i The first sign that something was wrong was when it started to take several seconds to send and receive e-mail at the medical center.
    [Show full text]
  • Colasoft Capsa
    Technical Specifications (Capsa Standard) HP Unix Nettl Packet File (*.TRCO; TRC1) Deployment Environment Libpcap (Wireshark, Tcpdump, Ethereal, etc.) Shared networks (*.cap; *pcap) Switched networks (managed switches and Wireshark (Wireshark, etc.) (*.pcapang; unmanaged switches) *pcapang.gz; *.ntar; *.ntar.gz) Network segments Microsoft Network Monitor 1.x 2.x (*.cap) Proxy server Novell LANalyer (*.tr1) Network Instruments Observer V9.0 (*.bfr) Supported Network Types NetXRay 2.0, and Windows Sniffer (*.cap) Ethernet Sun_Snoop (*.Snoop) Fast Ethernet Visual Network Traffic Capture (*.cap) Gigabit Ethernet Supported Packet File Formats to Export Supported Network Adapters Accellent 5Views Packet File (*.5vw) 10/100/1000 Mbps Ethernet adapters Colasoft Packet File (V3) (*.rapkt) Colasoft Packet File (*.cscpkt) System Requirements Colasoft Raw Packet File (*.rawpkt） Operating Systems Colasoft Raw Packet File (V2) (*.rawpkt） Windows Server 2008 (64-bit) EtherPeek Packet File (V9) (*.pkt) Windows Server 2012 (64-bit)* HP Unix Nettl Packet File (*.TRCO; *.TRC1) Windows Vista (64-bit) Libpcap (Wireshark, Tcpdump, Ethereal, etc.) Windows 7 (64-bit) (*.cap; *pcap) Windows 8/8.1 (64-bit) Wireshark (Wireshark, etc.) (*.pcapang; Windows 10 Professional (64-bit) *pcapang.gz; *.ntar; *.ntar.gz) Microsoft Network Monitor 1.x 2.x (*.cap) * indicates that Colasoft Packet Builder is not Novell LANalyer (*.tr1) compatible with this operating system. NetXRay 2.0, and Windows Sniffer (*.cap) Minimum Sun_Snoop (*.Snoop)
    [Show full text]
  • 7956 Y. Li Category: Standards Track Huawei ISSN: 2070-1721 A
    Internet Engineering Task Force (IETF) W. Hao Request for Comments: 7956 Y. Li Category: Standards Track Huawei ISSN: 2070-1721 A. Qu MediaTec M. Durrani Equinix Inc. P. Sivamurugan IP Infusion September 2016 Transparent Interconnection of Lots of Links (TRILL) Distributed Layer 3 Gateway Abstract The base TRILL (Transparent Interconnection of Lots of Links) protocol provides optimal pair-wise data frame forwarding for Layer 2 intra-subnet traffic but not for Layer 3 inter-subnet traffic. A centralized gateway solution is typically used for Layer 3 inter- subnet traffic forwarding but has the following issues: 1. Sub-optimum forwarding paths for inter-subnet traffic. 2. A centralized gateway that may need to support a very large number of gateway interfaces in a Data Center, one per tenant per Data Label used by that tenant, to provide interconnect functionality for all the Layer 2 Virtual Networks in a TRILL campus. 3. A traffic bottleneck at the gateway. This document specifies an optional TRILL distributed gateway solution that resolves these centralized gateway issues. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7956.
    [Show full text]
  • Introduction to Software Defined Networking (SDN)
    IntroductionIntroduction toto SoftwareSoftware DefinedDefined . NetworkingNetworking (SDN)(SDN) SDN=Standard Southbound API SDN = Centralization of control plane SDN=OpenFlow SDN = Separation of Control and Data Planes Raj Jain Washington University in Saint Louis Saint Louis, MO 63130 [email protected] These slides and audio/video recordings of this class lecture are at: http://www.cse.wustl.edu/~jain/cse570-13/ Washington University in St. Louis http://www.cse.wustl.edu/~jain/cse570-13/ ©2013 Raj Jain 16-1 OverviewOverview 1. What is SDN? 2. Alternative APIs: XMPP, PCE, ForCES, ALTO 3. RESTful APIs and OSGi Framework 4. OpenDaylight SDN Controller Platform and Tools Note: This is the third module of four modules on OpenFlow, OpenFlow Controllers, SDN and NFV in this course. Washington University in St. Louis http://www.cse.wustl.edu/~jain/cse570-13/ ©2013 Raj Jain 16-2 OriginsOrigins ofof SDNSDN SDN originated from OpenFlow Centralized Controller Easy to program Change routing policies on the fly Software Defined Network (SDN) Initially, SDN= Application … Application Separation of Control and Data Northbound Plane API Network Controller Centralization of Control Southbound API OpenFlow OpenFlow to talk to the data plane Switch Switch … Switch Now the definition has changed significantly. Overlay (Tunnels) Washington University in St. Louis http://www.cse.wustl.edu/~jain/cse570-13/ ©2013 Raj Jain 16-3 WhatWhat isis SDN?SDN? SDN=OpenFlow SDN=Standard SDN = Centralization Southbound API of control plane SDN = Separation of Control and Data Planes All of these are mechanisms. SDN is not a mechanism. It is a framework to solve a set of problems Many solutions Washington University in St.
    [Show full text]
  • Testing TRILL (Transparent Interconnect for Lots of Links)
    University of New Hampshire InterOperability Laboratory 121 Technology Drive Suite 2 Durham, NH 03824 Testing TRILL (TRansparent Interconnect for Lots of Links) By: Christina Dube, Senior Manager, Ethernet Switching Technologies, UNH InterOperability Laboratory Abstract The University of New Hampshire InterOperability Laboratory (UNH-IOL) hosted its second TRansparent Interconnect of Lots of Links (TRILL) Interoperability Test Event the week of November 26 – December 1, 2012 at its 32,000+ square-foot facility in Durham, New Hampshire. The test event brought together implementers of TRILL as well as test equipment manufacturers that support TRILL. The purpose of the test event was to gain a perspective on the current status of TRILL implementation and interoperability. Participants included Hewlett-Packard Networking, Extreme Networks, Ixia and Spirent Communications. Introduction The Spanning Tree Protocol (STP) was created to ensure a loop-free topology for bridged Ethernet despite having redundant links within the topology. These redundant links allow for automatic fail over in the case of an inactive link. At the time of the Spanning Tree Protocol’s creation, data networking was in its infancy. Since then, as data communication networks have grown, and STP has been implemented in large scale networks, limitations of the protocol have come to light. TRILL provides a solution to current STP limitations by combining Layer 2 and Layer 3 technologies. It applies link state routing to Virtual Local-Area Network (VLAN) aware bridges, which allows for the deployment of large scale Layer 2 networks. Additionally, TRILL allows the current Spanning Tree topology to still exist, essentially filling in the limitations of the Spanning Tree.
    [Show full text]
  • Performance of Meshed Tree Protocols for Loop Avoidance in Switched Networks Kuhu Sharma
    Rochester Institute of Technology RIT Scholar Works Articles 2014 Performance of Meshed Tree Protocols for Loop Avoidance in Switched Networks Kuhu Sharma Bill Stackpole Daryl Johnson Nirmala Shenoy Bruce Hartpence Follow this and additional works at: http://scholarworks.rit.edu/article Recommended Citation Sharma, Kuhu; Stackpole, Bill; Johnson, Daryl; Shenoy, Nirmala; and Hartpence, Bruce, "Performance of Meshed Tree Protocols for Loop Avoidance in Switched Networks" (2014). The International Journal on Advances in Networks and Services, 7 (3&4), 228-239. Accessed from http://scholarworks.rit.edu/article/1806 This Article is brought to you for free and open access by RIT Scholar Works. It has been accepted for inclusion in Articles by an authorized administrator of RIT Scholar Works. For more information, please contact [email protected]. Performance of Meshed Tree Protocols for Loop Avoidance in Switched Networks Kuhu Sharma, Bill Stackpole, Daryl Johnson, Nirmala Shenoy and Bruce Hartpence College of Computing and Information Sciences Rochester Institute of Technology, Rochester, NY, USA [email protected], [email protected], [email protected], [email protected], [email protected] Abstract—Loop free frame forwarding in layer 2 switched through the root and a second is the root re-election on networks that use meshed topologies to provision for link and topology changes. Radia Perlman then proposed path redundancy is a continuing challenge. The challenge is Transparent Interconnection of Lots of Links (TRILL) on addressed through special protocols at layer 2 that build RBridges (router bridges) to overcome the disadvantages of logical trees over the physically meshed topologies, along which STA-based loop avoidance.
    [Show full text]
  • Introduction to TRILL by Radia Perlman, Intel Labs, and Donald Eastlake, Huawei Technologies
    September 2011 Volume 14, Number 3 A Quarterly Technical Publication for From The Editor Internet and Intranet Professionals I recently attended a conference in Japan where the attendee network offered IPv6 service only. In the past, conferences such as the Asia In This Issue Pacific Regional Conference on Operational Technologies (APRICOT) and meetings of the Internet Engineering Task Force (IETF) have conducted IPv6 experiments, but these have all been “opt-in” events. From the Editor ...................... 1 The conference in Japan was different: there was no IPv4 service available. Making this work involved a few manual configuration TRILL ..................................... 2 steps, but for the most part everything worked more or less the same as it did under IPv4. Some applications, including my instant message client and Skype did not work, and all connections to IPv4-only hosts IP Backhaul ........................... 21 needed to use Fully Qualified Domain Names (FQDNs) instead of IP addresses, but overall the experience gave me confidence that IPv6 is becoming a reality. As you might expect, this IPv6-only experiment Fragments ............................. 30 also uncovered a number of bugs and incompatibilities that were duly reported to developers around the world. Call for Papers ...................... 31 Our first article is an overview of TRansparent Interconnection of Lots of Links (TRILL). TRILL uses Layer 3 routing techniques to create a large cloud of links that appear to IP nodes to be a single IP subnet. The protocol has been developed in the IETF and is currently being refined and enhanced in the TRILL working group. The article is by Radia Perlman and Donald Eastlake.
    [Show full text]
  • Support for Rbridge VLAN and Priority Regions, So That a VLAN ID Or
    To TRILL WG co-chairs , ADs and IEEE-IETF liaisons: From: IEEE 802.1 Thank you for your liaison sent to us March 14, 2010. We understand that this was for our information. There is a perceived rift in layer 2 bridging standards involving IETF Trill and IEEE 802.1. We use similar terms, and have shortest path projects to support 802.1 external interfaces in similar environments. Whatever the original objectives in both groups, these projects are converging on two ways to do similar things. For example, you offered information about a re-charter item: (8) Support for RBridge VLAN and priority regions, so that a VLAN ID or priority may have different meanings in different regions, requiring configuration only at border RBridges IEEE 802.1Q supports Bridged Networks that span multiple administrative domains, and allows for of the establishment of regions within those domains. IEEE 802.1Q also allows for the translation of VLAN Identifiers and Priority Code Points in frames when those frames cross region boundaries. Assuming IETF and IEEE have similar concepts of a “region”, it sounds like there is direct overlap between the capabilities currently supported in 802.1Q and the proposed TRILL work item. In regards to the other item you offered for information: (9) Specify the use of the TRILL protocol in data centers, such as by adding any support that may be need for IEEE 802.1 "Data Center Bridging" standards In our understanding, the only addition that is needed to support the current DCB Standards is interworking function for Congestion notification messages.
    [Show full text]
  • TRILL Over IP Draft-Mrw-Trill-Over-Ip-00.Txt
    TRILL over IP draft-mrw-trill-over-ip-00.txt Margaret Wasserman <[email protected]> Donald Eastlake <[email protected]> Dacheng Zhang <[email protected]> TRILL over IP Basics TRILL Protocol defined in RFCs 6325, 6326 & 6327 TRILL is already defined to work over different link layer types, both multicast and point-to-point Ethernet (RFC 6325) & PPP (RFC 6361) TRILL over IP defines how TRILL can be run over UDP/IP TRILL packets are encapsulated in UDP/IP(v4 or v6), and sent over any IP network Very simple encapsulation, does not modify TRILL TRILL over IP Scenarios Remote Office Scenario Nodes in a remote office are connected to a central TRILL campus over a multi-hop network, possibly the public Internet IP Backbone Scenario TRILL links within an enterprise network are connected, as a single TRILL campus, over an IP backbone Remote Office Scenario Remote Remote Office Office RB RB RB RB Main TRILL Campus Pairs (or small sets?) of RBridges used to connect remote offices to a central TRILL Campus TRILL over IP links run across multi-hop networks (such as the public Internet). May not be under the same administrative control as the TRILL campus, may not support multicast. IP Backbone Scenario TRILL over IP Backbone RB RB RB TRILL Links Multiple TRILL links within a single campus, connected using a TRILL over IP backbone The TRILL over IP link is part of the TRILL campus. Multiple (even many?) RBridges may be on a single TRILL over IP link, and the link will typically support multicast Key Differences: Security In Remote Office Scenario, TRILL over IP traffic will be tunneled over links that may not be in the same administrative control as the TRILL campus.
    [Show full text]
  • CLI Reference Guide for Arubaos-CX, Arubaos-Switch, Comware and Cisco IOS
    CLI Reference Guide for ArubaOS-CX, ArubaOS-Switch, Comware and Cisco IOS Published: November 2018 Rev: 4 Table of Contents Introduction ..................................................................................................................................................................................... 3 Using This Guide ............................................................................................................................................................................ 4 Comware Differences .............................................................................................................................................................. 4 Navigation Differences Among CLIs .................................................................................................................................. 4 Configuration Differences Among CLIs ............................................................................................................................ 4 Terminology Differences ........................................................................................................................................................ 6 Disclaimer ......................................................................................................................................................................................... 6 Comparing View and Configuration Prompts ...................................................................................................................
    [Show full text]
  • 8385 Cisco Category: Informational S. Kingston Smiler ISSN: 2070-1721 PALC Networks D
    Internet Engineering Task Force (IETF) M. Umair Request for Comments: 8385 Cisco Category: Informational S. Kingston Smiler ISSN: 2070-1721 PALC Networks D. Eastlake 3rd Huawei L. Yong Independent June 2018 Transparent Interconnection of Lots of Links (TRILL) Transparent Transport over MPLS Abstract This document specifies methods to interconnect multiple TRILL (Transparent Interconnection of Lots of Links) sites with an intervening MPLS network using existing TRILL and VPLS (Virtual Private LAN Service) standards. This document addresses two problems: 1) providing connection between more than two TRILL sites that are separated by an MPLS provider network and 2) providing a single logical virtualized TRILL network for different tenants that are separated by an MPLS provider network. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8385. Umair, et al. Informational [Page 1] RFC 8385 TRILL Transparent Transport over MPLS June 2018 Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document.
    [Show full text]