There was several blogs which condemned IE’s choice of using a program called LockLizard which provided DRM for their PDF’s. LockLizard is a program which only runs on Windows and requires and periodic internet connection to ensure that the user opening the LockLizard PDF has the rights to do so.

I am entirely for IE maintaining their intellectual property and preventing piracy but as a native Linux user this had previously totally ruled out the option of using their material for my training, this didn’t concern me totally as there are similar products available from IPExpert which I have been looking at. Sure there was the option of me dual booting or running that virtual XP machine I have to use from time to time but its such an inconvenience.

But they finally announced that they will no longer use LockLizard and use standard PDFs instead in this blog post, they also announced some new anti piracy measures such as stenography and anti piracy bots. For me this is a great, when I start looking at solutions for my CCIE lab, I will review their material.

To improve performance of network devices packets should be marked as close to the source of the traffic, all network devices can then make decisions based upon those markings and do not need to reclassify or remark the traffic.

ToS Byte & IPP

RFC 791 defines the ToS (Type of Service) byte for “internet service quality selection”, thats QoS to you and me. The ToS byte initially used the first 3 bits to define the IP Precedence (IPP), the remaining bits where defined (except for the final bit) but rarely used.

Differentiated Services

Later on a standards were created for Differentiated Services (DiffServ), it went a little further and defined what each hop should do with the packet called Per Hop Behavior (PHB). The standard renamed the first 6 bits of the ToS byte to Differentiated Services Code Point (DSCP). The DSCP was used it for the selection of class in DiffServ, the first 3 bits are used for backwards compatibility with IPP. The final 2 bits were not defined but later used for Explicit Congestion Notification (apparently Vista is the first desktop OS which incorporates support for the ECN bits, but I don’t have a source for that info and its just hear say).

Please see the table below for the binary values of IPP/DSCP and the DSCP Class Selector values compared to the IPP names.

Assured Forwarding

Assured Forwarding (AF) is very common today, it defines the 6 DSCP bits to be used into 12 values. The 12 values for AF allows for 4 classes and 3 levels of drop probability for each class. AF DSCPs are shorted to the following format AFxy, x defines which queue and y defines the drop probability.

This handy table is from Page 410, of CCIE Routing & Switching 3rd Edition from Cisco Press;

Its really easy to turn the binary into the the AFxy format once you realise that the first 3 bits are for class and the final 3 bits in the DSCP field are are drop probability.

I have just gone through some of the methods of marking IP packets but not in that much detail, there are of course many other methods of marking traffic such as with the Discard Eligible (DE) bit in Frame Relay, Cell Loss Priority (CLP) in ATM, the MPLS Experiential bits, & CoS in the trunking headers.

There are 4 types of network delay which are summarized to form end to end delay they are;
Processing Delay, which is the time it takes a network device to make a decision on what to action to perform to a packet
Queuing Delay, is the time a packet spends in the outbound queue
Serialization Delay, how long it takes to put the bits onto the physical link
Prorogation Delay, this is the time a packet takes to travel down a physical link

Delays generally occur at the points where multiple downstream links aggregate into an upstream link or when there is a speed mismatch, eg your high speed LAN access the lower speed ISP connection.

But its not just delay which can cause problems, other network nasties include Packet Loss, Jitter, and lack of available bandwidth.

When the network was only being used for web, email, and file sharing it didn’t matter so much if there was jitter, a moderate packet loss or bad delays. Now with applications such as VOIP and video conferencing it has shifted engineers focus onto providing Quality of Service for the network, delays of greater than 150-200ms and packet losses higher than 1% can cause a significant degradation in quality.

The recognised methods of reducing delay are;
Increasing link speed – this can be an expensive approach and rarely solves the issue
Prioritise packets – by implementing queuing methods
Compress the packet payload – this is CPU Intensive
Compress the headers - this uses cRTP and is exceptionally handy for small VOIP packets where the header is a large percentage of the packet size
Avoid Congestion – using Congestion Avoidance techniques

In my next few posts I will go through the various stages for implementing Quality of Service, starting with classification & marking, congestion management & queuing, and policing & shaping.

There are a few really interesting mailing lists which I enjoy reading from time to time, if you do start subscribing to some lists then you should setup rules in your mail client to manage the mail or they can become overwhelming.

Cisco-nsp – This is a mailing list for people using Cisco in a Network Service Provider environment, it gets approximately 8 new posts a day and around 40 replies to those 8 posts. There are lots of interesting problems posted which are being experienced in the field. This is my favorite list by far and I try to read through some of the strange issues once every few days.

NANOG – Is the North American Network Operators Group this is for network operators primarily in the US but is used by people in other countries. They also have meetings in the US. It gets around 5 posts a day and 15 replies to those posts.

RIPE – RIPE (Réseaux IP Européens) is a collaborative group which is open to all interested parties in the development of the Internet in Europe. They have meetings every 6 months which is when most of the work gets done, they are organised into working groups, the mailing lists have very low traffic but its fun to be part of the community especially at RIPE meetings. RIPE & the RIPE NCC (Network Coordination Center) are separate entities but very closely related, the RIPE NCC is the Regional Internet Registry (RIR) for Europe, similar groups exist in other geographies such a IANA, APNIC, ARIN, Arfrnic, & LACNIC.

IETF - The IETF has lots of mailing lists and some have massive amounts of posts daily, trying to keep up with the IETF general discussion feels like a full time job. These lists are generally revolved around standards development.

Understanding all the OSPF LSA types is one of the keys to understanding OSPF, so its definatly worth me making a few notes on them

LSA type 1 – Router LSAs are sent from a router to other routers in the same area. It contains information regarding the routers interfaces in the same area, relevant interfaces IPs, its adjacent routers on those interfaces and sub networks

LSA type 2 – Network LSAs are generated by the DR on a multi access segment, and provides similar information to an LSA type 1 for the multi access segment and subnet which it belongs

LSA type 3 – Network Summary LSAs are generated by ABRs and contain the subnets & costs but omit the topological data from all subnets in one area and sent to another area via the ABR

LSA type 4 -ASBR summary LSAs are from ASBRs and are identical in structure to a type 3 LSA and sent when crossing an AS boundary

LSA type 5 -Are AS external LSAs which are originated by ASBRs and describe external networks

LSA type 6 – Is defined as a Group Membership LSA but not used in Cisco devices

LSA type 7 -NSSA External LSAs are generated by the ASBR in an NSSA area

LSA type 8 – Is defined as a External Attribute LSA but not used in Cisco devices

LSA types 9 to 11 – Defined as Opaque LSAs and are reserved for future expansion

OSPF uses a variety of area types to divide the network which results in smaller and therefore more efficient LSDBs due to summarization at ABRs & ASBRs, also failures are limited to a single area so OSPF does not need to run a full SPF calculation across the entire network and the reduced size of the LSDB uses less memory and therefore results in quicker SPF calculations.

The Backbone Area or Area 0

The backbone area which is also configured as area 0, which is the area number which is used in the configuration. Area 0 which must be directly connected (except for a few very rare circumstances) to every other area. Area 0 must be continuous and is used for inter area routing between the OSPF areas.

Standard Area

This is the default area type which accepts link updates, route summaries and external routes.

Stub Areas

A stub area (sometimes referred to as a stubby area), is an area which does not receive type 4 or 5 LSA’s which are external routes from ASBRs. But a stubby area will receive type 3 LSAs which are summary routes from ABRs. If there are multiple ABRs in a stub area the route will be chosen which has the shortest path to the destination.

Totally Stubby Areas

Totally Stubby Areas, is a non standard area type used in Ciscos implementation of multi area OSPF. Totally Stubby Areas do not accept type 3, 4 or 5 LSAs, the ABRs only injects a single default route into the area. If there are multiple ABRs in the Totally Stubby Area each router routes to the closest (lowest metric) ABR in its area.

Not So Stubby Area (NSSA)

A Not So Stubby Area (NSSA) is a stub area which contains an an ASBR. It operates in the same way as a stub area but originates type 7 LSAs which are external routes from a ASBR in a NSSA area.

Not So Stubby Totally Stubby Area

This area name has got to be one of the craziest names I have come across, and I thought a Not So Stubby Area was bad. Its another non standard area type used by Cisco which is a Totally Stubby Area which has an ASBR which originates type 7 LSAs.

On an multiaccess network OSPF prevents every router on the segment from becoming fully adjacent neighbors with each other through the use of OSPF Designated Routers (DR).

If OSPF did not use the concept of having a DR then each router on the multiaccess segment would directly share its LSDB with each other, we can calculate the number of instances of  LSDB flooding that would occur if there wasn’t a DR on a multiaccess segment with the full mesh formula which is N(N-1)/2.

So without OSPF DRs if we had 10 routers then where would be 45 LSDBs flooded between the adjacent OSPF routers (N(N1-1)/2 = 10(10-1)/2 = 45). This could potentially cause a serious amount of overhead due to the massive amount of redundant LSAs that would be propagating the network. This is the main reason why OSPF DRs are used, another good point about OSPF DRs is that they originate type 2 LSAs which represent a subnet. I will make a post on all of the LSA types soon.

OSPF will start to perform a DR election when it starts 2-way state on the first neighbor it sees on an interface if the hello received from the neighbor has a DR of 0.0.0.0 (0.0.0.0 as the DR in a hello packet means a DR has not yet been elected). OSPF will then wait the period specified in the Dead Timer, where it is waiting for other routers to communicate and come online. This timer is called the wait time and is used to allow other routers to come online and be active for the DR elections after a failure, if this did not occur then one of the first routers to be online would always be the DR.

If the received OSPF hello has a DR of anything else apart from 0.0.0.0 that indicates that DR elections have already taken place and OSPF will use the DR specified in the hello.

In each OSPF hello it sends the current DR and its Priority, if the DR priority of a received hello is higher than the current DR it recognises that as the current DR. The router priority is a value between 0 and 255 with the higher being better, the default is 1 and if it is set to 0 then the router will never become a DR. If there is a tie between OSPF priorities then the highest Router ID wins the tie breaker. The second most preferable DR becomes the Backup DR (BDR) and is used as a failover. Routers which are not the DR or BDR assume the DROther state. Once the DR election is complete the router will move into ExStart and start exchange Database Descriptors (DD).

All OSPF routers send their DDs to the multicast address of 224.0.0.6, this gets acknowledged by the DR sending the same packet back to the source as unicast. The DR then sends the DD it has received to all OSPF routers on the multi access segment via the multicast address of 224.0.0.5. This means that all routers on a multi access network to not need to constantly keep updating one another, they only have to update a central source and this is then sent to the segment.

I have blitzed through EIGRP in the last few days and am starting on OSPF, here is the first of a few posts I will make on it in the next few days.

For a router to send OSPF messages it has to define its OSPF Router Identifier (RID). This is a 32bit dotted decimal number which uniquely identifies the router.

Its a simple 3 steps for the router to choose what the RID will be

1. If the router-id id command is configured under router ospf then that that will always be used as the RID
2. If there is no router-id configured it uses the numerically highest up loopback interface
3. Finally if there is no router-id command set or no loopback interfaces up then it uses the highest interface IP address which is up.

It should be noted that the RID is only used to uniquely identify the OSPF router and does not need to be reachable or exist in the routing table. If the RID is changed then all OSPF routers in the area will have to recalculate SPF as its unique identifier has changed.

The final point is that the RID will only change when the router-id command is entered, or OSPF is restarted.

The CCNP/CCNA TV events are live online presentations by Cisco on various technologies, the one coming up on July 24th 2008 seems pretty interesting.

Register for the CCNP TV: Implement Multicast Forwarding, July 24, 2008

Note: Please remember to use your Cisco.com/CCO username and password to register for this event.

Watch a live presentation done by Abhi Singh. Abhi holds various certifications including a CCNA, CCNP and a CCIE. Abhi is a Network Consulting Engineer for Cisco and works closely with customers in the Service Provider segment.

Agenda:
The program will focus on the following objectives and is designed to provide information that will assist you in passing your CCNP exam. After Abhi Singh’s presentation, we’ll be taking live calls from YOU – the viewer— during our Q&A session. You may also submit questions electronically.

Objectives:
During the show, Cisco Experts will discuss:

• Why do we need Multicast?
• Multicast at Layer 2 (IGMPv2/3)
• Multicast at Layer 3 (PIM)

To register for the event visit https://cisco.hosted.jivesoftware.com/docs/DOC-2442 you will need to create an account/login to the free Cisco Learning Network for this.

The EIGRP K values are used to calculate the EIGRP metric, by default the metric is based on constrained bandwidth, and cumulative delay but can be configured to use Link load, reliability & MTU. Cisco Recommends that Link Load & Reliability are not used in the metric as these values change rapidly due to network conditions and results in frequent convergence.

The delay is a calculated as the cumulative total delay of the path through the network, this is measured in tens of microseconds so a 10millisecond (ms) delay = 1000 tens of microseconds.

The bandwidth is calculated in the minimum interface bandwidth available and measured in kB.

If the default K-Values are used the Bandwidth and Delay are scaled with the following formula
EIGRP metric = 256(10000000/bandwidth)+256(delay)

The full official formula which includes all the K values is as follows;
EIGRP metric = [K1 * bandwidth + (K2 * bandwidth) / (256 - load) + K3 * delay] * [K5 / (reliability + K4)]

The K values can be changed with the following command
metric weights tos k1 k2 k3 k4 k5

Where; k1 = bandwidth, k2 = load, k3 = delay, k4 = reliability & k5 = MTU.