Fast Convergence Techniques: IS-IS

We would be irresponsible as network designers if we did not study and appreciate IS-IS for the problems it can solve. IS-IS is a link-state protocol similar to OSPF. IS-IS uses TLVs (similar to BGP), and is thus easily extended. IS-IS and OSPF are the two choices you have when deploying TE on MPLS networks, so you should know how IS-IS compares with OSPF when your design requires fast convergence. Cisco has several resources on their site, which I’ve distilled into a few rules of thumb:

  1. Increase LSP refresh timer to a high value
  2. Increase MAX LSP lifetime to a high value
  3. Tune PRC interval
  4. Tune SPF interval
  5. Tune LSP generation interval
  6. Use BFD in lieu of fast hellos (on multiaccess networks)
  7. Tune ISIS retransmit interval
  8. Set overload-bit on startup
  9. Disable hello padding
  10. Use a single IS type where possible (note that Cisco default is L1/L2)
  11. Use metric-style wide (not necessarily FC related, but is req’d for TE)

Also related: use isis mesh-group and configure point-to-point interface type on multiaccess interfaces where they are really point-to-point (think 2-member Ethernet segments).

References:
Cisco Technology Support Page
Cisco IOS 12.4 IS-IS Fast Convergence
Cisco Configuration Example

Share/Save/Bookmark

Best Common Practices

For those of you who don’t know, the IETF publishes these documents called BCPs (Best Common Practice). These documents are useful to see what the Internet community believes is a best practice for a particular deployment type. I think these could be useful for CCDE study – not only because one of them is referred to on the written outline (BCP38) – but because they contain some very useful design information. BCP121, for example, contains MSDP deployment scenarios.

Here’s the full listing of BCP documents.

BCP128 – Avoiding ECMP in MPLS networks looks interesting.

Share/Save/Bookmark

Book Review: Definitive MPLS Network Designs

I have access to safari books through my employer, so I’ll be doing some brief reviews of each book to determine whether or not I’ll be buying it for further study.

The first of this series is Definitive MPLS Network Designs. The book contains several case studies that will be helpful in studying for the CCDE. There is a brief overview of the various technologies that are used with MPLS, but the technical content is not deep. This book concentrates on design aspects by examining design issues related to the following network types:

  • Interexchange Carrier
  • National Telco
  • Global SP
  • Large Enterprise

Buy or don’t buy? Since the CCDE concentrates on design rather than implementation, case studies are a must as part of your path to certification. I’ll be buying the book.


Share/Save/Bookmark

Updated book listing

I created a book list on Amazon which contains the books referenced in the CCDE roadmap. I am updating it to contain only the books which are in print. Of note, the Traffic Engineering with MPLS book (Osborne) was out of print. You’ll need to buy the paperback version for one that is in print.

MPLS and VPN Architectures (Pepelnjak) is also out of print. This book was very difficult to understand for me and I would not recommend it for a beginner. Either take a course in companion with this book or begin with a book like MPLS Fundamentals (DeGhein).

Advanced MPLS Design and Implementation is also out of print. This book received good reviews on Amazon, so I chose to leave it on the list.

Amazon book list.

Share/Save/Bookmark

Design Case Study 1 – Problem Overview

I thought it would be useful to document my design process using a case study. It is better (for me anyway) to force myself to write down my thought process so I more thoroughly understand the decisions involved. I believe the process of documenting, although sometimes tedious, is educational and gives me a much deeper understanding of the problem and solutions. With that said, let’s begin Design Case Study 1 – Problem Overview.

Given:
The customer wants to provide network services to remote users using satellite communications equipment. You do not have to concern yourself with the RF (radio frequency) portion of the network, but should have a basic understanding of how layer 3 and layer 2 services map to the RF network. The customer is a satellite network provider (worldwide) that provides the RF network management and connectivity to the customer network via landline (T1 or greater speeds).

Your objective is to document the current state of the network and propose changes that will scale the solution and provide the following services: IP Data and Voice. The network should be manageable, scalable, and secure.

The provider has purchased and installed equipment, but has little expertise in configuring and managing the network gear. As the network designer you should consider this when planning for operational expenses (OPEX).

Let’s begin with a high-level diagram. The basic design consists of N remote sites and a single Headquarters location. The remotes are backhauled using low-speed T1 (or lower) links.



What information do you need in order to make a proper assessment of the high-level design? I would probably start with the following questions:

  1. What business requirements are imposed on any network design? Does the business need a 24x7x365 operational network? Or is the availability constrained to an 8×5 model?
  2. What are the recovery requirements, and does it vary by site? How quickly must service be restored in the event of a failure, and how difficult is it to get parts to the site?
  3. Does the business expect the bandwidth requirements to grow? If so, will the growth be predictable in any sort of fashion? For example: if one site covers the Los Angeles area, and another site covers a less densely populated area, should we expect the LA site to support more growth?
  4. How deterministic must the network performance be? Will this network be required to support low-latency traffic like voice and video?
  5. What are the security requirements for the network? Must we simply protect portions like management access to devices or are we required to provide protection for data as well?

I think this covers the basics, I would drill down into specifics as I received answers from the customer.

What questions would you ask? Do you see anything I missed?

Share/Save/Bookmark

Multilink PPP

I recently came across a good use for MLPPP in solving a design issue. The problem I faced was that I had several T1 links between a remote site and a single distribution router. The issue was how to ensure fault tolerance, scalability, and ease of configuration. MLPPP seemed to be the ticket. MLPPP is easy to configure as you’ll see below. MLPPP also provides an easy way to scale the network, as routing will not change. Without some sort of link aggregation technique you would have to worry about how to load balance over the available links. Load balancing can be a complex topic, and in some cases – where the number of links is greater than 4 – some routing protocols will not work properly. In addition, links can fail while keeping your routing policies the same – no failover is necessary with MLPPP as long as there are links still in the bundle. Here are a few additional notes on MLPPP.

According to the Cisco SRND on Enterprise QoS, MLPPP is a recommended configuration when trying to solve the above problems, as long as CPU usage can be kept below 75%. The MQC can be applied to the Multilink interface directly, and bandwidth will automatically adjust as links come into/leave the Multilink group.

Along these lines, you should not configure a bandwidth statement on the Multilink interface, since it will not reflect the true bandwidth of the interface as links fail/recover.

The other issue it solves is a reduction in the number of IP addresses necessary to form a working configuration. Instead of using several subnets for all of the T1s, you only have to configure a single subnet for the Multilink interface. You could configure ip unnumbered if you like, although this is not a recommended practice – mainly because it can be difficult to manage.

Here’s a basic configuration:

interface Multilink1
ip address 172.30.1.1 255.255.255.252
encapsulation ppp
ppp multilink group 1

interface serial0/1/0:1
encapsulation ppp
ppp multilink group 1

interface serial0/1/1:1
encapsulation ppp
ppp multilink group 1

And a simple MQC configuration example:

class-map match-all VOICE
match dscp ef
policy-map mypolicy
class VOICE
priority percent 20
class class-default
fair-queue

interface Multilink1
service-policy output mypolicy

router#sho policy-map int
Multilink1
Service-policy output: mypolicy
Class-map: VOICE (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: dscp ef (46)
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 20 (%)
Bandwidth 614 (kbps) Burst 15350 (Bytes)
<...>

Now with a T1 disconnected:

router#sho policy-map int
Multilink1
Service-policy output: mypolicy
Class-map: VOICE (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: dscp ef (46)
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 20 (%)
Bandwidth 307 (kbps) Burst 7675 (Bytes)
<...>

As you can see, the Bandwidth in the priority queue drops as T1s leave the bundle.

Share/Save/Bookmark