Posts

Showing posts from March 10, 2013

GMPLS Operation and Deployment Challenges

GMPLS extends MPLS functionality with the enhancement of forwarding, traffic engineering, and quality-of-service (QoS) capabilities of packet-based networks by creating virtual label-switched paths (LSPs) across a network of label switching routers (LSRs) to optical network devices utilizing time-division multiplexing (TDM), fiber switching, and lambda switching. In a GMPLS network it is therefore possible to find and provision end-to-end paths that traverse different networks. For example, a packet/cell-based LSP can be nested in a TDM-based LSP for transport over a SONET network. The TDM-based LSP can similarly be nested in a lambda-based LSP for transport over a wavelength network. Multiple lambda switch-capable LSPs can be nested within a fiber switch-capable set up between two fiber switching elements. This forwarding hierarchy of nested LSPs allows service providers to transparently send different types of traffic over various types of network segments. GMPLS introduces Link

Cisco Dynamic Packet Transport (DPT) / Resilient Packet Ring (RPR)

DPT/RPR uses two symmetric bi-directional counter-rotating fiber rings. Each fiber ring can be concurrently utilized to pass both data and control packets. Data can be sent on both rings simultaneously. The rings are referred to as “bi-directional counter-rotating” rings, because traffic travels in opposite directions on the rings. To distinguish between the two rings, one fiber ring is referred to as the “inner” ring and the other as the “outer” ring. Notice the outer ring sends traffic clockwise while the inner ring sends traffic counter-clockwise.  At the same time as data is sent (downstream) on one ring, a corresponding control packet is sent (upstream) around on the other ring. Having control packets traveling in the opposite direction on a separate ring makes it possible to restore service more quickly in the event of a failure.  DPT/RPR uses the entire concatenated payload at the specified line rate. For example, at OC48 or STM16 both fiber rings use the entire 2.5 gigabits

SONET Transport Hierarchy

SONET Transport Hierarchy Each level of the hierarchy terminates its corresponding fields in the SONET payload, as such: Section A section is a single fiber run that can be terminated by a network element (Line or Path) or an optical regenerator. The main function of the section layer is to properly format the SONET frames, and to convert the electrical signals to optical signals. Section Terminating Equipment (STE) can originate, access, modify, or terminate the section header overhead. (A standard STS-1 frame is nine rows by 90 bytes. The first three bytes of each row comprise the Section and Line header overhead.) Line Line-Terminating Equipment (LTE) originates or terminates one or more sections of a line signal. The LTE does the synchronization and multiplexing of information on SONET frames. Multiple lower-level SONET signals can be mixed together to form higher-level SONET signals. An Add/Drop Multiplexer (ADM) is an example of LTE. Path Path-Terminating Equipm

Selective Packet Discard (SPD)

Overview Selective Packet Discard (SPD) is a mechanism to manage the process level input queues on the Route Processor (RP). The goal of SPD is to provide priority to routing protocol packets and other important traffic control Layer 2 keepalives during periods of process level queue congestion. Historically, on platforms such as the Cisco 7x00 and non-Cisco Express Forwarding (CEF) 7500 systems, significant numbers of transit packets were forwarded by the Route Processor in order to populate the fast switching cache. Consequently, SPD was required in this case to prioritize the routing protocol packets over the transit packets which share the same queue. Currently, on the Cisco 12000 Series Internet Router and on the 7500 running CEF, only traffic destined to the router itself is sent to process level. In this case, SPD is used to prioritize routing protocol packets when management traffic such as Simple Network Management Protocol (SNMP) is present or when a Denial of Service

Layer Two Tunneling Protocol - Version 3 (L2TPv3) - ICRQ

Incoming-Call-Request (ICRQ) Incoming-Call-Request (ICRQ) is the control message sent by an LCCE to a peer when an incoming call is detected (although the ICRQ may also be sent as a result of a local event).  It is the first in a three-message exchange used for establishing a session via an L2TP control connection. The ICRQ is used to indicate that a session is to be established between an LCCE and a peer.  The sender of an ICRQ provides the peer with parameter information for the session.  However, the sender makes no demands about how the session is terminated at the peer (i.e., whether the L2 traffic is processed locally, forwarded, etc.).    The following AVPs MUST be present in the ICRQ:     Message Type     Local Session ID     Remote Session ID     Serial Number     Pseudowire Type     Remote End ID     Circuit Status

How BGP Graceful Restart Preserves Prefix Information During a Restart?

Image
When a router that is capable of BGP Graceful Restart loses connectivity, the following happens to the restarting router: 1. The router establishes BGP sessions with other routers and relearns the BGP routes from other routers that are also capable of Graceful Restart. The restarting router waits to receive updates from the neighboring routers. When the neighboring routers send end-of-Routing Information Base (RIB) markers to indicate that they are done sending updates, the restarting router starts sending its own updates. 2. The restarting router accesses the checkpoint database to find the label that was assigned for each prefix. If it finds the label, it advertises it to the neighboring router. If it does not find the label, it allocates a new label and advertises it. 3. The restarting router removes any stale prefixes after a timer for stale entries expires. When a peer router that is capable of BGP Graceful Restart encounters a restarting router, it does the following:

Layer 2 VPNs Cisco IOS MPLS Virtual Private LAN Service

The signaling requirements of VPLS: The virtual circuit setup uses the same LDP signaling mechanism defined for point-to-point services. Using a directed LDP session, each provider edge advertises a virtual circuit label mapping that is used as part of the label stack imposed on the Ethernet frames by the ingress provider edge during packet forwarding. The reachability information distributed in a VPLS Cisco VPLS does not require the exchange of reachability (MAC addresses) information via a signaling protocol. This information is learned from the data plane using standard address learning, aging, and filtering mechanisms defined for Ethernet bridging. However, the LDP signaling used for setting up and tearing down the virtual circuits can be used to indicate to a remote provider edge that some or all MAC addresses learned over a virtual circuit need to be withdrawn from the VSI. This mechanism provides a convergence optimization over the normal address aging that would eventual

THE G.709 OPTICAL TRANSPORT NETWORK - Optical Data Unit (ODU)

Optical Data Unit (ODU) The ODU overhead is broken into several fields: RES, PM, TCMi, TCM ACT, FTFL, EXP, GCC1/GCC2 and APS/PCC. The reserved (RES) bytes are undefined and are set aside for future applications. The path monitoring (PM) field is similar to the SM field described above. It contains the TTI, BIP-8, BEI, BDI and Status (STAT) sub-fields. There are six tandem connection monitoring (TCMi) fields that define the ODU TCM sub-layer, each containing TTI, BIP-8, BEI/BIAE, BDI and STAT sub-fields associated to each TCM level (i=1 to 6). The STAT sub-field is used in the PM and TCMi fields to provide an indication of the presence or absence of maintenance signals. The tandem connection monitoring activation/deactivation (TCM ACT) field is currently undefined in the standards. The fault type and fault location reporting communication channel (FTFL) field is used to create a message spread over a 256-byte multiframe. It provides the ability to send forward and backward pa

CRC Troubleshooting Guide for ATM Interfaces

Reasons for ATM CRC Errors The following are some potential reasons for ATM CRC errors: Dropped cells due to traffic policing in the ATM cloud on one or more VCs attached to the ATM interface. Noise, gain hits, or other transmission problems on the data-link equipment. A faulty or failing ATM interface. The show interfaces command output displays the CRC error count. These errors suggest that when the SAR reassembles the packet and checks the CRC, the calculated CRC value does not match the value in the assembled packet's CRC field.

HDLC Operational Modes

HDLC offers three different modes of operation. These three modes of operations are: Normal Response Mode(NRM) Asynchronous Response Mode(ARM) Asynchronous Balanced Mode(ABM) Normal Response Mode This is the mode in which the primary station initiates transfers to the secondary station. The secondary station can only transmit a response when, and only when, it is instructed to do so by the primary station. In other words, the secondary station must receive explicit permission from the primary station to transfer a response. After receiving permission from the primary station, the secondary station initiates it's transmission. This transmission from the secondary station to the primary station may be much more than just an acknowledgment of a frame. It may in fact be more than one information frame. Once the last frame is transmitted by the secondary station, it must wait once again from explicit permission to transfer anything, from the primary station. Normal Response Mode

Class-Based Tunnel Selection: CBTS

Class-Based Tunnel Selection: CBTS EXP-based selection between multiple tunnels to same destination Local mechanism at head-end (no IGP extensions) Tunnel master bundles tunnel members Tunnel selection configured on tunnel master (auto-route, etc.) Bundle members configured with EXP values to carry Bundle members may be configured as default Supports VRF traffic, IP-to-MPLS and MPLS-to-MPLS switching paths Reference: http://meetings.apnic.net/__data/assets/pdf_file/0010/45010/MPLS-TE.pdf

Sink Holes - Understand And Analyze Your Network

Image
Sinkhole Routers/Networks •Sinkholes are a topological security feature—somewhat analogous to a honeypot •Router or workstation built to suck in traffic and assist in analyzing attacks (original use) •Used to redirect attacks away from the customer—working the attack on a router built to withstand the attack •Used to monitor attack noise, scans, data from misconfiguration and other activity (via the advertisement of default or unused IP space) •Traffic is typically diverted via BGP route advertisements and policies •Leverage instrumentation in a controlled environment—Pull the traffic past analyzers/analysis tools Why Sinkholes? •They work! Providers, enterprise operators and researchers use them in their network for data collection and analysis •More uses are being found through experience and individual innovation •Deploying sinkholes correctly takes preparation BGP Trigger •Leverage the same BGP technique used for RTBH •Dedicated trigger router redistributes mor

MPLS VPN - Route Target Rewrite

Image
Prerequisites for MPLS VPN - Route Target Rewrite The MPLS VPN - Route Target Rewrite feature requires the following: • You should know how to configure Multiprotocol Virtual Private Networks (MPLS VPNs). • You need to configure your network to support interautonomous systems (Inter-AS) with different route target (RT) values in each autonomous system (AS). • You need to identify the RT replacement policy and target router for each AS. Route Target Replacement Policy Routing policies for a peer include all configurations that may impact inbound or outbound routing table updates. The MPLS VPN - Route Target Rewrite feature can influence routing table updates by allowing the replacement of route targets on inbound and outbound BGP updates. Route targets are carried as extended community attributes in BGP Virtual Private Network IP Version 4 (VPNv4) updates. Route target extended community attributes are used to identify a set of sites and VPN routing/forwarding instanc

Remote Trigger Black Hole Filtering

Image
Remotely Triggered Blackhole Filtering We will use BGP to trigger a network wide response to an attack  A simple static route and BGP will enable a network-wide destination address blackhole as fast as iBGP can update the network  This provides a tool that can be used to respond to security related events and forms a foundation for other remote triggered uses  Often referred to as RTBH Step 1: Prepare All the Routers with Trigger Select a small block that will not be used for anything other than blackhole filtering; test Net (192.0.2.0/24) is optimal since it should not be in use Put a static route with a /32 from Test-Net—192.0.2.0/24 to Null 0 on every edge router on the network ip route 192.0.2.1 255.255.255.255 Null0  Step 2: Prepare the Trigger Router The Trigger Router Is the Device That Will Inject the iBGP Announcement into the ISP’s Network Should be part of the iBGP mesh—but does not have to accept routes Can be a separate router (recommende

MPLS Traffic Engineering - DiffServ Aware (DS-TE)

Image
MPLS Traffic Engineering - DiffServ Aware (DS-TE) Background and Overview MPLS traffic engineering allows constraint-based routing (CBR) of IP traffic. One of the constraints satisfied by CBR is the availability of required bandwidth over a selected path. DiffServ-aware Traffic Engineering extends MPLS traffic engineering to enable you to perform constraint-based routing of "guaranteed" traffic, which satisfies a more restrictive bandwidth constraint than that satisfied by CBR for regular traffic. The more restrictive bandwidth is termed a  sub-pool , while the regular TE tunnel bandwidth is called the  global pool . (The sub-pool is a portion of the global pool. In the new IETF-Standard, the global pool is called BC0 and the sub-pool is called BC1. These are two of an eventually available eight Class Types). This ability to satisfy a more restrictive bandwidth constraint translates into an ability to achieve higher Quality of Service performance in terms of delay, jitter,

Frame Relay Local Management Interface Optional Extensions

Optional LMI Extensions The LMI specification also defines several optional extensions: Global addressing convention Multicast capability A simple flow control mechanism Ability for the network to communicate a PVC's CIR to the subscriber in a Status message A new message type that allows the network to announce PVC status changes without prompting from the subscriber Implementors may build any, all, or none of these features into their networks. Global Addressing The global addressing convention defines a simple commitment from the operator of a network that DLCIs will remain unique throughout the network. In a globally addressed network, each DLCI identifies a subscriber device uniquely. For a few years Frame Relay networks will remain small enough that they won't need to implement extended addressing to use the global addressing feature. As networks grow and interconnect, any trend toward global addressing will probably require use of extended addresses. Mul

Inter-Autonomous System Connectivity: Another Application of Tunnels

Image
Carrier Supporting Carrier Carrier supporting carrier  (CsC) is a two-layer IP VPN solution designed to allow a backbone carrier to use MPLS VPN (or L2TPv3) to carry traffic belonging to customers' carriers that use MPLS VPNs. Before looking at the solution, it is a good idea to understand the problem being solved . An MPLS PE router holds all the routes of all the sites to which it connects. In a normal scenario, although this  number  can be large, the expectation is that an individual VPN would require at most hundreds or perhaps thousands of entries in a VRF. However, if the customer is itself an ISP, carrying routes belonging to their customers, the potential exists to require the backbone PE to carry an impossibly large number of routes. The CsC solution addresses this issue. CsC is based on the observation that the label switched domain of an MPLS VPN network (that is, the backbone network) only needs routing information to reach provider (P) routersthe customer rout

SONET Transport Hierarchy

SONET Transport Hierarchy Each level of the hierarchy terminates its corresponding fields in the SONET payload, as such: Section A section is a single fiber run that can be terminated by a network element (Line or Path) or an optical regenerator. The main function of the section layer is to properly format the SONET frames, and to convert the electrical signals to optical signals. Section Terminating Equipment (STE) can originate, access, modify, or terminate the section header overhead. ( A standard STS-1 frame is nine rows by 90 bytes. The first three bytes of each row comprise the Section and Line header overhead. ) Line Line-Terminating Equipment (LTE) originates or terminates one or more sections of a line signal. The LTE does the synchronization and multiplexing of information on SONET frames. Multiple lower-level SONET signals can be mixed together to form higher-level SONET signals. An Add/Drop Multiplexer (ADM) is an example of LTE. Path Path-Terminating Equ

Cisco CRS-1 Multishelf System Hardware Overview

Cisco CRS-1 16-Slot Line Card Chassis The LCC is a mechanical enclosure that houses modular services cards (MSCs) and their associated physical layer interface modules (PLIMs), switch fabric cards (SFCs), route processor (RP) cards, and distributed route processor (DRP) cards. The LCC is bolted to the facility floor and does not require an external rack. The LCC contains its own power and cooling systems. A minimum of two LCCs are required to configure a multishelf system. Cisco CRS-1 Fabric Card Chassis The FCC is a mechanical enclosure that houses switch fabric cards (SFCs) and shelf controller Gigabit Ethernet (SCGE) cards (2-port or 22-port) in the front of the chassis. The rear of the chassis houses the optical interface modules (OIMs) and the OIM light emitting diode (LED) monitoring card (OIM-LED). The FCC is bolted to the facility floor and does not require an external rack. The FCC contains its own power and cooling systems. At least one FCC is required to configure a

MPLS VPN QoS Design

Customer Edge QoS Design Considerations In addition to the full-mesh implication of MPLS VPNs, these considerations should be kept in mind when considering MPLS VPN CE QoS design: Layer 2 access (link-specific) QoS design Service-provider service-level agreements (SLA) Enterprise-to-service provider mapping models http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/VPNQoS.pdf

QoS DSCP for Call-Signaling

Image
Call-Signaling Traffic The following are key QoS requirements and recommendations for Call-Signaling traffic: • Call-Signaling  traffic should be marked as  DSCP CS3  per the QoS Baseline (during migration, it may also be marked the legacy value of DSCP AF31). • 150 bps  (plus Layer 2 overhead) per phone of  guaranteed bandwidth  is required for voice control traffic; more may be required, depending on the call signaling protocol(s) in use. Call-Signaling traffic was originally marked by Cisco IP Telephony equipment to DSCP AF31. However, the Assured Forwarding classes, as defined in RFC 2597, were intended for flows that could be subject to markdown and - subsequently - the aggressive dropping of marked-down values. Marking down and aggressively dropping Call-Signaling could result in noticeable delay-to-dial-tone (DDT) and lengthy call setup times, both of which generally translate to poor user experiences. The QoS Baseline changed the marking recommendation for Call

Metro Ethernet Forum (MEF) Services

Image
MEF Services Overview MEF Ethernet Services are defined as connectivity services provided by a Service Provider's Carrier Ethernet Networks (CENs) to Customer Edge (CE) devices.  The connectivity service is modeled by an Ethernet Virtual Connection (EVC). The EVC is defined as an association of two or more User Network Interfaces (UNIs) that limits the exchange of Service Frames to UNIs in the EVC.  An Ethernet Service [9] [10] consists of an Ethernet Service Type and is associated with one or more Bandwidth Profile(s) and supports one or more Classes of Service. A service is also associated with a list of Layer Two Control Protocols such as Spanning Tree Protocol or Link Aggregation Control Protocol and a set of actions that specify how they should be handled. MEF Service Ethernet Service Types can be used to create a broad range of Subscriber services. The service types are characterized by their required connectivity [10]. The following service types have been defined to