LLD Template 7April05

(1)

Cisco Systems Advanced Services

Low Level Design Template

Version 0.1

Corporate Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 526-4100

(2)

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio-frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense.

The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-frequency energy. If it is not installed in accordance with Cisco’s installation instructions, it may cause interference with radio and television reception. This equipment has been tested and found to comply with the limits for a Class B digital device in accordance with the specifications in part 15 of the FCC rules. These specifications are designed to provide reasonable protection against such interference in a residential installation. However, there is no guarantee that interference will not occur in a particular installation.

You can determine whether your equipment is causing interference by turning it off. If the interference stops, it was probably caused by the Cisco equipment or one of its peripheral devices. If the equipment causes interference to radio or television reception, try to correct the interference by using one or more of the following measures:

Turn the television or radio antenna until the interference stops. Move the equipment to one side or the other of the television or radio. Move the equipment farther away from the television or radio.

Plug the equipment into an outlet that is on a different circuit from the television or radio. (That is, make certain the equipment and the television or radio are on circuits controlled by different circuit breakers or fuses.)

Modifications to this product not authorized by Cisco Systems, Inc. could void the FCC approval and negate your authority to operate the product. The following third-party software may be included with your product and will be subject to the software license agreement:

CiscoWorks software and documentation are based in part on HP OpenView under license from the Hewlett-Packard Company. HP OpenView is a trademark of the Hewlett-Packard Company. Copyright  1992, 1993 Hewlett-Packard Company.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright  1981, Regents of the University of California.

Network Time Protocol (NTP). Copyright  1992, David L. Mills. The University of Delaware makes no representations about the suitability of this software for any purpose. Point-to-Point Protocol. Copyright  1989, Carnegie-Mellon University. All rights reserved. The name of the University may not be used to endorse or promote products derived from this software without specific prior written permission.

The Cisco implementation of TN3270 is an adaptation of the TN3270, curses, and termcap programs developed by the University of California, Berkeley (UCB) as part of the UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright  1981-1988, Regents of the University of California.

Cisco incorporates Fastmac and TrueView software and the RingRunner chip in some Token Ring products. Fastmac software is licensed to Cisco by Madge Networks Limited, and the RingRunner chip is licensed to Cisco by Madge NV. Fastmac, RingRunner, and TrueView are trademarks and in some jurisdictions registered trademarks of Madge Networks Limited. Copyright  1995, Madge Networks Limited. All rights reserved.

Xremote is a trademark of Network Computing Devices, Inc. Copyright  1989, Network Computing Devices, Inc., Mountain View, California. NCD makes no representations about the suitability of this software for any purpose.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PRACTICAL PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS

SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

AccessPath, AtmDirector, Browse with Me, CCDE, CCIP, CCSI, CD-PAC, CiscoLink, the Cisco NetWorks logo, the Cisco Powered Network logo, Cisco Systems Networking Academy, Fast Step, Follow Me Browsing, FormShare, FrameShare, GigaStack, IGX, Internet Quotient, IP/VC, iQ Breakthrough, iQ Expertise, iQ FastTrack, the iQ logo, iQ Net Readiness Scorecard, MGX, the Networkers logo, Packet, RateMUX, ScriptBuilder, ScriptShare, SlideCast, SMARTnet, TransPath, Unity, Voice LAN, Wavelength Router, and WebViewer are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Discover All That’s Possible, and Empowering the Internet Generation, are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert Logo, Cisco IOS, the Cisco IOS logo, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Enterprise/Solver, EtherChannel, EtherSwitch, FastHub, FastSwitch, IOS, IP/TV, LightStream, MICA, Network Registrar, PIX, Post-Routing, Pre-Routing, Registrar, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.

All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0105R)

INTELLECTUAL PROPERTY RIGHTS:

THIS DOCUMENT CONTAINS VALUABLE TRADE SECRETS AND CONFIDENTIAL INFORMATION OF CISCO SYSTEMS, INC. AND IT’S SUPPLIERS, AND SHALL NOT BE DISCLOSED TO ANY PERSON, ORGANIZATION, OR ENTITY UNLESS SUCH DISCLOSURE IS SUBJECT TO THE PROVISIONS OF A WRITTEN NON-DISCLOSURE AND PROPRIETARY RIGHTS AGREEMENT OR INTELLECTUAL PROPERTY LICENSE AGREEMENT APPROVED BY CISCO SYSTEMS, INC. THE DISTRIBUTION OF THIS DOCUMENT DOES NOT GRANT ANY LICENSE IN OR RIGHTS, IN WHOLE OR IN PART, TO THE CONTENT, THE PRODUCT(S), TECHNOLOGY OF

INTELLECTUAL PROPERTY DESCRIBED HEREIN.

Low Level Design Template

(3)

Tables

Table 1 Revision History... 13

Table 2 Revision Review... 14

Table 3 PE-P Connectivity in CO BA...32

Table 4 Software Release Table...50

Table 5 Proposed OSPF Metrics...54

Table 6 OSPF Timer Default Values...56

Table 7 RT/RD Allocation... 73

Table 8 BGP Timer Definitions...82

Table 9 Tunnel Provisioning...108

Table 10 Class-Selector PHBs...116

Table 11 Serialisation delay [ms] as function of link speed and packet size...119

Table 12 Recommended fragment size...121

Table 13 The components of the end-to-end delay model...122

Table 14 CoS Mechanisms Overview...125

Table 15 NB and EB settings...132

Table 16 WRED Settings for Business Class...139

Table 17 WRED Settings for Streaming Class...139

Table 18 WRED Settings for Standard Class...140

Table 19 WRED - exponential weighting constant...142

Table 20 MDRR weights... 150

Table 21 WRED Setings for Business Class (ENG-2 GSR) ...153

(9)

Tables

Table 23 WRED Setings for Standard Class (ENG-2 GSR)...153 Table 24 ATM Overhead... 156 Table 25 LLQ bandwidths and ATM...156

(10)

Figures

Figure 1 <Company’s name> network – WAN topology...18

Figure 2 Architecture of CO BA...27

Figure 3 HW configuration of ba2-igw-2...28

Figure 4 HW configuration of ba1-igw-1...29

Figure 5 HW configuration of ba-six-1...29

Figure 6 HW configuration of ba1-p-1 and ba2-p-2...31

Figure 7 HW Configuration of ba2-pe-4...33

Figure 8 HW Configuration of ba1-pe-5...33

Figure 9 HW Configuration of ba1-pe-6 and ba1-pe-7...35

Figure 10 Architecture of CO BB...38

Figure 11 HW configuration of bb1-p-1...39

Figure 12 HW configuration of bb2-p-2...39

Figure 13 HW configuration of bb1-pe-1...40

Figure 14 HW Configuration of bb2-pe-2...40

Figure 15 HW Configuration of bb1-cat-1 and bb1-cat-2...41

Figure 16 Architecture of CO KE...42

Figure 17 HW configuration of ke1-p-1...43

Figure 18 HW configuration of ke2-p-2...43

Figure 19 HW Configuration of ke1-pe-1...44

Figure 20 HW Configuration of ke2-pe-2...44

Figure 21 HW Configuration of ke1-cat-1 and ke1-cat-2...45

(11)

Figures

Figure 23 New Architecture of regional PoPs (7206VXR based)...47

Figure 24 HW Configuration of 10008 in Regional PoPs (ZA, NI, TT, PO)...48

Figure 25 HW Configuration of 10005 in Regional PoP Trencin (TN)...48

Figure 26 HW Configuration of 7206VXRs in Regional PoP...48

Figure 27 OSPF enabled links...53

Figure 28 Layer 2 Frame with 2 MPLS Labels...59

Figure 29 MP-BGP VPN Route Distribution example...63

Figure 30 VPN route distribution using partitioned RRs...64

Figure 31 Route Reflector Redundancy in the <Customer Name> Networks...65

Figure 32 Redundant Route Reflectors with same cluster-id...67

Figure 33 Unique RD per each VPN...71

Figure 34 Unique RD per site for each VPN...72

Figure 35 PE-CE eBGP with unique AS...79

Figure 36 PE-CE eBGP with single network wide AS...80

Figure 37 Internet Access from a VPN using separate CEs...84

Figure 38 Internet Access from a VPN – Single CE (two links in CEred, single link on CEblue)... 86

Figure 39 NAT in CE router... 88

Figure 40 - Traffic Engineering Mechanisms...91

Figure 41 - Traffic Engineering Path Setup...94

Figure 42 - TE FRR Example... 96

Figure 43 - Topology Without Tunnels...99

Figure 44 - R1 Routing Table – No MPLS TE...100

Figure 45 – Topology With TE Tunnels...100

Figure 46 - R1 Routing Table With Autoroute Announce...100

Figure 47 - Forwarding Adjacency Topology...101

Figure 48 - "3" Core Network Architecture...106

Figure 49 - Illustration of Primary and Backup TE Tunnels...107

Figure 50 Various interpretations of the TOS field...114

(12)

Figures

Figure 52 Adaptive jitter buffer...120

Figure 53 - Call admission control...120

Figure 54 LFI to reduce frame delay and jitter...121

Figure 55 Overview of end-to-end delay segments...123

Figure 56 DSCP to EXP mapping...124

Figure 57 DSCP / MPLS Headers...124

Figure 58 QoS mechanisms overview...126

Figure 59 In/Out-contract Marking and Policing (example for Business class) ...130

Figure 60 CAR based In/Out-contract Marking and Policing ...131

(13)

Document Control

Authors:

Change Authority:

Reference Number: EDCS-xxxx

History

Table 1 Revision History

Version

(14)

Document Control

Review

Table 2 Revision Review

Reviewer’s Details Version No. Date

Change Forecast: Medium

(15)

Document Control

Design Acceptance

The signatories below confirm that the design meets the requirements specified. The design is subject to change during or following staging.

CISCO SYSTEMS Slovak Telecom

By:__________________________________ By:_____________________________________

Name: Name:

Title: Title:

(16)

About This Design Document

Document Purpose

The purpose of this document is to outline the Cisco Systems recommended Low Level Design (LLD) for

<Company’s name and Project Name>. It details the physical and logical requirements and how we will accomplish these requirements.

The document is split into following main sections,

• Current Architecture and Network Design

• Planned Services

• Proposed Design and Architecture

• OSS

Note: The above sections may change depending on the customer’s needs

The document provides sufficient detail to derive the device configurations that will be documented in the Network Implementation Plan. Some parameters may be determined during network deployment.

Scope

Please refer to Statement of Work documents for exact definition of project deliverables.

Document Usage Guidelines

The document should be used as a guideline for deriving the necessary information to ultimately create the configurations that allow the network to provide the necessary services. The more theoretical sections should be used in conjunction with the practical sections in order to allow the deployment engineer to understand the service requirements behind the configurations. This will also allow the deployment engineer to take certain decisions when deploying and configuring the network.

As long as the Low Level Design document is in a draft format, it is susceptible to modifications and additions initiated by Cisco Systems or by the customer.

After acceptance of the LLD by the customer, the LLD document is still a living document that will be updated by experiences gained throughout the deployment and testing phases.

(17)

About This Design Document

Assumptions and Caveats

• Based on the input from CRDR ,HLD,SOW and Site Survey write down the necessary assumptions and caveats

• It is assumed the reader is familiar with the <Customer Name> service requirements. Furthermore it is also assumed the reader is familiar with Cisco IOS and has a basic understanding of the network and technologies that will be used to fulfil the customer requirements.

Network Overview

Describe what kind of customer and their core business. Also at a high level explain their current architecture with more details in the following section. This information can be collected from CRD and HLD

Network Topology

WAN Overview

The following figure is provided for illustrative purposes and depicts a high-level view of <Company’s name> network. Picture is simplified for easier understanding of WAN network topology.

Figure 1 <Company’s name> network – WAN topology

Network Infrastructure

Core

If possible provide the details of current core network. The platforms used, kind of links, what routing protocol etc.

Edge

The following types of devices are installed in <Company’s name> network as Provider Edge (PE) routers:

Access

Customer Edge (CE) routers are classical IPv4 routers and will interconnect customer sites with PE routers via leased lines (as described in Error: Reference source not found chapter below). CE routers usually reside in customer premises. CE router can be managed by <Company’s name> or by the customer.

(19)

Traffic Flow and Characteristic

In this section explainand characterize the custoemnr traffic. Explain the load that major pops(or even links) are carrying. What additional traffic is expected with the new deployment.

Existing Services and SLAs

In this section explain the current services that the customer is offering and the SLAs ,if any , associated with these services

(20)

Proposed Network Architecture

In this chapter we highlight the architecture that is being proposed for the customer based on the requirements listed in the CRD. Following chapter would go into the details of how this architecture would be deployed.

Design Considerations

This chapter summarizes the design objectives that have been followed throughout the LLD, and the design rules we have taken to meet these objectives.. Following are the list of these objectives as dictated by the customer

MPLS Network Architecture

Following are just some of the examples. Customize this section based on your customer requirements

• Fast convergence

Fast convergence and network stability are two orthogonal components in any network design. Accurately measuring and interpreting the convergence time in complex topologies is somewhat like rocket science as many factors are involved. Improving the overall convergency by tuning the relevant parameters is a complex task that requires in depth analysis of all side effects (e.g. CPU utilization). We recommend to tune the convergence of routing protocols in a separate project. The scope of this project should be exclusively the optimization of convergency in ST MPLS network, by introducing new features (e.g. Traffic Engineering Fast Reroute) and tuning of routing protocol timers (see OSPF Convergence chapter)

• Network Stability and Scalability

Any routing protocol would scale well, if the routing information is stable. Stability of backbone IGP was one of the main concerns in the former ST network. For this reason the following changes have been made during previous project phases :

o Offload of any customer routes from backbone OSPF into BGP.

o Subnet aggregation of unstable leased-line connections and redistribution as static route into BGP.

o Subnet aggregation the of dial-up customers with fixed addresses on VPDN tunnel concentrator, and redistribution as static routes into BGP

• Network resilience

ST MPLS network has been designed for high availability. Physical and logical design ensures that primary and backup path exists between any two core routers. Core routers are equipped with primary

(21)

and backup route processors. Resilient connections between regional PoPs and Core locations will be rolled out in project phase 8A.

• Network security

Cisco has implemented best-practices security mechanisms on ST routers to protect the network. Customer security and managed firewall service was not in the scope of any Cisco project.

• Simplicity

ST MPLS network design is clean and simple to understand. Any feature or design element that would increase network complexity - but have a limited overall benefit - has been avoided. ST has decided to clean-up the existing IP addressing scheme and migrate from multi-area OSPF into single-area design.

• MPLS

LDP has been chosen for label distribution in ST MPLS network. LDP is enabled on all core links (P-P, P-PE, P-RR, P-iGW).

Quality-of-Service

• Traffic prioritisation

The following Classes of Service are implemented in the <Customer Network> network: Voice, Streaming, Business, Standard. Each class has different QoS attributes and guaranteed (configured) bandwidth that cannot be utilised by any other class during congestion periods.

Backbone links must be provisioned with sufficient capacity for each of the classes! • Flexibility

Modular QoS CLI allows to map traffic flows of <Customer Name> customers in one of the Classes of Service. Such classification and marking is extremely flexible (different customers can map different applications in any of the classes), but requires the understanding of traffic profiles (e.g. SMTP or any other data traffic must not be mixed with delay-sensitive VoIP packets).

• Scaleable implementation

The customer-specific QoS configuration is implemented on CE routers – QoS configuration template on PE and P devices will remain stable and the same for all ST customers. VPNSC shall be used for accurate provisioning of QoS parameters on access (PE-CE) connections.

MPLS/VPN Services

• Flexible and scalable managed IP VPN service

Achieved through MPLS technology, properly applied MPLS/VPN functionality and VPNSC management system1_.

• Service resilience

Resilient MPLS backbone, redundant route reflectors and the possibility of fully resilient connectivity scenarios on access-layer (2CE-2PE) in all PoPs, are necessary building blocks for high availability MPLS/VPN service.

• End-to-end Quality of Service

Achieved through the use of various Diffserv mechanisms: classification, marking, policing, queuing and dropping. QoS is implemented on access layer and in the backbone.

(22)

• Internet Access for MPLS/VPN customers

Internet access from the MPLS/VPN is provided for customers with such requirement. For security reasons we only recommend to implement the Internet connection through a dedicated CE router and dedicated access-layer circuit (see chapter for detailed description)

• Security

Assuming that MPLS core is secure, the MPLS/VPN solution offers same level of security as the traditional layer-2 VPN networks.

Detailed Naming and Addressing Specifications

BGP AS Number

AS number for <Customer Name> MPLS network and inter-domain routing is <AS number>

<Customer Name>

Routers

Naming convention for backbone routers has been defined by <Customer Name> as part of current deployment.

Explain in detail the nomenclature used by the customer or will be used by the customer

Customer Edge (CE) Routers

Naming convention for CE routers shall in addition to backbone naming scheme incorporate the customer name or customer ID.

DNS domain name

The domain name for <Customer Name> networking equipment shall be <domain name>

IP Addressing

Explain in detail the IP addressing scheme in customer’s network

Loopbacks

The following address block is used for numbering of Loopback02_{interfaces in}_{<Customer Name>}_MPLS network:

X.X.X.X.

Give any additional details as it relates to loopback addresses

(23)

Backbone Links

Backbone connections are numbered with IP addresses from the following subnets: X.X.X.X

Explain in detail how these subnets would be allocated to different links

Existing Routers

In this section explain any renumbering of ip addresses that might be needed for any existing infrastructure

MPLS/VPN Access Connections

<Customer Name> has allocated the address pool

x.x.x.x/y

for numbering of MPLS/VPN access connections.

Internet Access Connections

<Customer Name> has allocated the following address pool for numbering of access connections for Internet customers:

x.x.x.x/y

IP-SLA

Depending on how IP-SLA is deployed , explain addressing scheme that would be required

MPLS/VPN Attributes

VPN naming and addressing is described by four attributes. These are the VRF name, RD, RT and SOO. Detailed naming of MPLS/VPN attributes are given in the NMS document (see Error: Reference source not found)

VRF Name

The VRF name is locally significant on the PE router. Service providers that provision the MPLS/VPNs manually (via CLI on router console) are advised to use a VRF name that is recognisable across the whole network in order to aid troubleshooting. The name should identify the predominant function of the CEs

(24)

connected to the VRF, this can be a word to identify the customer or, in the case of a VRF that is shared by multiple customers, the type of service offered by the attached CEs.

Explain how VRF name would be configured. Also explain if any provisioning tool like ISC is being used

RD

Explain how RD is being assigned. Also explain if any provisioning tool like ISC is being used

RT

RTs define the VPNs, the value is therefore significant across the whole network. A different RT is required for each VPN, hub-and-spoke VPNs can be considered as 2 uni-directional VPNs and therefore need 2 RTs if bi-directional routing is required.

Explain how RT is being assigned. Also explain if any provisioning tool like ISC is being used

SOO

SOO is required in order to provide loop avoidance on multi-homed sites. The same SOO attribute should be added to every routing update originating on the multi-homed site. Routes received by a VRF carrying a SOO also exported by the VRF should be filtered out so that they are not imported. Only multi-homed sites require the SOO attribute so SOO values will only be allocated as required.

Explain how SOO is being assigned. Also explain if any provisioning tool like ISC is being used

BGP AS Numbers

When peering with a customer CE router, the customer can use his registered ASN if he possesses one. If not, private ASNs (64512 to 65535) can be used on the CEs.

The same ASN can be used for all the sites of a VPN to conserve the number of ASNs; this is recommended and also allows for VPNs that have more than 1024 sites. The “as-override” is used on the PEs in order to reuse the same ASN for all the sites.

(25)

Deployment Guidelines

In this chapter we’ll exaplain you how to deploy the architecture proposed in the previous chapter

Physical Network Design

The content is this section is only for reference purpose. You need to add details specific to your own customers. This is confidential information In no way should this information be shared with non-cisco folks

Layer-2 Transport Media

The following summarizes the physical layer transport in ST MPLS network.

• Inter-site connectivity

o POS STM-16 over DWDM is used to interconnect: Core COs BA, BB and KE

7304 SIX router and P router in BA.

o POS STM-1 over SDH interconnects regional PoPs (PEs) with core COs (Ps)

• Intra-site connectivity

o Back-to-back POS STM-16 is used for connectivity between P and collocated IGW routers in BA PoP

o Back-to-back GE connections are deployed for the following device pairs:

10008 (PE) -12410 (P) ; Bratislava, Banska Bystrica, Kosice

7600 (PE) -12410 (P) ; Bratislava

ERX (DSL) -12410 (P) ; Bratislava

10008 (PE) -12012 (P) ; Banska Bystrica

o Back-to-back POS STM-1 is used for the following links: 12406 (iGW) -12008 (iGW) ; Bratislava (2 x STM-1)

(PE) - (P) ; Any other collocated PEs in central offices

7204VXR (RR) -12xxx (P) ; BA & BB

o Switched FE connections are used to connect existing ST IP (CE, NAS) routers that are cascaded behind new PEs. Layer 2 switches (Cisco 4503/3550-24) are used for port aggregation.

(26)

Central Office Bratislava [BA]

The chapters below depict the architecture of the three central offices and a typical implementation of a regional PoP in ST MPLS network.

Central Office in Bratislava is a major hub in ST network, because of the largest concentration of customer base in that area. For this reason, ST decided to build the BA CO resiliently and with powerful routers. The devices in BA CO can be logically grouped into four layers: Peering, Core, Aggregation and Access. Two Firesections

The Bratislava CO will be divided into two physically separated firesections (1 and 2). Main components of peering, core and aggregation layer will be deployed in different locations to achieve network resilience in case of a major disaster. Customers can be dualhomed to PE routers in both firesection in order to provide them a maximum of redundancy.

(27)

Figure 2 Architecture of CO BA

Peering Layer

Internet Gateway Routers (ba1-igw-1, ba2-igw-2)

Two routers (Cisco 12406 and Cisco 12008) will be installed in BA CO for IP connectivity between ST MPLS network and:

• Downstream ISPs (eg. local ASP - Application Service Provider) that pay for transit service to ST – these are in fact customers of ST.

• Upstream ISPs (eg. Deutsche Telekom, UTA) that provide global Internet reachability for customers of ST.

Each iGW will have a POS STM-16 back-to-back connection with a different P router. Interconnections with ISPs can be either POS STM-1 or E3 leased lines.

Both iGWs are equipped with powerful route processors (primary and redundant) that can handle large number of BGP sessions, and will have installed sufficient amount of memory to carry one or more copies of full Internet routing table.

(28)

Both iGWs will inject a BGP default route towards PE routers. A PE router will select the default route based on IGP distance to originating iGW, and eventually send all Internet traffic to the closest iGW. However, this iGW may not be the best exit point for a given Internet destination, so the packets would have to be re-routed to the neighbouring iGW to be delivered to the upstream ISP. For this reason, two POS STM-1 back-to-back links are installed between iGWs. No other traffic (eg. packets between two ST PoPs) are passing these two links.

An alternative solution would be to download full Internet routing table to any PE router, which can in turn deliver the Internet traffic to the right iGW. This would result in more optimal traffic flows across ST core, and enable “distributed” peering system, with possibility of connecting ISP circuits in any PoP. Assuming that BGP dampening is enabled on border routers, and number of routes that can be accepted from any ISP is limited3_{, the major drawback is memory requirements (min. 256 MB) on all PE routers due to large} number of routes in the global Internet routing table.

Figure 3 HW configuration of ba2-igw-2

3_{It is a good practice to define the maximum number of prefixes that can be accepted from any eBGP peer. This is for} example to prevent the situation where a peering partner at SIX advertises the full Internet routes to ST.

4 x POS STM-1 1 x POS STM-16 8 x POS STM-1 6 x E3 GRP Redundant GRP CSC SFC CSC Alarm Alarm SFC SFC Power Power P router Upstream/Downstream ISP 0 1 2 3 4 5

12406

(29)

-Figure 4 HW configuration of ba1-igw-1

SIX Internet Gateway Router (ba-six-1)

One 7304 router (ba-six-1) is collocated at SIX premises, for mutual and free-of-charge exchange of customer traffic between peering partners at Slovak Exchange Point. ba-six-1 router is attached to the SIX switch with a GE interface, and interconnected with ST core router ba2-p-2 via a POS STM-16 connection.

Figure 5 HW configuration of ba-six-1

Resiliency in Peering Layer

It is recommended and a good decision to terminate at least one upstream ISP connection on each iGW. This will protect from failures on a single peering circuit, and/or major failure of a single peering router

-1 x POS STM--16 P router

Peering partners @ SIX 4 2 0 5 3 1 NSE100 GE0 GE1 7304 4 x P O S S T M -1 - -C S C 0 C S C 1 1 x P O S S T M -1 6 4 x P O S S T M -1 -G R P R e d u n d an t G R P P o w er P o w er

1

2

0

8

P router Upstream/Downstream ISP 0 1 2 3 4 5 6 7

(30)

(either ST’s or the one of upstream ISP). Having two redundant Internet connections on separate routers will also permit software and hardware upgrades on iGWs without long downtimes.4

The two iGWs distribute BGP routes (default route and full Internet table if required) to other BGP neighbors in ST network via two redundant route reflectors.

The Internet connectivity scheme with physically separated IGW routers protects against the failure or major disaster in one of the Bratislava firesections. Internet connectivity will remain through the backup upstream ISP in the other firesection.

There’s currently a single router installed at SIX premises. If this router or a link between ba2-p-1 and SIX router fails, the direct connectivity with SIX participants will be lost. Nevertheless, this does not represent a single point of failure, because the peering partners’ networks can be during failure reached5_across upstream ISPs.

Core Layer

MPLS P Routers (ba1-p-1, ba2-p-2)

ST has selected two Cisco 12410 routers for MPLS P devices in Bratislava CO. These P routers do not perform any aggregation layer services (eg. termination of customer links, or peering circuits, BGP routing, etc.) P routers are also not routing the IP packets across ST core; the only6_{task of P routers is to label} switch the MPLS frames through high speed links, respecting the queuing and dropping attributes which are encoded in the EXP bits of MPLS labels.

Each P router links the following devices:

• Remote P router - GSR. POS STM-16 links interconnect the P routers into a high-speed backbone. Underlying technology is DWDM.

• Remote PE. Regional PEs in remote PoPs interconnect with P routers via POS STM-1 links.

• Collocated PEs are attached with P routers either via a back-to-back POS interfaces, or using a GE technology in a back-to-back mode.

4_{A short downtime will occur because of eBGP convergence throughout the Internet.}

5_{Most likely this would introduce higher RTT and jitter, and increased load on generally very expensive transit} connections with upstream ISPs.

(31)

Figure 6 HW configuration of ba1-p-1 and ba2-p-27

Resiliency in Core Layer

Dual triangle topology of ST core network is resistant to failures on a single P-P link. When a P-P link fails, or when a port on line card fails, the transit traffic between the two P routers can be rerouted across longer path around the core ring. This should not be very frequent event, also because of layer-2 resiliency built in DWDM ring. Nevertheless, a failure on P-P link has to be considered, because it would affect the cumulative backbone throughput and quality of MPLS/VPN services.

The ST core network is also protected against node failures in Bratislava, Banska Bystrica and Kosice. If one node fails, the traffic is rerouted across the second triangle.

The higher RTT and jitter because of increased number of hops is not questionable, because there’re currently only four P routers in the core ring, and they’re linked with high-speed 2.5 Gbps connections. However, if the core links are well utilised (eg. 70-80%) during normal network operation (although that is not expected in ST MPLS network very soon), the failure on one P-P link might cause temporary

congestions and packet loss on the alternate path. This can be dangerous if for example the SLAs of Business data class guarantee certain max. % of packet loss at any time. In this case the workaround 7_{New four-port STM-16 LC will be installed in ba1-p-2 during Phase 8A Project. Three-port GE LCs will be replaced by} new four-port Eng3 LCs. This will allow proper QoS implementation on P-PE connection (on GSR side).

4 x P O S S T M -1 6 4 x P O S S T M -1 6 -4 x G E -C S C 0 8 x P O S S T M -1 G R P R ed u n d a n t G R P 4 x G E 1 2 4 5 6 7 8 9 C S C 1 S FC 1 S FC 2 S FC 3 S FC 4 A lr m 0 A lr m 1 S FC 0 Power

12410

Power

P, IGW and SIX router

RR, MPE, Regional PEs, 7513 PE router Collocated PEs 0 P router 8 x P O S S T M -1 3

(32)

solution may be to overprovision the class bandwidth for Business data class, on account of under provisioned class bandwidth in Standard class.

Aggregation Layer

10008 MPLS PE - Concentration of Leased Line Customers (ba1-pe-5, ba2-pe-4)

Two ESR 10008 routers are installed in Bratislava CO for termination of leased-line customer connections (MPLS/VPN and Internet customers) and linking the non-upgraded regional PoPs of ST with MPLS core. For this, the 10008s are equipped with 24 E1 ports and 6 POS STM-1 ports.

The 10008 PEs are connected to P routers with two GE uplinks in a back-to-back mode, as shown on the following table. LX long haul GBICs connected via single mode dark fiber (10/9 micron) are used for longer distances (< 6,2miles/10 km) between firesections.

Table 3 PE-P Connectivity in CO BA

PE Device PE Name Primary P Backup P

ESR 10008 ba1-pe-5 ba1-p-1 ba2-p-2

ESR 10008 ba2-pe-4 ba2-p-2 ba1-p-1

7609 ba1-pe-6 ba1-p-1 ba2-p-2

(33)

Figure 7 HW Configuration of ba2-pe-48

Figure 8 HW Configuration of ba1-pe-59

8_{New 10008 chassis with 6xPOS STM-1LC, 24xE1LC and two half-slot GE LCs will be installed in BA firesection 2.} One 6xPOS STM-1 LC will be taken from current ba-pe-4 router. One 8xE3 LC will be taken from ke1-pe-1 router. 9_{One 8xE3 LC will be taken from bb1-pe-1 router.}

2 4 x E 1 -P R E B P R E A 6 x P O S S T M -1 1 2 3 4 6 P ri m a ry P E M R ed u n d an t PE M

1

0

8

Customers + Regional PoPs (CEs) Backup P Primary P + 6 x P O S S T M -1 2 4 x E 1 Backup P 1 x G E 1 x G E 8 7 -5 8 x E 3 1 x G E 2 4 x E 1 1 x G E -P R E B P R E A 6 x P O S S T M -1 1 2 3 4 6 7 8 P ri m a ry P E M R ed u n d an t PE M

1

0

8

Customers + Regional PoPs (CEs) Backup P Primary P 6 x P O S S T M -1 2 4 x E 1 5 8 x E 3

(34)

7609 MPLS PE - Collocation of Server Farms (ba1-pe-6, ba1-pe-7)

Two 7609 routers in Bratislava CO provide Internet connectivity for collocated server farms of ST customers. Moreover ST IP (CE, NAS) routers is directly connected via FE. Currently each 7609 is equipped with the following modules:

• one 48 port 10/100 catalyst module

o with daughter Distributed Forwarding Card - DFC

• one OSM 4-GE module

• two supervisor SUP2 modules (primary and redundant) each with

o PFC2 and MFC2

o 2 x GE ports on MFC2 - these are active on redundant SUP2 too.

• one Switch Fabric Module – SFM2

(35)

Figure 9 HW Configuration of ba1-pe-6 and ba1-pe-710

10008 / 7206VXR MPLS PE - Regional (remote) PoPs

The following regional PoPs are attached to Bratislava core PoP: Trnava, Nitra, Trencin, Senica, Topolcany, Trencin, Levice, Nove Zamky and Dunajska Streda.

Depending on the PoP location, there will be either one 10008 and one 7206VXR PE router installed, or two 7206VXR PE routers. Each regional PoP will be dualhomed to both P routers in Bratislava via POS STM-1 links.

Please find more details of a typical regional PoP architecture in chapter Regional PoPs

7206VXR - MP-BGP Route Reflectors

Two MP-BGP RRs are hosted in Bratislava CO. One 7204VXR IPv4 RR (ba1-irr-1) is connected with the collocated ba1-p-1 router with a single POS STM-1 interface. The other VPNv4 RR (ba2-vrr-2) is connected with the collocated ba2-p-2 router. There’s no need for redundant connection with a second P router, because the resiliency is achieved on BGP layer (two RRs).

10_{New 16 port GE module will be installed in ba1-pe-6 and ba1-pe-7 durin Project Phase 8A}

S FM 2 ( S w it ch F ab ri c M o d u le ) -S U P 2 R ed u n . S U P2 4 8 x 1 0 /1 0 0 R J-2 1 (D FC ) PS

7609

_RedundantPS CE/NAS Backup/Primary P 2 x G E 2 x G E (P FC 2 + M S FC 2 )

* Linecards only in slots 3, 4, 6-9

(P FC 2 + M S FC 2 ) 1 2 3 5 7 8 9 O S M 4 x G E

-PIX Firewalls (BA Datacenter) + NAS (5850)

1 6 x G E NAS (5850) 4 6

(36)

The 7204VXR RR will not forward any customer traffic.

75xx - BA-Border1, BA-Border2

The former BA-Border1 router in Bratislava PoP has been been upgraded to support MPLS/VPN technology. It is now used as PE device in new ST MPLS network (ba1-pe-2). The former BA-Border2 router has not sufficient hardware capabilities to support MPLS/VPN services. It will be used as CE router instead.

As per MPLS/VPN terminology, any remote PoP connected to ba1-pe-2, represents a MPLS/VPN CE router in the MPLS network.

Resiliency in Aggregation Layer

Since the core layer in centeral offices consists of two P routers, the aggregation layer routers will be resiliently connected with the rest of the ST network. When the port on P or PE router fails, or if the whole P router goes down, the traffic would be rerouted via backup PE-P uplink as per OSPF calculation.

If for any reason it is not possible to interconnect a PE router with both P devices, service resiliency can still be achieved on access layer: with two CE routers interconnecting with two PE routers via two separate connections.

Access Layer

Customer Edge – CE Routers

There are two type of CE routers connected to ST PE routers: customer managed and ST managed CE devices.

Cisco recommends to limit the number of various platforms and interfaces, in order to minimize operational and management costs. For example:

• Low-end CE router: 800, 1700 and 2600 series

• Mid-range CE router: 3600 series

• High-capacity CE router: 7200 (or more powerful device when required)

Customer managed CE router can be any device, which supports the leased line technology and protocols offered by ST.

Existing ST IP Access Connections

In theory, ST could re-home all customer leased lines from CE routers to MPLS PEs, but this task is already a huge project, requires lots of coordination with customers.

A more elegant approach has been chosen by ST. The former distribution layer was cascaded behind the MPLS PEs, in order to leave hundreds of customers’ leased lines intact. In MPLS/VPN terminology, the old distribution layer routers have become CE devices; that’s why ST has renamed them tinto ‘CE’ routers.

(37)

The following routers in Bratislava PoP are connected with a single FE back-to-back connection to the 7609 PEs: ba2-ce-1, ba2-ce-2, ba2-ce-3, ba2-nas-1, ba2-nas-2.

New 5850 access servers will rolled out in a separate project. Two logical separated access servers (ba2-nas-3 and ba2-nas-4) on the same physical device will be installed in Bratislava firesection 2. They will be dualhomed to the 7609 PEs via two GE uplinks.

Alternative to migration of existing leased-line customers

ST could progressively turn the old IP routers into MPLS PEs and attach them directly to P routers. For this, the old 7206 and 3640 routers shall be SW upgraded with a more recent (and stable) IOS release, which offers required MPLS/QoS functionality on given hardware.

Assuming that CPU utilisation on existing CE routers is not problematic, this might be a more appropriate alternative than migration of hundreds of leased lines to the new platforms.

Resiliency in Access Layer

Having two PE routers in each regional PoP, and two resilient connections between regional and core PoP provides the possibility to dualhome access devices to both PE routers. Redundant L2 access switches in core PoPs Banska Bystrica and Kosice (4503) and regional PoPs (3550-24) are used to aggregate FE connections from access devices.

(38)

Central Office Banska Bystrica [BB]

New 12410 P and 10008 PE router will be installed in a separate location (firesection) in Banska Bystrica. The currently installed 10005 router will be moved to regional PoP Trencin, while the existing 10008 router remains in the current location.

New 4503 aggregation switches will be deployed in one firesection to connect existing ST IP devices and new customers via FE. ST IP devices will be dualhomed to switches via back-to-back FE links, in cases where additional LAN interfaces are available (e.g. NAS).

The architecture of CO BB is depicted on the following figure.

(39)

Figure 11 HW configuration of bb1-p-111

Figure 12 HW configuration of bb2-p-212

11_{New 1 port STM-16 and 4 port GE LC will be installed in bb1-p-1 during Phase 8A Project. 1xGE LC will be removed} 12_{New installed during Phase 8A Project}

-C S C 0 1 6 x P O S S T M -1 PR P R ed u n d a n t PR P 4 x G E 1 2 3 4 5 8 9 C S C 1 S FC 1 S FC 2 S FC 3 S FC 4 A lr m 0 A lr m 1 S FC 0 Power 12410 Power P routers

Regional PEs, 7507 PE router BB Aggregation 4 x P O S S T M -1 6 0 1 -6 7 - -8 x P O S S T M -1 1 x P O S S T M -1 6 8 x P O S S T M -1 -CSC 0 1 x P O S S T M -1 6 G R P R e d u n d an t G R P 0 2 3 4 5 6 7 8 9 CSC 1 SFC 1 SFC 2 A lr m SFC 0 Power A 12012 Power B [BB] P router Regional PEs BB Aggregation 1 1 ₁2 1 1 x P O S S T M -1 6 1 0 4 x G E -

(40)

-Figure 13 HW configuration of bb1-pe-113

Figure 14 HW Configuration of bb2-pe-214

13_{Two new half-slot and one single GE LC will be installed in bb1-pe-1 during Phase 8A Project. The second single slot} GE LC will be moved from existing 10005 to bb1-pe-1. One 8x E3 LC moved to ba1-pe-5 router.

14_{New 10008 will replace existing 10005 (moved to Trencin) during Phase 8A Project}

1 x G E -PR E B PR E A 6 x P O S S T M -1 1 6 7 8 Pr im a ry PE M R ed u n d an t P E M

1

0

8

Customers + Regional PoPs (CEs) Primary P + Backup P 2 4 x E 1 3 5 2 4 x E 1 1 x G E -1 x G E 2 1 x G E

ST IP devices (CAR, Dist) via 4503

8 x E 3 4 2 4 x E 1 P R E B P R E A 6 x P O S S T M -1 1 3 Pr im ar y P E M R ed u n d an t P E M

1

0

8

Customers + Regional PoPs (CEs)

Backup P Primary P

8 x E 3 4 5 8 1 x G E 7 1 x G E -1 x G E 1 x G E 6 5

(41)

-Figure 15 HW Configuration of bb1-cat-1 and bb1-cat-215

15_{New installed during Phase 8A Project}

1

4503

SUP IV 2 x GE

2 6 x GE

3 48 x FE ST IP devices (CAR, Dist)

(42)

Central Office Kosice [KE]

New 12410 P and 10008 PE router will be installed in a separate location (firesection) in Kosice. ST IP devices will be migrated to new installed 4003 aggregation switch in current location. Another switch will be installed in the new location (firesection 2). Both switches will be dualhomed to 10008 PE routers via GE uplinks.

The architecture of CO KE is depicted on the following figure:

(43)

Figure 17 HW configuration of ke1-p-116

Figure 18 HW configuration of ke2-p-217

16_{New 1 port STM-16 and 4 port GE LC will be installed in ke1-p-1 during Phase 8A Project} 17_{New installed during Phase 8A Project}

-C S C 0 1 6 x P O S S TM -1 PR P R ed u n d an t PR P 4 x G E 1 2 3 4 5 8 9 C S C 1 S FC 1 S FC 2 S FC 3 S FC 4 A lr m 0 A lr m 1 S FC 0 Power 12410 Power P routers

Regional PEs, 7507 PE router KE Aggregation 4 x P O S S T M -1 6 0 1 -6 7 - -1 x P O S S T M -1 6 8 x P O S S T M -1 -4 x G E -CSC 0 1 x P O S S T M -1 6 -G R P R e d u n d a n t G R P 4 x P O S S T M -1 0 2 3 4 5 6 7 8 9 CSC 1 SFC 1 SFC 2 A lr m SFC 0 Power A 12012 Power B [ke_p_1] P router Regional PEs KE Aggregation 1 1 1 2 1 1 x P O S S T M -1 6 1 0

(44)

-Figure 19 HW Configuration of ke1-pe-118

Figure 20 HW Configuration of ke2-pe-219

18_{Four new half-slot GE LCs will be installed in ke1-pe-1 during Phase 8A Project. One 8x E3 LC moved to ba2-pe-4.} 19_{New installed during Phase 8A Project}

1 x G E -PR E B PR E A 6 x P O S S T M -1 1 6 7 8 Pr im a ry PE M R ed u n d an t P E M

1

0

8

Customers + Regional PoPs (CEs) Primary P + Backup P 2 4 x E 1 3 5 1 x G E -1 x G E 2 1 x G E

4 8 x E 3 -1 x G E -PR E B PR E A 6 x P O S S T M -1 1 6 7 8 Pr im a ry PE M R ed u n d an t P E M

1

0

8

Customers + Regional PoPs (CEs) Primary P + Backup P 2 4 x E 1 3 5 2 4 x E 1 1 x G E -1 x G E 2 1 x G E

8

x

E

3

(45)

Figure 21 HW Configuration of ke1-cat-1 and ke1-cat-220

1

4503

SUP IV 2 x GE

2 6 x GE

3 48 x FE ST IP devices (CAR, Dist)

(46)

Regional PoPs

During transition phase of ST IP network to MPLS/VPN technology, the old 7206 (CAR/POP), 3640 (CAR) and AS5300 (NAS) routers have been cascaded behind 7206VXRs as CE devices. Each 7206VXR router have been attached with a single POS STM-1 uplink to the closest P router.

In the scope of phase-2 of MPLS/VPN project (deployment of 17 new PoPs) ST decided to improve the design of remote PoPs. The design change introduces a new Catalyst 3550 that will aggregate local LAN-attached devices. This will allow direct attachment of old STIP routers to the new PE router.

Connection between a Catalyst and PE router will be configured with encapsulation dot1Q and several logical sub-interfaces on PE router. Each sub-interface can be assigned to a different VRF, or to the global routing table, which makes deployment of co-located CEs or customers’ web servers straightforward. Number of VLANs in the Catalyst switch will correspond to number of VRFs implemented on the PE router (+1 for global RT).

Part of Project Phase 8A is to achieve higher service availability in the regional PoPs by deploying second PE routers.

Two groups of Regional PoP will be deployed:

• A new C10k PE router will be implemented next to the current C7206VXR in 5 PoPs: (Zilina, Nitra, Trnava, Presov, Trencin)

• A new 7206VXR will be implemented next to the current C7206VXR in 17 PoPs:

(Senica, Topolcany, Dunjaska Streda, Nove Zamky, Prividza, Martin, Provazska Bystrica, Liptovsky Mikulas, Levice,Spisska Nova Ves, Bardejov, Poprad, Humenne, Michalovce, Roznava,Lucenec, Zvolen)

The following drawing shows the new design for the remote PoPs where a new 10k PE router will be deployed; Nitra PoP has been taken as a typical example.

(47)

Figure 22 New Architecture of Regional PoPs (10k based)

The following drawing shows the new design for the remote PoPs where a new 7206VXR PE router will be deployed; Senica PoP has been taken as a typical example.

(48)

48

Figure 24 HW Configuration of 10008 in Regional PoPs (ZA, NI, TT, PO)21

Figure 25 HW Configuration of 10005 in Regional PoP Trencin (TN)22

Figure 26 HW Configuration of 7206VXRs in Regional PoP

22_{Two new half-slot GE LCs will be installed in tn-pe-2 (moved from BB PoP) during Phase 8A Project}

7 2 0 6 V X R C7200-I/O-2FE/E PA-2E3 0 1 PA-POS-OC3SMI 2 3 PA-8T-X21 PA-MC-8E1/120 4 5 6 Uplink to P router Customer CEs 1 x G E -PR E B PR E A 6 x P O S S T M -1 1 6 7 8 P ri m ar y P E M R ed u n d an t P E M

1

0

8

Customers + Regional PoPs (CEs) Primary P + Backup P 2 4 x E 1 3 5 2 4 x E 1 1 x G E -2

4 8 x E 3 2

(49)

(50)

-Hardware/Software Release Table

The following table summarizes the IOS releases for different platforms in ST MPLS network.

Table 4 Software Release Table

Device Role in ST MPLS network IOS release Image Name

12xxx-GRP existing P, iGW 12.0(25)S2 gsr-p-mz.120-25.S2 12xxx-PRP new P c12kprp-p-mz,120-25.S2 1000x PE 12.0(25)S1 c10k-p10-mz.12.0-25.S1 7609 PE <tbd> <tbd> 7304 SIX <tbd> <tbd> 7204VXR RR 12.0(25)S2 c7200-p-mz.120-25.S2 7206VXR PE 12.1(11b)E12 c7200-p-mz.12.1-11b.E12 2620XM SAA 12.2(8)T5 c2600-is-mz.122-8.T5

4503 Aggregation Switch 12.1(19)EW1 cat4000-i9s-mz.121-19.EW1

3550-24 Aggregation Switch 12.1(9)EA1c cc3550-i9q3l2-mz.121-9.EA1c

New Engine 3-based 4 port GigE linecards (4GE-SFP-LC, aka “Tetra”) will be implemented in 12012 and 12410 P routers in central offices. An IOS upgrade to 12.0(25)S is required to support this new hardware. 12.0(25)S is the first release supporting this new linecard.

Apart from the new hardware, which is the main factor for the IOS upgrade, some of the IOS releases in ST's network are vulnerable to Denial of Service (DoS) attacks. Refer to the following URL for more information : http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml

The core release 12.0(25)S2 is the third maintenance release of 12.0(25)S and should be deployed after as much as possible testing (during staging phase) on all 12xxx core routers and 7204VXR routers (acting as BGP RRs). Due to IOS bug CSCec57264, the 12.0(25)S2 release is not avilable for 1000x routers (already running 12.0(25)S1). 1000x routers should be upgraded to a later maintenance release of 12.0(26)S. The new edge release 12.1(11b)E12 includes several bug fixes compared to the currently used 12.1(11b)E4b. It should be deployed on 7206VXR PE routers in order to improve stability and to fix vulnerability.

Once satisfied, the next step should be to deploy the code on one or two devices in a redundant and non-critical area of the network for one week pilot phase. During this period, ST should monitor the status of these devices to insure successful deployment The code should then be rolled out in a controlled and logical fashion.

From a strategic standpoint, Cisco recommends to use as few different IOS releases as possible. Using just one IOS release across all platforms is sometimes not achievable, due to the differences in HW architecture and feature requirements. Nevertheless, deploying 12.0(25)S2 on two platforms will be a first step towards the limitation of different IOS releases in ST’s network.

In the medium term (3 to 6 months from now), Cisco recommends to do a new IOS evaluation. The aim of this evaluation should be the definition of a long-term IOS strategy for ST’s network. The IOS strategy

(51)

highly depends on the network evolution concerning new features and hardware deployments. Therefore it should be covered by ongoing Cisco Network Optimization Support (NOS).

(52)

Logical Network Design

IGP Routing – (OSPF or ISIS)

OSPF is a link state routing protocol. It is called as such because it sends link states advertisement (LSA) to all the routers within the same hierarchical area. All the OSPF routing information is passed within these LSAs. After the routers receive that information they run the SPF algorithm to calculate the shortest path to each destination.

When an SPF router powers up all the routing protocol data structures are initialised and then the process waits for the interfaces to be functional. Once the interfaces are functioning the devices use the OSPF hello protocol to establish neighbourships. Once the hello exchange has finished and the neighbourship is established, hello packets are used as keepalives to identify which devices are active. When the link state databases of two neighbours are synchronised, they are said to be adjacent. Distribution of routing information is only performed between adjacent routers.

Each router sends periodically LSAs and also when a router's state changes. The OSPF database contents are compared with the received LSAs to identify possible topology changes.

The following is the generic OSPF router configuration. !

router ospf 1

log-adjacency-changes passive-interface Loopback0 network x.x.x.x y.y.y.y area 0 !

The Role of OSPF in

<Customer name>

MPLS network

The <Customer name> MPLS network requires an underlying Interior Gateway Protocol (IGP) to be enabled for the following reasons:

• BGP next-hop reachability.

• Fast convergence after failure of backbone node or core link.

(53)

<Customer name> is already running OSPF in its current network. Therefore <Customer name> is very familiar with OSPF operation, and has gained lots of experiences in OSPF troubleshooting. <Customer name> has therefore requested to preserve the OSPF as IGP in current MPLS network. The choice of OSPF is a very good one as it is standardised, scales well and converges quickly.

OSPF is responsible for interior routing only ! It is not used to carry any customer addresses or linksNetwork addresses of the following links are carried in the OSPF LSAs:

• backbone P-P links

• distribution layer PE-P links

• loopback0 interfaces

• RR-P links

• CE, NAS connections*

Figure 27 OSPF enabled links

In addition to backbone links, the subnets allocated to NMS VLANs and VPNSC LAN are redistributed in the backbone OSPF as connected/static routes. This is required to establish connectivity between NOC sites and P routers, which do not run BGP. <Use the above paragraph if you are not using an out of band connection for management purposes>

OSPF Areas

Single area or Multiarea OSPF would be implemented in the <Customer Network> network. This decision is based on:

• Give reasons here. Also discuss in this sections how you are going to number OSPF areas

• Discuss in detail the max number of routers that would there in an area. Talk about the scale numbers of ABRs, ASBRs

CAR 3640 POP 7200 PE 10008 Regional PE 7206VXR Loop Loop Loop Loop

Loop Loop Loop

P GSR PE 7609 P GSR Loop NAS 5800 Loop OSPF Area 0 Loop iGW GSR Peering circuits D ia lu p u se rs Le as d l in e cu st om er s E xi st in g L L cu st om er s E xi st in g L L cu st om er s D ia lu p u se rs S er ve r fa rm s LL c u st om er s Regional NAS 5300 RR 7200VXR Loop

(54)

OSPF Authentication

It is possible to authenticate the OSPF packets such that routers can participate in routing domains based on predefined passwords. By default, a router uses a Null authentication, which means that routing exchanges over a network are not authenticated. Two other authentication methods exist: Simple password authentication and Message Digest authentication (md5). Authentication does not need to be set, but we strongly recommended for security purposes. And we are recommending MD5 as the authentication method since it is provided higher security than plain text authentication method.

Message Digest Authentication is a cryptographic authentication. A key (password) and key-id are configured on each router. The router uses an algorithm based on the OSPF packet, the key, and the key-id to generate a “message digest” that gets appended to the packet. Unlike the simple authentication, the key is not exchanged over the wire. A non-decreasing sequence number is also included in each OSPF packet to protect against replay attacks.

This method also allows for uninterrupted transitions between keys. This is helpful for

administrators who wish to change the OSPF password without disrupting communication. If an interface is configured with a new key, the router will send multiple copies of the same packet, each authenticated by different keys. The router will stop sending duplicate packets once it detects that all of its neighbors have adopted the new key. Following are the commands used for message digest authentication:

interface <interface type-number>

ip ospf message-digest-key keyid md5 <key> Router ospf 19

area <area-id> authentication message-digest

Loopback Addresses

Each of the OSPF speakers has a Loopback address configured. These are used to force stability of the routers OSPF ID. These loopback addresses are in OSPF passive mode to optimise the routing process.

OSPF Area Summarization

Discuss the details of summarization plans if any

OSPF Costs

• Discuss here the costs of ospf for different links. Expalin any considerations kept in mind when deciding ospf costs. Following table can be used to define the costs

Table 5 Proposed OSPF Metrics

Bandwidth [Mbps] CE-PE PE-PE (none MPLS) P-P iGW1-iGW2 PE-P primary RR-P, iGWx-P PE-P backup RR-P iGWx-P PE-PE (MPLS) E1 2 31300 - - -E3 34 31200 - - -FE 100 31100 - 5700 10700