Module 2-Ip Routing Basic

Bharat Sanchar Nigam Limited Hkkjr lapkj fuxe fyfeVsM
JTO Ph-II DATA NETWORK

WEEK-2 (IP ROUTING BASIC)
BSNL
ES & IT FACULTY
COURSE CODE – BRBCOIF 114
BHARAT RATNA BHIMRAO AMBEDKAR

INSTITUTE OF TELECOM TRAINING,
RIDGE ROAD, JABALPUR – 482 001
(ISO-9001 : 2008 Certified)
―DATA NETWORK‖ FOR JTOs PH-II
PHASE II SPECIALIZATION TRAINING

ON
“DATA NETWORKS” FOR JTOs
INDEX
Week-2 IP ROUTING BASICS:-
S No Topic Page No.

1. IP routing principal 2
2. Overview of IPv6 18
3. RIP 28
4. OSPF 43
5. BGP 69
6. NIB-I Network NIB-I: Cisco7513, 7507,Catalyst5500, 90
Router Architecture, RAS- AS 5800
7. Cisco Router Configuration Basics 111
8. Preliminary configuration of Sample Network 115
9. Cisco Router Configuration: Static & Static/Default Routing 116
10. Cisco Router Configuration: RIP & RIP Static/Default 117
11. Cisco Router Configuration: OSPF Multi Area, OSPF Route 117
Summarization, OSPF Normal/Stub/Totally Stub/NSSA,
OSPF/RIP Redistribution, OSPF/Static/Default
BRBRAITT : June-2011 1
ROUTING PRINCIPLES
ROUTING PRINCIPLES
SWITCHING
A typical electrical switch directs current to one of several wires of the electrical
circuit. Once the connection is made, the switch appears as part of the wire - it
(ideally) introduces no resistance, no attenuation, no delay. A networking switch is
designed to behave in much the same way. Its primary feature is speed. Like an
electrical switch, it is designed to appear much like a wire when relaying data signals.
Networking Switches must implement a normal path selection

algorithm; they just do it faster. Layer 2 switches bridge whereas layer 3 switches
route.
Normal Bridges and Routers will receive an entire packet, analyse its headers, make a
forwarding decision, then transmit the packet. The packet is stored in the RAM
(Random access Memory) while being processed. These RAM buffers can become
bottlenecks in a busy network. Switches use special silicon chips than can forward
packets directly from source to destination without passing through RAM buffers.
Consider a typical Ethernet switch, which acts much like a standard IEEE 802.1d
bridge. The difference is that as soon as an incoming packet's header has been
received, a forwarding decision is immediately made, before the packet is completely
received. If the destination Ethernet segment is idle, the packet begins transmission
there immediately. As bits are received they are shunted through the switch fabric to
the destination interface. On a 10 Mbps Ethernet, the net delay is perhaps one or two
microseconds, as opposed to several milliseconds for a typical bridge. This is termed
cut-through switching.
With respect to Layer 3, the term switching implies, moving packets from one port to
another port. This is different from Layer 2 switching functionality, which implies
forwarding a packet from one port to another port based on the MAC address only.
Routing
The primary function of a packet switching network is to receive packets from a
source and deliver them to the destination. To achieve this, a path or route through the
network has to be determined. More than one route may be possible. This requires a
routing function/ algorithm to be implemented.
The routing function must achieve the following requirements :

Correctness
Simplicity
Robustness
Stability
Fairness
Optimality
Efficiency
Correctness and Simplicity are self explanatory.
Robustness has to do with the routing of packets through alternate routes in the
network in case of route failures or overloads.
Stability is an important aspect of the routing algorithm. It implies that the routing
algorithm must converge to equilibrium as quickly as possible, however some never
converge, no matter how long they run.
Fairness and optimality are competing requirements. A trade-off exists between the
two. Some performance criteria may give a higher priority to transportation of packets
between adjacent/ nearby stations in comparison to those between distant stations.
This results in higher throughput but is not fair to the stations which have to
communicate with distant stations.
Efficiency of a routing technique/ algorithm gets decided by the quantum of overhead

processing required. Of course these have to be kept to a minimum.
Thus, Routing is essentially a method of path selection and is an overhead activity.

Routing Table ARP Table
100.3.4.0 100.1.1.5 7 100.1.1.5 3CE9...

100.3.6.0 100.1.1.9 100.1.1.9 3C76...
100.1.1.13 3C87...
100.3.7.0 100.1.1.13
6
3
Network
2 Data Link
1 Physical
Fig.1 Routing & Switching
Routing & Network Layer Addresses

Routers relay a packet from one data link to another. To relay a packet, a router
employs two basic functions :
a path determination function and
a switching function.
Figure 2 illustrates how routers use the addressing for routing and switching
functions. When a packet destined for network 100.1.0.0 arrives at Router 1, the
router knows that the packet should be sent out on port S0.
ROUTER R1 100.2.0.0
S1
S2
S0
100.1.0.0
100.3.0.0
S0
DESTINATION ROUTER
NETW ORK PORT
S1
ADDRESS ROUTER R2
100.1.0.0 S0
100.4.0.0
100.2.0.0 S1
100.3.0.0 S2
100.4.0.0 S2
Fig. 2 Use of Network Layer Addresses in Routing

Although the path determination function sometimes is capable of calculating the
complete path from the router to the destination, a router is responsible only for
passing the packet to the best network along the path. This best path is represented as
a direction to a destination network. For example, in figure 2, if a packet that is
destined for network 100.4.0.0 arrives at Router 1, the router knows that the best
direction to send the packet out is interface S2. Router 2 is the next hop, or router,
along the path. The router uses the network portion of the address to make these path
selections.
The switching function enables a router to accept a packet on one interface and
forward it on a second interface. The path determination function enables the router to
select the most appropriate interface for forwarding a packet.
Routing assumes that addresses have been assigned to network elements to facilitate
data delivery. In particular, routing assumes that addresses convey at least partial
information about where a host is located. This permits routers to forward packets
without having to rely either on broadcasting or a complete listing of all possible
destinations. At the IP level, routing is used almost exclusively, primarily because the
Internet was designed to construct large networks in which heavy broadcasting or
huge routing tables are not feasible.
Three general prerequisites must be met to perform routing :
Design :
A plan must exist by which addresses are assigned. Typically, addresses are broken
into fields corresponding to levels in a physical hierarchy. At each level of the
hierarchy, only the corresponding field in the address is used, permitting addresses to
be handled in blocks. In IP, the most common designs are IP Address Classes, Sub-
netting, and CIDR.
Implementation :
The design plan must be implemented in switching nodes, which must be able to
extract path information from the addresses. Since router programming is generally
not under a designer's control, designs must be limited by the features provided by
manufacturers. Subnetting's great appeal lies in its great flexibility, while using a
fairly simple implementation model.
Enforcement :
The plan must be enforced in host addressing. A design is useless unless addresses are
assigned in accordance with it. Addressing authority must be centralised.
In the Internet environment, routing is almost always used at the IP level, and
bridging almost always used at the Data Link Layer.
For new network installations, the best approach is to plan for routing even if it's not
used at first. This requires some advanced planning to design an addressing scheme
that will work. However, the overhead is all human - hardware won't know the
difference between organised and haphazard addressing schemes. Network should be
planned for the ability to put routers in strategic locations, even if those locations will
initially use bridges or just signal boosters (such as Ethernet hubs and repeaters). In
this manner, routers can be easily added later.
Routed Protocol
A routed protocol is a protocol that contains sufficient network-layer addressing
information for user traffic to be directed from one network to another network.
Routed protocols define the format and use of the fields within a packet. Packets that
use a routed protocol are conveyed from one end system to another end system
through an internetwork.
The internet protocol IP and Novell‘s IPX are examples of routed protocols.
Routing Protocol
A routing protocol provides mechanisms for sharing routing information. Routing
protocol messages move between the routers. A routing protocol allows the routers to
communicate with other routers to update and maintain routing tables. Routing
protocol messages do not carry end-user traffic from network to network. A routing
protocol uses the routed protocol to pass information between routers.
Types of Routing : Static, Default, Dynamic
Static routing :
Refers to routes to destinations being setup manually

in the router. Network reachability in this case is not dependent on the
existence and state of the network itself. Whether a destination is up or
down, the static routes would remain in the routing table, and traffic
would still be sent towards that destination. Static routing generally is not sufficient
for large or complex networks because of the time required to define and maintain
static route table entries.
Default routing :
Refers to a ―last resort‖ outlet – traffic to destinations

that are unknown to the local router are sent to the default outlet router. Default
routing is the easiest form of routing for a domain connected to a single exit point. A
default route is a path on which a router should forward a packet if it does not have
specific knowledge about the packet‘s destination.
Figure 3 below illustrates the concept of Static and default Routing.
Static Routing 10.1/16
Traffic to 10.1
R1 R2
WAN
Send all traffic to R1
Default Routing
Fig.3 Static and Default Routing
Dynamic routing :
Refers to routes being learnt via an internal or

external routing protocol. Network reachability is dependent on the existence and
state of the network. If a destination is down, the route would disappear from the
routing table, and traffic will not be sent toward the destination. Dynamic routing is
used to enable routers to build their routing tables automatically and make the
appropriate forwarding decisions. This concept is illustrated in Figure 4 below.
R2
Routing update :
I can reach 100.1
X
R2
R3 R1
100.1
Routing update :
I can reach 100.1
Fig. 4 Dynamic Routing
Static and default routing are not our enemy. The most stable (but not so flexible)
configurations are the ones based on static routing. Many people feel that they are not
technologically up-to-date because they are not running dynamic routing. Trying to
force dynamic routing on situations that do not really need it is just a waste of
bandwidth, effort, and money.
As networks keep on growing in size, the routing tables also grow proportionately.
Considerable amount of router memory is consumed by these ever increasing tables.
In addition, the processor time is eaten up in scanning these tables and bandwith is
consumed in sending status reports about the updated routing tables. At a certain
stage, the network size becomes so large that it becomes impossible to have every
router keep an entry of every other router in the network. Ultimately, the routing has
to be done hierarchically, similar to a telephone network.
Routing Algorithms
Routing algorithms and protocols form the core of the hacker's Internet, because it is
here that all the decisions get made. Network engineers assign costs to network paths,
and routing protocols select the least-cost path to the destination.
Routing protocols bear a resemblance to capitalist market economics. In both systems,

there is a large group of "nodes", the decisions of each being driven by a cost-
minimisation algorithm. The end result is a reasonably efficient distribution of
"resources". Furthermore, cost determination is done in similar ways. A router, like an
import/export firm, will compute its cost, add on profit for its part in the transaction,
and pass this cost along to customers. Both systems use this method to achieve
reasonable efficiency.
Routing is the main process used by Internet hosts to deliver packets. Internet uses a
hop-by-hop routing model, which means that each host or router that handles a packet
examines the Destination Address in the IP header, computes the next hop that will
bring the packet one step closer to its destination, and delivers the packet to the next
hop, where the process is repeated.
To make this work, two things are needed :

First, routing tables match the destination addresses with next hops.
Second, routing protocols determine the contents of these tables.
Routing algorithms can be grouped into two major classes :
Non-Adaptive or Static
Adaptive or Dynamic
Non-Adaptive algorithms
This algorithm do not base their routing decisions on measurements or estimates of

the current traffic and topology. Instead, the choice of the route to use to get from I to
J (for all I to J) is computed in advance, off-line, and downloaded to the routers when
the network is booted. This procedure is also called as Static Routing.
Adaptive algorithms
This algorithm change their routing decisions to take into account changes in the
topology, and sometimes the traffic as well. Adaptive algorithms will be classified
depending on :
where it gets the information from - whether locally, from adjacent Routers, or
from all Routers
When does the algorithm decide to change the routes - whether every T sec,
when the load changes, or when the topology changes, and
what metric (parameter) is used for optimisation i.e. either distance, number of
hops, or estimated transit time.
Dynamic Routing Operations
The success of dynamic routing depends on two basic router functions :

Maintenance of a routing table
Timely distribution of knowledge – in the form of routing updates – to other
routers
Dynamic routing relies on a routing protocol to disseminate knowledge. A routing
protocol defines the set of rules used by a router when it communicates with
neighbouring routers. Typically, a routing protocol describes:
How updates are conveyed
What knowledge is conveyed
When to convey this knowledge
How to locate recipients of the updates
Convergence
Information about the network topology needs to be very accurate and also consistent
from Router to Router. This consistency and accuracy is referred to as Convergence.
The network is considered to have converged when all the Routers contain consistent
information.
Representing Distance with Metrics

When a routing algorithm updates the routing table, its primary goal is to determine
the best information to include in the table. Each routing algorithm will interpret
―best‖ in its own way. The algorithm generates a number – called the metric- for each
path through the network. Typically, the smaller the metric, the better is the path.
Metrics can be calculated based on a single characteristic of the path or by combining

several key characteristics such as :
1) Hop Count :
Refers to the number of routers a packet must go through, to reach a destination. The
lower the hop count, the better is the path. Path length is used to indicate the sum of
the hops to a destination.
2) Cost :
Path cost is the sum of cost associated with each link to

a destination. Costs are assigned (automatically or manually) to the process of
crossing a network. Slower networks typically have a higher cost than faster
networks. The lowest ‗cost‖ route is the one believed to be the fastest route available.
3) Bandwidth :
The rating of a link‘s throughput. Routing through links with greater bandwidth does
not always provide the best routes. For example, if a high-speed link is busy, sending
a packet through a slower link might be faster.
4) Delay :
Depends on many factors, including the bandwidth of network links, the length of
queues at each router in the path, network congestion on links, and the physical
distance to be travelled. A conglomeration of variables that change with internetwork
conditions, delay is common and useful metric.
5) Load :
Dynamic factor that can be based on a variety of measures, including CPU and packet
processed per second. Monitoring these parameters on a continual basis can be
resource intensive.
Modern computer networks generally use dynamic routing algorithms rather than
the static ones. Two dynamic algorithms in particular,
distance vector routing and
link state routing
are the most popular.
Distance Vector Routing
Distance Vector Routing algorithms require that each router maintain a table (a
vector) indicating the best known distance to each destination and which line/ port to
use to reach there. These tables are constantly updated by exchanging information
with the neighbours. The algorithms periodically pass copies of a routing table from
router to router. Updates between routers also communicate topology changes
immediately when they occur.
The distance vector routing is also known by other names, viz; the distributed
Bellman-Ford routing algorithm and the Ford-Fulkerson algorithm, after the
researchers who developed it (Bellman, 1957; and Ford and Fulkerson, 1962). It was
the original ARPANET routing algorithm and was also used in the Internet under the
name RIP and in early versions of DECnet and Novell‘s IPX.
In distance vector routing, each router maintains a routing table containing one entry
for, each router in the subnet. This entry consists of two parts :
the preferred outgoing line/ port to use for that destination, and
an estimate of the time or distance to that destination. The metric used might
be number of hops, time delay in milliseconds, total number of packet queued
along the path, or something similar.
The router is assumed to know the ―distance‖ to each of its neighbours. If the metric
is hops, the distance is just one hop. If the metric is queue length, the router simply
examines each queue. If the metric is delay, the router can measure it directly with
special ECHO packets that the receiver just time-stamps and sends them back as fast
as it can.
A
C
D C B A
Routing Routing Routing Routing

Table Table Table Table
Fig. 5 Distance Vector Routing Updates
Each router receives a routing table from other routers connected to the same network,
as shown in Figure 5. For example, in the figure, router B receives information from
router A, its neighbouring router across the WAN link. Router B adds a distance
vector number (such as the number of hops) thereby increasing the distance vector,
and then passes the routing table to its other neighbouring router C. This Step-by-step
process occurs in all directions between directly connected neighbour routers.
In this way, the algorithm accumulates network distances sothat it can maintain a
database of network topology information. Distance vector algorithms do not allow a
router to know the exact topology of an internetwork.
Distance vector information is similar to the information found on signs at a highway

intersection. A sign points toward a road leading away from the intersection and
indicates the distance to the destination. Further down the highway, another sine also
points towards the destination, but now the distance to the destination is shorter. As
long as each successive point on the path shows that the distance to the destination is
successively shorter, we know that the traffic is following the best path.Examples of
distance vector routing protocols are IPX RIP and IP RIP.
Distance Vector Network Discovery

Each router using distance vector routing begins by identifying its own neighbours. In
Figure 6 the interface to each directly connected network is shown in the routing
tables as having a distance of 0.
D
B C
100.2.0.0 100.3.0.0
100.1.0.0
S2 S0
S2 S1
S1 S1
Routing Table Routing Table Routing Table

100.1.0.0 S1 0 100.2.0.0 S2 0 100.3.0.0 S0 0
100.2.0.0 S2 0 100.3.0.0 S1 0 100.4.0.0 S1 0
100.3.0.0 S2 1 100.4.0.0 S1 1 100.2.0.0 S0 1
100.4.0.0 S2 2 100.1.0.0 S2 1 100.1.0.0 S0 2
Fig. 6 Distance Vector Route Discovery
As the distance vector network discovery process proceeds, routers discover the best
path to destination networks based on accumulated metrics from each neighbour.
For example, router A learns about other networks based on information it receives
from router B. Each of the other network entries learnt from router B are placed in
router A‘s routing table.
Link State Routing

Link State Routing replaced the Distance Vector Routing (used in the ARPANET) in
1979. Two problems caused the demise of Distance Vector algorithm. First, since the
delay metric was queue length, it did not take line bandwidth into account when
choosing the routes. It would have been possible to change the delay metric to take
into account the line bandwidth, but a second problem existed, namely, the algorithm
often took too long to coverage, even with enhancements like split horizon. For these
reasons, it was replaced by an entirely new algorithm now called link state routing.
Variants of link state routing are now widely used.
The 5 step concept is stated below :
1. Discover the neighbors and learn their network addresses

2. Measure the delay or cost to each of the neighbors
3. Construct a packet telling all that has just been learnt
4. Send this packet to all other routers
5. Compute the shortest path to every other router
When a router is booted, its first task is to learn who its neighbours are. This task is
accomplished by sending a special HELLO packet on each point-to-point line. The
router on the other end is expected to send back a reply telling who it is.
Link-state routing algorithms - also known as shortest path first (SPF) algorithm
maintain a complex database of topology information. Whereas the distance vector
algorithm has entries for distant networks and a metric value to reach those networks
but no knowledge of distant routers, a link state routing algorithm maintains full
knowledge of distant routers and how they interconnect. Examples of link-state
routing protocols are : NLSP, OSPF, and IS-IS.
Link state routing is widely used in actual networks. The OSPF protocol, which is
increasingly being used in the Internet, uses a link state algorithm.
Link-State Network Discovery

Link-state network discovery mechanisms are used to create a common picture of the
entire internetwork. All routers employing the link state routing algorithm share this
common view of the internetwork. In Figure 7, four networks (W,X,Y, and Z) are
connected by three link-state routers
(A,B, and C).
A B C
X Y
W Z
S1 S0
S0
S1 S1
Routing Table Routing Table Routing Table

W S0 0 X S1 0 Y S1 0
X S1 0 Y S0 0 Z S0 0
Fig. 7 Link State Routing
Link-State Network discovery proceeds as follows :
Routers learn about their neighbours; that is, other routers that are on directly
connected networks with them. This process is often referred to as neighbour
notification. In link-state routing, each router connected to a network keeps
track of its neighbours.
Routers transmit LSPs (Link State Packets) on the network. The LSPs contain
information about networks to which the routers are connected.
Then, routers constructed their topological databases consisting of all the LSPs
from the internetwork.
The SPF algorithm computes network reachability, determining the shortest
path from a router to each other network in the link-state protocol
internetwork. The router uses the Dijkstra algorithm to construct this logical
topology of shortest paths as an SPF tree with itself as root. The SPF tree
expresses paths from the router to all destinations.
The router computes its best paths and the ports to these destination networks
and enters them in the routing table.
After the routers dynamically discover the details of their internetwork, they can use
the routing table for switching packet traffic.
Comparison of Distance Vector Routing & Link-State Routing

You can compare distance-vector routing to link-state routing in several key areas, as
listed in Table 1.
Table 1
Distance Vector Link State
Network Topology is viewed from Entire Network Topology is common to all

neighbours perspective Routers
Metrics are incremented as the update Shortest Path to other Routers is calculated
crosses one Router
Periodic & Frequent Updates results in Updates are triggered by events. Results in
slow convergence faster convergence
Copies of Routing Tables are passed to Link State Packets are passed to other
neighbouring Routers Routers
Interior Routing
Interior routing occurs within an autonomous system. Most common interior routing
protocols are RIP and OSPF. The basic routable element is the IP network or
subnetwork, or CIDR prefix for newer protocols.
Exterior Routing
Exterior routing occurs between autonomous systems, and is of concern to service
providers and other large or complex networks. The basic routable element is the
Autonomous System, a collection of CIDR prefixes identified by an Autonomous
System number. While there may be many different interior routing schemes, a single
exterior routing system manages the global Internet, based primarily on the BGP-4
(Border Gateway Protocol Version 4) exterior routing protocol.
IGP
Autonomous
Systems
Autonomous
Systems
BGP BGP
IGP
IGP
BGP
Fig. 8 General illustration of Protocol relationships
Distance Vector Protocols :

1) D-V Protocols such as RIP Version 1 were mainly designed for small
network topologies.
2) The term Distance Vector derives from the fact that the protocol includes
in its routing updates a vector of distances (hop counts).
3) Low speed links are treated equally or sometimes preferred over a high-
speed link, depending on the calculated hop count in reaching a
destination. This may lead to inefficient routing behaviour.
4) Count to infinity restriction : D-V Protocols have a finite limit of hops (15)
after which a route is considered unreachable. This would restrict the
propagation of routing updates and would cause problems for large
networks.
5) The reliance on hop counts is one deficiency of distance vector protocols;
another deficiency is the way that the routing information gets updated.
6) D-V Protocols work on the concept that routers exchange all the network
numbers they can reach via periodic broadcasts of the entire routing table.
In large networks, the routing table exchanged between routers becomes
very hard to maintain, leading to slower convergence.
7) D-V Protocols are considered to be Flat. They present a lack of hierarchy,
which translates into a lack of aggregation. This flat nature has made D-V
Protocols incapable of scaling to larger and more efficient enterprise
networks.
Link State Protocols :

1) Link State Protocols work on the basis that routers exchange
information elements, called link states, which carry
information about links and nodes.
2) This means that routers running link state protocols do not exchange
routing tables. Each router inside a domain will have enough bits and
pieces of the big puzzle that it can run a shortest path algorithm and build
its own routing table.
IPV6
IPV6
Introduction
By the early 1990s, it was clear that the change to a classful network introduced a
decade earlier was not enough to prevent the IPv4 address exhaustion and that further
changes to IPv4 were needed.[1] By the winter of 1992, several proposed systems were
being circulated and by the fall of 1993, the IETF announced a call for white papers
(RFC 1550) and the creation of the "IPng Area" of working groups.[1][2]
IPng was adopted by the Internet Engineering Task Force on July 25, 1994 with the
formation of several "IP Next Generation" (IPng) working groups.[1] By 1996, a series
of RFCs were released defining IPv6, starting with RFC 2460. (Incidentally, IPv5 was
not a successor to IPv4, but an experimental flow-oriented streaming protocol
intended to support video and audio.)
It is expected that IPv4 will be supported alongside IPv6 for the foreseeable future.
However, IPv4-only clients/servers will not be able to communicate directly with
IPv6 clients/servers, and will require service-specific intermediate servers or NAT-PT
protocol-translation servers.
Features of IPv6
To a great extent, IPv6 is a conservative extension of IPv4. Most transport- and
application-layer protocols need little or no change to work over IPv6; exceptions are
applications protocols that embed network-layer addresses (such as FTP or NTPv3).
Applications, however, usually need small changes and a recompile in order to run
over IPv6.
Larger address space

The main feature of IPv6 that is driving adoption today is the larger address space:
addresses in IPv6 are 128 bits long versus 32 bits in IPv4.
The larger address space avoids the potential exhaustion of the IPv4 address space
without the need for NAT and other devices that break the end-to-end nature of
Internet traffic. It also makes administration of medium and large networks simpler,
by avoiding the need for complex Subnetting schemes.
The drawback of the large address size is that IPv6 carries some bandwidth overhead
over IPv4, which may hurt regions where bandwidth is limited (header compression
can sometimes be used to alleviate this problem).
Stateless autoconfiguration of hosts
IPv6 hosts can be configured automatically when connected to a routed IPv6 network.
When first connected to a network, a host sends a link-local multicast (broadcast)
request for its configuration parameters; if configured suitably, routers respond to
such a request with a router advertisement packet that contains network-layer
configuration parameters.
If IPv6 autoconfiguration is not suitable, a host can use stateful autoconfiguration
(DHCPv6) or be configured manually.
Stateless autoconfiguration is only suitable for hosts: routers must be configured

manually or by other means.
Multicast
Multicast is part of the base protocol suite in IPv6. This is in opposition to IPv4,
where multicast is optional.
Most environments do not currently have their network infrastructures configured to

route multicast; that is — the link-scoped aspect of multicast will work but the site-
scope, organization-scope and global-scope multicast will not be routed.
IPv6 does not have a link-local broadcast facility; the same effect can be achieved by
multicasting to the all-hosts group (FF02::1).
The m6bone is catering for deployment of a global IPv6 Multicast network.
Jumbograms
In IPv4, packets are limited to 64 KiB of payload. When used between capable
communication partners and on communication links with a MTU larger than 65,576
octets, IPv6 has optional support for packets over this limit, referred to as
jumbograms which can be as large as 4 GiB. The use of jumbograms may improve
performance over high-MTU networks.
Network-layer security
IPsec, the protocol for IP network-layer encryption and authentication, is an integral
part of the base protocol suite in IPv6; this is unlike IPv4, where it is optional (but
usually implemented). IPsec, however, is not widely deployed except for securing
traffic between IPv6 BGP routers.
Mobility
Unlike mobile IPv4, Mobile IPv6 (MIPv6) avoids triangular routing and is therefore
as efficient as normal IPv6. This advantage is mostly hypothetical, as neither MIP nor
MIPv6 are widely deployed today.
Deployment status
As of December 2005, IPv6 accounts for a tiny percentage of the live addresses in the
publicly-accessible Internet, which is still dominated by IPv4. The adoption of IPv6
has been slowed by the introduction of classless inter-domain routing (CIDR) and
network address translation (NAT), each of which has partially alleviated the impact
of address space exhaustion. Estimates as to when the pool of available IPv4
addresses will be exhausted vary — in 2003, Paul Wilson (director of APNIC) stated
that, based on then-current rates of deployment, the available space would last until
2023,[3] while in September 2005 a report by Cisco Systems that the pool of available
addresses would be exhausted in as little as 4–5 years.[4] As of November 2006, a
regularly updated report projected that the IANA pool of unallocated addresses would
be exhausted in May 2011, with the various Regional Internet Registries using up
their allocations from IANA in August 2012.[5] This report also argues that, if
assigned but unused addresses were reclaimed and used to meet continuing demand,
allocation of IPv4 addresses could continue until 2024. The U.S. Government has
specified that the network backbones of all federal agencies must deploy IPv6 by
2008.[6] Meanwhile China is planning to get a head start implementing IPv6 with
their 5 year plan for the China Next Generation Internet.
With the notable exceptions of stateless autoconfiguration, more flexible addressing

and Secure Neighbor Discovery (SEND), many of the features of IPv6 have been
ported to IPv4 in a more or less elegant manner. Thus IPv6 deployment is primarily
driven by address space exhaustion.
Addressing
128-bit length
The primary change from IPv4 to IPv6 is the length of network addresses. IPv6
addresses are 128 bits long (as defined by RFC 4291), whereas IPv4 addresses are 32
bits; where the IPv4 address space contains roughly 4 billion addresses, IPv6 has
enough room for 3.4×1038 unique addresses.
IPv6 addresses are typically composed of two logical parts: a 64-bit (sub-)network
prefix, and a 64-bit host part, which is either automatically generated from the
interface's MAC address or assigned sequentially. Because the globally unique MAC
addresses offer an opportunity to track user equipment, and so users, across time and
IPv6 address changes, RFC 3041 was developed to reduce the prospect of user
identity being permanently tied to an IPv6 address, thus restoring some of the
possibilities of anonymity existing at IPv4. RFC 3041 specifies a mechanism by
which variable over time random bit strings can be used as interface circuit identifiers,
replacing unchanging and traceable MAC addresses.
Notation
IPv6 addresses are normally written as eight groups of four hexadecimal digits. For
example, 2001:0db8:85a3:08d3:1319:8a2e:0370:7334 is a valid IPv6 address.
If a four-digit group is 0000, the zeros may be omitted and replaced with two
colons(::). For example, 2001:0db8:0000:0000:0000:0000:1428:57ab can be
shortened as 2001:0db8::1428:57ab. Following this rule, any number of consecutive
0000 groups may be reduced to two colons, as long as there is only one double colon
used in an address. Leading zeros in a group can also be omitted. Thus, the addresses
below are all valid and equivalent:
2001:0db8:0000:0000:0000:0000:1428:57ab
2001:0db8:0000:0000:0000::1428:57ab
2001:0db8:0:0:0:0:1428:57ab
2001:0db8:0:0::1428:57ab
2001:0db8::1428:57ab
2001:db8::1428:57ab
Having more than one double-colon abbreviation in an address is invalid, as it would
make the notation ambiguous.
A sequence of 4 bytes at the end of an IPv6 address can also be written in decimal,
using dots as separators. This notation is often used with compatibility addresses (see
below). Thus, ::ffff:1.2.3.4 is the same address as ::ffff:0102:0304, and
::ffff:15.16.18.31 is the same address as ::ffff:0f10:121f.
Additional information can be found in RFC 4291 - IP Version 6 Addressing

Architecture.
Literal IPv6 Addresses in URLs
In a URL the IPv6-Address is enclosed in brackets. Example:
http://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]/
This notation allows parsing a URL without confusing the IPv6 address and port
number:
http://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]:443/
Additional information can be found in "RFC 2732 - Format for Literal IPv6
Addresses in URL's" and "RFC 3986 - Uniform Resource Identifier (URI): Generic
Syntax"
Network notation
IPv6 networks are written using CIDR notation.
An IPv6 network (or subnet) is a contiguous group of IPv6 addresses the size of
which must be a power of two; the initial bits of addresses, which are identical for all
hosts in the network, are called the network's prefix.
A network is denoted by the first address in the network and the size in bits of the
prefix (in decimal), separated with a slash. For example, 2001:0db8:1234::/48 stands
for the network with addresses 2001:0db8:1234:0000:0000:0000:0000:0000 through
2001:0db8:1234:FFFF:FFFF:FFFF:FFFF:FFFF
Because a single host can be seen as a network with a 128-bit prefix, you will
sometimes see host addresses written followed with /128.
Kinds of IPv6 addressses

IPv6 addresses are divided into 3 categories [7] :
Unicast Addresses
Multicast Addresses
Anycast Addresses
A Unicast address defines a single interface. It identifies a single network interface A
packet sent to a unicast address is delivered to that specific computer.
Multicast addresses are used to define a set of interfaces that typically belong to
different nodes instead of just one. When a packet is sent to a multicast address, the
protocol delivers the packet to all interfaces identified by that address. Multicast
addresses begin with the prefix FF00::/8, and their second octet identifies the
addresses scope, i.e. the range over which the multicast address is propagated.
Commonly used scopes include link-local (2), site-local (5) and global (E).
Anycast addresses, are also assigned to more than one interface, belonging to different
nodes. However, a packet sent to an anycast address is delivered to just one of the
member interfaces, typically the ―nearest‖ according to the routing protocol‘s idea of
distance. Anycast addresses cannot be identified easily: they have the structure of
normal unicast addresses, and differ only by being injected into the routing protocol at
multiple points in the network.
Special addresses
There are a number of addresses with special meaning in IPv6:

::/128 — the address with all zeros is an unspecified address, and is to be used
only in software.
::1/128 — the loopback address is a localhost address. If an application in a
host sends packets to this address, the IPv6 stack will loop these packets back
to the same host (corresponding to 127.0.0.1 in IPv4).
::/96 — the zero prefix was used for IPv4-compatible addresses; it is now
obsolete.
::ffff:0:0/96 — this prefix is used for IPv4 mapped addresses (see Transition
mechanisms below).
2001:db8::/32 — this prefix is used in documentation (RFC 3849). Anywhere
where an example IPv6 address is given, addresses from this prefix should be
used.
fc00::/7 — Unique local IPv6 unicast addresses are routable only within a set
of cooperating sites. They were defined in RFC 4193 as a replacement for site-
local addresses (see below). The addresses include a 40-bit pseudorandom
number that minimizes the risk of conflicts if sites merge or packets somehow
leak out.
fe80::/64 — The link-local prefix specifies that the address only is valid in the
local physical link. This is analogous to the Autoconfiguration IP address
169.254.x.x in IPv4.
fec0::/10 — The site-local prefix specifies that the address is valid only inside
the local organisation. Its use has been deprecated in September 2004 by RFC
3879 and systems must not support this special type of address.
ff00::/8 — The multicast prefix is used for multicast addresses[8] as defined
by in "IP Version 6 Addressing Architecture" (RFC 4291).
There are no address ranges reserved for broadcast in IPv6 — applications use
multicast to the all-hosts group instead.
IPv6 packet
The structure of an IPv6 packet header.
The IPv6 packet is composed of two main parts: the header and the payload.
The header is in the first 40 octets of the packet and contains both source and
destination addresses (128 bits each), as well as the version (4-bit IP version), traffic
class (8 bits, Packet Priority), flow label (20 bits, QoS management), payload length
in bytes (16 bits), next header (8 bits), and hop limit (8 bits, time to live). The payload
can be up to 64KiB in size in standard mode, or larger with a "jumbo payload" option.
Fragmentation is handled only in the sending host in IPv6: routers never fragment a
packet, and hosts are expected to use PMTU discovery.
The protocol field of IPv4 is replaced with a Next Header field. This field usually
specifies the transport layer protocol used by a packet's payload.
In the presence of options, however, the Next Header field specifies the presence of
an extra options header, which then follows the IPv6 header; the payload's protocol
itself is specified in a field of the options header. This insertion of an extra header to
carry options is analogous to the handling of AH and ESP in IPsec for both IPv4 and
IPv6.
IPv6 and the Domain Name System
IPv6 addresses are represented in the Domain Name System by AAAA records (so-
called quad-A records) for forward lookups; reverse lookups take place under ip6.arpa
(previously ip6.int), where address space is delegated on nibble boundaries. This
scheme, which is a straightforward adaptation of the familiar A record and in-
addr.arpa schemes, is defined in RFC 3596.
The AAAA scheme was one of two proposals at the time the IPv6 architecture was
being designed. The other proposal, designed to facilitate network renumbering,
would have had A6 records for the forward lookup and a number of other innovations
such as bit-string labels and DNAME records. It is defined in the experimental RFC
2874 and its references (with further discussion of the pros and cons of both schemes
in RFC 3364).
AAAA record fields

NAME Domain name
TYPE AAAA (28)
CLASS Internet (1)
TTL Time to live in seconds
RDLENGTH Length of RDATA field
RDATA String form of the IPV6 address as described in RFC 3513
RFC 3484 specifies how applications should select an IPv6 or IPv4 address for use,
including addresses retrieved from DNS.
IPv6 and DNS RFCs

DNS Extensions to support IP version 6 - RFC 1886
DNS Extensions to Support IPv6 Address Aggregation and Renumbering -
RFC 2874
Tradeoffs in Domain Name System (DNS) Support for Internet Protocol
version 6 (IPv6) - RFC 3364
Default Address Selection for Internet Protocol version 6 (IPv6) - RFC 3484
Internet Protocol Version 6 (IPv6) Addressing Architecture - RFC 3513
DNS Extensions to Support IP Version 6 (Obsoletes 1886 and 3152) - RFC
3596
IPv6 scope
IPv6 defines 3 unicast address scopes: global, site, and link.. Site-local addresses are
non-link-local addresses that are valid within the scope of an administratively-defined
site and cannot be exported beyond it.
Site-local addresses are deprecated by RFC 3879. Note that this does not deprecate
other site-scoped address types (e.g. site-scoped multicast).
Companion IPv6 specifications further define that only link-local addresses can be
used when generating ICMP Redirect Messages [ND] and as next-hop addresses in
most routing protocols.
These restrictions do imply that an IPv6 router must have a link-local next-hop
address for all directly connected routes (routes for which the given router and the
next-hop router share a common subnet prefix).
IPv6 deployment
In February 1999, The IPv6 Forum was founded by the IETF Deployment WG to
drive deployment worldwide creating by now over 30 IPv6 Country Fora and IPv6
Task Forces [9]. On 20 July 2004 ICANN announced[10] that the root DNS servers
for the Internet had been modified to support both IPv6 and IPv4.
A global view into the IPv6 routing tables, which displays also which ISPs are already
deploying IPv6, can be found by looking at the SixXS Ghost Route Hunter pages:
these pages display a list of all allocated IPv6 prefixes and give colors to the ones that
are actually being announced in BGP. When a prefix is announced, that means that
the ISP at least can receive IPv6 packets for their prefix. They might then actually
also offer IPv6 services, maybe even to end users/sites directly.
ISPs that provide IPv6 connectivity to their customers can be found in the Where can
I get native IPv6 FAQ.
The mandate by the United States Government to move to an IPv6 platform for all
civilian and defense vendors by summer 2008 will greatly boost deployment. The
awarding of over $150 billion in contracts in spring of 2007 by the General Services
Administration will in itself come close to the total amount spent on the Y2K upgrade
of the previous decade, and total cost will swell far beyond that, to as much as $500
billion.[11]
Transition mechanisms
Until IPv6 completely supplants IPv4, which is not likely to happen in the foreseeable
future, a number of so-called transition mechanisms are needed to enable IPv6-only
hosts to reach IPv4 services and to allow isolated IPv6 hosts and networks to reach
the IPv6 Internet over the IPv4 infrastructure. [12] contains an overview of the below
mentioned transition mechanisms.
Dual stack
Since IPv6 is a conservative extension of IPv4, it is relatively easy to write a network

stack that supports both IPv4 and IPv6 while sharing most of the code. Such an
implementation is called a dual stack, and a host implementing a dual stack is called a
dual-stack host. This approach is described in RFC 4213.
Most current implementations of IPv6 use a dual-stack. Some early experimental

implementations used independent IPv4 and IPv6 stacks. There are no known
implementations that implement IPv6 only.
Tunneling
In order to reach the IPv6 Internet, an isolated host or network must be able to use the
existing IPv4 infrastructure to carry IPv6 packets. This is done using a technique
somewhat misleadingly known as tunnelling which consists in encapsulating IPv6
packets within IPv4, in effect using IPv4 as a link layer for IPv6.
IPv6 packets can be directly encapsulated within IPv4 packets using protocol number
41. They can also be encapsulated within UDP packets e.g. in order to cross a router
or NAT device that blocks protocol 41 traffic. They can of course also use generic
encapsulation schemes, such as AYIYA or GRE.
Automatic tunneling
Automatic tunneling refers to a technique where the tunnel endpoints are

automatically determined by the routing infrastructure. The recommended technique
for automatic tunneling is 6to4[13] tunneling, which uses protocol 41 encapsulation.
Tunnel endpoints are determined by using a well-known IPv4 anycast address on the
remote side, and embedding IPv4 address information within IPv6 addresses on the
local side. 6to4 is widely deployed today.
Teredo [14] is an automatic tunneling technique that uses UDP encapsulation and is
claimed to be able to cross multiple NAT boxes. Teredo is not widely deployed today,
but an experimental version of Teredo is installed with the Windows XP SP2 IPv6
stack. IPv6, 6to4 and Teredo are enabled by default in Windows Vista [15].
Configured tunneling
Configured tunneling is a technique where the tunnel endpoints are configured

explicitly, either by a human operator or by an automatic service known as a Tunnel
Broker[16]. Configured tunneling is usually more deterministic and easier to debug
than automatic tunneling, and is therefore recommended for large, well-administered
networks.
Configured tunneling typically uses either protocol 41 (recommended) or raw UDP

encapsulation.
Proxying and translation
When an IPv6-only host needs to access an IPv4-only service (for example a web
server), some form of translation is necessary. The one form of translation that
actually works is the use of a dual-stack application-layer proxy, for example a web
proxy.
Techniques for application-agnostic translation at the lower layers have also been
proposed, but they have been found to be too unreliable in practice due to the wide
range of functionality required by common application-layer protocols, and are
commonly considered to be obsolete.
ROUTING INFORMATION PROTOCOL

(RIP)
INTRODUCTION
The DARPA Internet Architecture.
Internet Protocols
The Internet system consists of a number of interconnected packet networks

supporting communication among host computers using the Internet protocols. These
protocols include the Internet Protocol (IP), the Internet Control Message Protocol
(ICMP), the Transmission Control Protocol (TCP), and application protocols
depending upon them .
All Internet protocols use IP as the basic data transport mechanism. IP is a datagram,
or connectionless, internetwork service and includes provision for addressing, type-
of-service specification, fragmentation and reassembly, and security information.
ICMP is considered an integral part of IP, although it is architecturally layered upon
IP. ICMP provides error reporting, flow control and first-hop gateway redirection.
Reliable data delivery is provided in the Internet protocol suite by transport-level

protocols such as the Transmission Control Protocol (TCP), which provides end-end
retransmission, resequencing and connection control. Transport-level connectionless
service is provided by the User datagram Protocol (UDP).
Networks and gateways
Constituent networks may generally be divided into two classes.

Local-Area Networks (LANs)
Wide-Area Networks (WANs)
In the Internet model, constituent networks are connected together by IP datagram
forwarders which are called "gateways" or "IP routers".
A gateway is connected to two or more networks, appearing to each of these networks

as a connected host. Thus, it has a physical interface and an IP address on each of the
connected networks. Forwarding an IP datagram generally requires the gateway to
choose the address of the next-hop gateway or (for the final hop) the destination host.
This choice, called "routing", depends upon a routing data-base within the gateway.
This routing data-base should be maintained dynamically to reflect the current
topology of the Internet system; a gateway normally accomplishes this by
participating in distributed routing and reachability algorithms with other gateways.
gateways provide datagram transport only, and they seek to minimize the state
information necessary to sustain this service in the interest of routing flexibility and
robustness.
Autonomous Systems
For technical, managerial, and sometimes political reasons, the gateways of the
Internet system are grouped into collections called "autonomous systems" . The
gateways included in a single autonomous system (AS) are expected to
Be under the control of a single operations and maintenance (O&M)
organization;
Employ common routing protocols among themselves, to maintain their
routing data-bases dynamically.
A number of different dynamic routing protocols have been developed; the particular
choice of routing protocol within a single autonomous system is generically called an
interior gateway protocol or IGP.
An IP datagram may have to traverse the gateways of two or more autonomous

systems to reach its destination, and the autonomous systems must provide each other
with topology information to allow such forwarding. The Border Gateway Protocol
(BGP) is used for this purpose, between gateways of different autonomous systems.
Routing Information Protocol (RIP)
RIP is one protocol in a series of routing protocols based on the Bellman-Ford (or
distance vector) algorithm. This algorithm has been used for routing computations in
computer networks since the early days of the ARPANET. The particular packet
formats and protocol described here are based on the program "routed", which is
included with the Berkeley distribution of Unix. It has become a de facto standard for
exchange of routing information among gateways and hosts. It is implemented for this
purpose by most commercial vendors of IP gateways. Note, however, that many of
these vendors have their own protocols which are used among their own gateways.
This protocol is most useful as an "interior gateway protocol". In a nationwide

network such as the current Internet, it is very unlikely that a single routing protocol
will used for the whole network. Rather, the network will be organized as a collection
of "autonomous systems". An autonomous system will in general be administered by
a single entity, or at least will have some reasonable degree of technical and
administrative control. Each autonomous system will have its own routing
technology. This may well be different for different autonomous systems. The routing
protocol used within an autonomous system is referred to as an interior gateway
protocol, or "IGP". A separate protocol is used to interface among the autonomous
systems. The earliest such protocol, still used in the Internet, is "EGP" (exterior
gateway protocol). Such protocols are now usually referred to as inter-AS routing
protocols. RIP was designed to work with moderate-size networks using reasonably
homogeneous technology. Thus it is suitable as an IGP for many campuses and for
regional networks using serial lines whose speeds do not vary widely.
RIP is intended for use within the IP-based Internet. The Internet is organized into a
number of networks connected by gateways. The networks may be either point-to-
point links or more complex networks such as Ethernet or the ARPANET. hosts and
gateways are presented with IP datagrams addressed to some host. Routing is the
method by which the host or gateway decides where to send the datagram. It may be
able to send the datagram directly to the destination, if that destination is on one of the
networks that are directly connected to the host or gateway. However, the interesting
case is when the destination is not directly reachable. In this case, the host or gateway
attempts to send the datagram to a gateway that is nearer the destination. The goal of a
routing protocol is very simple. It is to supply the information that is needed to do
routing.
This protocol does not solve every possible routing problem. As mentioned above, it
is primary intended for use as an IGP, in reasonably homogeneous networks of
moderate size. In addition, the following specific limitations should be mentioned
The protocol is limited to networks whose longest path involves 15 hops. Note
that this statement of the limit assumes that a cost of 1 is used for each
network.
The protocol depends upon "counting to infinity" to resolve certain unusual
situations.
This protocol uses fixed "metrics" to compare alternative routes.
RIP Algorithm
Let's look at what happens when a datagram is sent from one source to a destination.
If the source and the destination are in the same autonomous system it is delivered by
the system's technology. But, if the destination is in another autonomous system the
datagram should be transferred to that autonomous system. There it will be delivered
by that system technology. routers are the ones that should do the transferring.
Therefore, they should know all the autonomous systems in the supernet. When they
receive a datagram addressed to autonomous system `A' they should transfer it to `A'.
A trivial way to implement a router is having one router that is connected to all
autonomous systems. However this is not practical.
A more practical way is having many routers. Each connected to few autonomous
systems. Let a datagram be sent from one autonomous system to another. The router
of the first autonomous system would transfer the datagram to that autonomous
system (if it can), or transfer it to another router, that knows how to reach the
destination. Eventually the datagram will reach a router that has a connection to that
autonomous system and the datagram will be transferred correctly.
This way requires each router to hold a database of all the possible destinations. Each
entry in the database should hold the next router that datagrams should be sent to.
This way could have worked very well. Alas, the network cannot be kept still. New
routers can be installed Old routers can crash. Crashed router can come up. Therefore,
our connection through a router is not guaranteed. Even if the router doesn't crash, a
new router may be installed, providing better service.
Before we continue this discussion, we have to make few things clearer. We have to
define what we mean by saying that one line is better than the other. There are many
ways to measure a connections. You can measure it by the Dollar cost, number of
hops in the way, error rate, latency, etc. We will assume that connection are measured
by the number of hops in its path. This assumption is no way, obligatory and any
system administrator can define a measure of his own. We will treat measure as costs.
That means that the lower the number associated with the connection, the better. RIP
treats any number higher than fifteen as infinity (sixteen). So, sixteen means 'no
connection'. This method of calculating the cost is called metric.
Let d( i , j ) be the cost of the direct link from i to j .
d( i , i ) = 0 for any i .
Let D( i , j ) be the cost of the best route from i to j . It is defined for any two entities i
,j.
D( i , i ) = 0 for any i .
D( i , j ) = min [d( i , k ) + D( k , j )] for i <> j
The last equation can be proven using induction over the number of steps in the
routes. The metrics can be calculated using a simple algorithm. Entity i gets its
neighbor k to send their estimates of their distance from j . When i gets the estimates
from k , it adds d( i , k ) to each of the numbers. Then i picks the smallest value. A
proof that this algorithm converges to the correct values of D( i , j ) in finite time,
when the network topology does not change. Very few assumption were made about
the order in which the entities send each other their information. No assumption were
made on the initial values of D( i , j ), except that they have to be non-negative. That
means that it is safe to run the algorithm asynchronously. Entities can send updates by
their own clock. Updates may be dropped, as long as they don't get all dropped.
Because there are no assumptions on the initials values, the algorithm handles
changes. when the topology changes, the system will move to a new equilibrium
using the old one as its starting point.
Once a router is installed, or started, it should send messages to all of its neighbors.
This is necessary in order to update their tables. Consider this case:
A was connected to D through B and C . Once E has been installed, A can connect to
D through E . This line costs less. That's why E has to announce its existence to A . If
E should ever crash, A must know about it. Otherwise it will continue to send
datagram s through E . Unfortunately, a router can't always inform others, that it is
about to crash. A router can't depend on such message to warn it.
Therefore a router crash, must be learned in other ways. RIP forces a router to send
update messages every thirty seconds. These messages contain routes, that that router
knows; and their metrics. If a router does not receive an update message for 180
seconds. from another router. It assumes that router to be unreachable. This timeout of
180 seconds allow a router to miss five update messages, without being marked
unreachable. This is necessary, because the media might be unreliable and loose
datagrams.
The algorithm so far, sends update messages every thirty seconds. Every update
message contains a list of the autonomous system the routers knows to reach and their
metrics. If the metric in an update message is lower than the metric in the router 's
table, the router would update the metric and the next hop fields in its table. If for
some destination, an update had come from the next hop, indicating a different metric,
then the metric in the table should be changed. This is necessary because if the metric
changes in the next hop, we must change the metric in our router, as well. This
guarantees correct performance, but not good enough. Consider this case:
All links have cost of 1, except for the direct link from C to B which has cost 10. Each
router will have a table showing the next hop and the metric for each destination.
We're interested only in the connection to the target network.
D : directly connected, metric 1.
B : connected via D , metric 2.
C : connected via B , metric 3.
A : connected via B , metric 3.
Now suppose that the link from B to D fails. The routes should adjust to use the link
from C to D . Unfortunately it will take quite a while for this to happen. The routing
changes start when B notices that the route to D is no longer usable. The chart below
assumes that all router s send updates at the same time. the chart shows the metrics for
the target.
time --->
B : unreachable | C , 4 | C , 5 ....
C: B, 3 | A,4| A,5
A: B, 3 | C,4| C,5
The problem is that A and C both believe they can connect to the target through each
other. It happened because they sent messages indicating they can connect to the
target at cost of 3. When they received the message from B saying that the target is
unreachable, they received another message. The second message said they can
connect to the target in cost of 3. This cost is of course not true, because the link from
B to D is unusable. Since A and C don't know that the route from each other uses
another link that is no longer usable, they would both update their tables to point at
each other. Since, they increase the metric by one, they will both report that the cost is
now four. Since A uses C as next connection, and C signals that the cost had change,
A would change the cost of the link. Same thing would happen to C . This way the
cost of the connection will slowly rise. The worst case is when the target is really
unusable, and then the cost will rise up to infinity. This effect is called 'counting to
infinity'. This is why infinity was chosen to be such a small number. If some
autonomous system becomes completely unreachable, we would like the counting to
be over as soon as possible.
There are several ways to prevent this from happening. The ones that RIP uses are
called 'split horizon with poison reverse' and 'triggered update'.
Split horizon.
Notice that the problem above is caused because both A and C deceive each other.
They both claim they have a connection. Since they both think they can connect
through each other, a real link is not established. This could have been prevented if A
hadn't told C that it can connect to the target. Generally, it is not useful to claim
reachability for a destination to the neighbor from which the route was learned. The
"simple split horizon" omits routes learned from one neighbor in updates to that
neighbor. "split horizon with poisoned reverse" include those routes but with cost of
infinity.
If A thinks it can get to D through C its message to C should indicate that D is

unreachable. If C still claim reachability to D , then either it is connected directly to D
, or it knows another router that claim reachability. C 's route to the destination cannot
go back to any route that points to C .
In general, split horizon with poisoned reverse, is safer than simple split horizon. If
two routers point at each other, advertising reverse routes with metric of 16 will brake
the loop immediately. If the reverse routes are simply omitted, those routes will have
to be eliminated by waiting for a timeout. Alas, poisoned reverse increases the size of
the messages. Consider the case of a campus backbone connecting many buildings.
Each building has a router. In simple split horizon only the network that is connected
to the router is included in the updates messages. In split horizon with poisoned
reverse, ALL networks learned must be published as well.
Implementors may use simple split horizon if they like. Or they can offer a
configuration option, to allow the system manager to choose which way to use. It is
also possible to advertise some reverse routes with metric of sixteen, and omit others.
Triggered updates
Split horizon with poisoned reverse will break any loop of two router s. However, it is
still possible for loops of three or more router s, to occur. A may think it can reach the
target through B . B may think it can reach the target through C . C may think it can
reach the target through A . This loop will break only when infinity will be reached.
Triggered updates are an attempt to speed up this convergence. To imply triggered
updates, we simply add a rule that whenever a router changes the metric of a route, it
is required to send update messages almost immediately. The triggered update
messages will be sent even if it is not time to the regular update message. Consider a
case were G can connect to a target network, and then its link becomes unusable. G
will send its neighbor updates about the change. Its neighbors will update their tables
if necessary. The ones that updated their tables will send their own update messages.
Some of the neighbors' neighbors will update their tables, and send their own update
messages. The update messages will propagate back, until they reach a portion of the
network that uses another route to connect to the target.
If the system could be made to stay still while the update messages propagate back, it
had been possible to prove that counting to infinity would never happen. A bad router
will be removed from the tables, using update messages. Alas, this is not the case.
While the triggered updates are being sent, regular updates can be sent, from router
who hasn't got the update yet. Their update will indicate that the target is still
reachable. It is possible that a router will receive a false regular update saying the
target is reachable, after it received a triggered update saying the target is
unreachable. This could reestablish a connection incorrectly. Triggered updates
reduce the chance to get counting to infinity, however this can still happen.
Format of RIP Datagram:
The format of the RIP header is shown here:

8B + 4B + 25x20B = 512 B
UDP Header RIP Header RIP Data
Octet +0 Octet +1 Octet +2 Octet +3
COMMAND VERSION UNUSED (SET TO ZERO’S)
ADDRESS FAMILY IDENTIFIER UNUSED (SET TO ZERO’S)
IP ADDRESS
UNUSED (SET TO ZERO’S)
UNUSED (SET TO ZERO’S)
METRIC
Each word (line) is 32 bits

The fields size (e.g, (1) ) are in octets
The portion of the datagram from address family field through metric may appear up
to 25 times. IP address is the usual 4-octet Internet address, in network order. The
special address 0.0.0.0 is used to describe a default route. The address family
identifier for IP is 2. The metric field must contain a value between 1 and 15
inclusive, specifying the current metric for the destination, or the value 16, which
indicates that the destination is not reachable. The maximum datagram size is 512
octets. (IP or UDP headers not counted) Every datagram contains a command, a
version number, and possible arguments.
Here is a summary of the commands implemented in version 1 of RIP:
Request A request for the responding system to send all or part of its routing
table.
Response A message containing all or part of the sender's routing table. This
message may be sent in response to a request or poll, or it may be an update
message generated by the sender.
Traceon Obsolete. Messages containing this command are to be ignored.
Traceoff Obsolete. Messages containing this command are to be ignored.
Teserved This value is used by Sun Microsystems for its own purposes. If new
commands are added in any succeeding version, they should begin with 6.
Messages containing this command may safely be ignored by implementations
that do not choose to respond to it.
Addressing considerations
The RIP packet formats do not distinguish among various types of address. Fields that
are labeled "address" can contain any of the following:
host address
subnet number
network number
0, indicating a default route
When routing a datagram , its destination address must first be checked against the list
of host addresses. Then it must be checked to see whether it matches any known
subnet or network number. Finally, if none of these match, the default route is used.
"Border" gateway s send only a single entry for the network as a whole to host s in
other networks. This means that a border gateway will send different information to
different neighbors. For neighbors connected to the subnetted network, it generates a
list of all subnets to which it is directly connected, using the subnet number. For
neighbors connected to other networks, it makes a single entry for the network as a
whole, showing the metric associated with that network. (This metric would normally
be the smallest metric for the subnets to which the gateway is attached.)
Timers
Every 30 seconds, the output process is instructed to generate a complete response to

every neighboring gateway .
There are two timers associated with each route, a "timeout" and a "garbage-
collection time". Upon expiration of the timeout, the route is no longer valid.
However, it is retained in the table for a short time, so that neighbors can be notified
that the route has been dropped. Upon expiration of the garbage-collection timer, the
route is finally removed from the tables.
The timeout is initialized when a route is established, and any time an update message
is received for the route. If 180 seconds elapse from the last time the timeout was
initialized, the route is considered to have expired, and the deletion process which we
are about to describe is started for it.
Deletions can occur for one of two reasons: (1) the timeout expires, or (2) the metric
is set to 16 because of an update received from the current gateway . (See response
command for a discussion processing updates from other gateway s.) In either case,
the following events happen:
- The garbage-collection timer is set for 120 seconds.
- The metric for the route is set to 16 (infinity). This causes the route to be removed
from service.
- A flag is set noting that this entry has been changed, and the output process is
signalled to trigger a response.
Until the garbage-collection timer expires, the route is included in all updates sent by
this host , with a metric of 16 (infinity). When the garbage-collection timer expires,
the route is deleted from the tables.
Should a new route to this network be established while the garbage- collection timer
is running, the new route will replace the one that is about to be deleted. In this case
the garbage-collection timer must be cleared.
Input processing
Before processing the recived datagram s, certain general format checks must be
made. These depend upon the version number field in the datagram , as follows:
0 datagram s whose version number is zero are to be ignored. These are from a
previous version of the protocol, whose packet format was machine-specific.
1 datagram s whose version number is one are to be processed as described in
this document. All fields that are described above as "must be zero" are to be
checked. If any such field contains a non-zero value, the entire message is to
be ignored.
>1 datagram s whose version number are greater than one are to be processed
as described in the rest of this specification. All fields that are described above
as "must be zero" are to be ignored. Future versions of the protocol may put
data into these fields. Version 1 implementations are to ignore this extra data
and process only the fields specified in this document.
After checking the version number and doing any other preliminary checks,
processing will depend upon the value in the command field.
Output processing
Let describe the processing used to create response messages that contain all or part of
the routing table. This processing may be triggered in any of the following ways
- by input processing when a request is seen. In this case, the resulting message is sent
to only one destination.
- by the regular routing update. Every 30 seconds, a response containing the whole
routing table is sent to every neighboring gateway
- by triggered updates. Whenever the metric for a route is changed, an update is
triggered. (The update may be delayed.)
Triggered updates require special handling for two reasons. First, experience shows
that triggered updates can cause excessive loads on networks with limited capacity or
with many gateway s on them. Thus the protocol requires that implementors include
provisions to limit the frequency of triggered updates. After a triggered update is sent,
a timer should be set for a random time between 1 and 5 seconds. If other changes that
would trigger updates occur before the timer expires, a single update is triggered
when the timer expires, and the timer is then set to another random value between 1
and 5 seconds. Triggered updates may be suppressed if a regular update is due by the
time the triggered update would be sent.
Second, triggered updates do not need to include the entire routing table. In principle,
only those routes that have changed need to be included. Thus messages generated as
part of a triggered update must include at least those routes that have their route
change flag set. They may include additional routes, or all routes, at the discretion of
the implementor; however, when full routing updates require multiple packet s,
sending all routes is strongly discouraged. When a triggered update is processed,
messages should be generated for every directly-connected network. Split horizon
processing is done when generating triggered updates as well as normal updates.
If, after split horizon processing, a changed route will appear identical on a network as
it did previously, the route need not be sent; if, as a result, no routes need be sent, the
update may be omitted on that network. (If a route had only a metric change, or uses a
new gateway that is on the same network as the old gateway , the route will be sent to
the network of the old gateway with a metric of infinity both before and after the
change.) Once all of the triggered updates have been generated, the route change flags
should be cleared.
If input processing is allowed while output is being generated, appropriate

interlocking must be done. The route change flags should not be changed as a result of
processing input while a triggered update message is being generated.
The only difference between a triggered update and other update messages is the
possible omission of routes that have not changed. The rest of the mechanisms about
to be described must all apply to triggered updates.
Here is how a response datagram is generated for a particular directly-connected

network:
The IP source address must be the sending host 's address on that network. This is
important because the source address is put into routing tables in other host s. If an
incorrect source address is used, other host s may be unable to route datagram s.
Sometimes gateway s are set up with multiple IP addresses on a single physical
interface. Normally, this means that several logical IP networks are being carried over
one physical medium. In such cases, a separate update message must be sent for each
address, with that address as the IP source address.
Set the version number to the current version of RIP.

Set the command to response. Set the bytes labeled "must be zero" to zero. Now start
filling in entries. To fill in the entries, go down all the routes in the internal routing
table. Recall that the maximum datagram size is 512 bytes. When there is no more
space in the datagram , send the current message and start a new one. If a triggered
update is being generated, only entries whose route change flags are set need be
included.
Routes to subnets will be meaningless outside the network, and must be omitted if the
destination is not on the same subnetted network. they should be replaced with a
single route to the network of which the subnets are a part. Similarly, routes to host s
must be eliminated if they are subsumed by a network route.
If the route passes these tests, then the destination and metric are put into the entry in
the output datagram . Routes must be included in the datagram even if their metrics
are infinite. If the gateway for the route is on the network for which the datagram is
being prepared, the metric in the entry is set to 16, or the entire entry is omitted.
Omitting the entry is simple split horizon. Including an entry with metric 16 is split
horizon with poisoned reverse.
RIP Version 2
Rip 2 is an extension of the Routing Information Protocol (RIP), as defined in the
previous sections. Its purpose is to expand the amount of useful information in the
RIP packets and to add security elements.
The justifications of maintaining old RIP in a world of newer and stronger routing
protocols are mainly its vast distribution and its small overhead requirements both in
bandwidth and in configuration and management time. In addition, RIP is very easy to
implement, especially in relation to the newer IGPs. Under the assumption that RIP
will remain in service for some more years, there were people who thought it was
reasonable to increase RIP's usefulness, especially since the gain looked far greater
than the expense of the change.
Recently, RIP version 2 became the standard version of RIP, and the original RIP is
now historic.
The main disadvantages of RIP version 1 are the minimal amount of information
included in every packet, the large amount of unused space in the header of each
packet and the ignorance from implementations and topics which postdated RIP 1.
Namely, autonomous systems and basically EGP interactions, sub-netting, and
authentication.
The RIP 2 datagram format is:
8B + 4B + 25x20B = 512 B
UDP Header RIP Header RIP Data
Octet +0 Octet +1 Octet +2 Octet +3
COMMAND VERSION ROUTING DOMAIN
ADDRESS FAMILY IDENTIFIER ROUTE TAG
IP ADDRESS
SUBNET MASK
NEXT HOP
METRIC
The Command, Address Family Identifier (AFI), IP Address, and Metric all have the
same meanings as in RIP 1. The Version field specifies version number 2 for RIP
datagrams which use authentication or carry information in any of the newly defined
fields.
In RIP 2 there is an optional authentication mechanism. When in use, this option

abuses an entire RIP entry, and leaves space to at most 24 RIP entries in the
remainder of the packet. The most widespread authentication Type is simple password
and it is type 2.
The Routing domain field enables some routing domains inter-work upon the same
physical infrastructure, while logically ignoring each other. This gives the ability to
simply implement various kinds of policies. There is a default routing domain which
is assigned the value '0'.
The Route Tag (RT) field exists as a support for EGP's. This field is expected to carry
Autonomous System numbers for EGP and BGP. RIP systems which receive RIP
entry which contains a non-zero RT value must re-advertise that value.
The Subnet Mask field contains the subnet mask which is applied to the IP address to
yield the non-host portion of the address. If this field is zero, then no subnet mask is
included for this entry.
Next Hop is the immediate next hop IP address to which packets to the destination
specified by this route entry should be forwarded. The purpose of the Next Hop field
is to eliminate packets being routed through extra hops in the system. It is particularly
useful when RIP is not being run on all of the routers on a network.
Multi-casting is an optional feature in RIP 2 using IP address 224.0.0.9. This feature
reduces unnecessary load on those hosts which are not listening to RIP 2. The IP
multi-cast address is used for periodic broadcasts. In order to maintain backwards
compatibility, the use of the multi-cast address is configurable.
RIP 2 is totally backwards compatible with RIP 1. Its applications support fine tuning
to be RIP 1 emulation, RIP 1 compatible, or fully RIP 2.
OPEN SHORTEST PATH FIRST
Open Shortest Path First

What is IP routing?
When several networks are joined together by hosts that are connected to more than
one network, hosts on one network may want to communicate with hosts on another
network. To do so, the messages between them must pass through several (i.e. more
than one) networks on the way. This is accomplished by turning some hosts with
connections to more than one network into routers, which forward messages to the
networks they can reach (to which they are connected).
Each router has a routing table, which specifies where that router should send a
message it receives. In IP routing, the routing table will usually consist of a network
address (and a subnet mask) and the address of the "next hop", which is the target to
which the message should be forwarded if the destination's IP address matches the
subnet mask of the network address. The next hop can be a local network to which the
router is connected physically, or the IP address of another router on the network,
which will then continue forwarding that message according to its own routing table.
If the routers are set up correctly and the network is healthy, eventually the message
will reach its destination.
Static routing
In relatively small networks, or in networks where the network topology rarely

changes, setting up the routing tables can be done manually. This means that in the
event of a malfunction in one of the routers or of a network, the other routers will not
know about the problem and will not circumvent it until someone, usually the network
administrator, will reconfigure each and every one of them with the new settings.
While this might turn out to be an impossible task for most networks, static routing is
still a viable solution in some cases.
Dynamic routing
Things get complicated when the conditions aren't ideal, and they rarely are.
Networks tend to grow, evolve and change, hardware usually isn't impregnable, and
errors tend to occur on computer networks, especially large ones, in such high
frequencies that manually reconfiguring everything every time can be quite
impossible. This is where dynamic routing comes into play.
In dynamic routing, the routers themselves, by communicating with one another, learn
the topology of the network by themselves. By running the same dynamic routing
protocol they can get that information and build their routing tables automatically, and
respond to changes in the network much faster than a manual update ever could.
In dynamic routing protocols, routers communicate with neighboring routers, i.e.

routers that are connected to the same networks that they are. The protocol dictates
what information they exchange and when, how the information will be saved on each
router, and how the routing table can be constructed from it. We will now be talking
about dynamic routing protocols of a certain kind: dynamic IGPs.
The Internet is constructed of many networks, and is divided into autonomous

systems (rather than single networks). An autonomous system is a network or several
connected networks which are controlled by a single entity. For example, a large
corporation's network can be defined as an Autonomous System (named AS, for
short). Within each autonomous system routing is done separately from other
autonomous systems, and there is also routing between autonomous systems. The
latter kind of routing is standardized throughout the Internet, and is uniformly
preformed by running a protocol named BGP (Border Gateway Protocol). IGPs are
protocols for routing within a single autonomous system (IGP stands for Interior
Gateway Protocol). These protocols define how to route to networks within the AS,
and can also distribute routing information for networks outside the AS (that
information will come, naturally, from the routers at the edges of the AS, which also
run the BGP protocol).
Unlike in intra-AS routing, where there is a clear standard (the BGP routing protocol),
there is no single standard for inter-AS routing. The most wide-spread IGP protocol is
the RIP protocol. That protocol, however, is showing signs of aging and is not
suitable for large networks. OSPF is an IGP which is designed to replace RIP, at least
for large networks.
Link-state vs. distance-vector
IGPs usually work according to the principles of one of the following known
problems: the link-state problem and the distance-vector problem. For example, RIP
works on the principles of the distance-vector problem, and OSPF works on the
principles of the link-state problem.
The both problems solve the problem of a graph, whose vertices "want" to know the
shortest path from them to every other vertex in the graph. When thinking about the
network as a graph of connected hosts, the resemblance is clear: we'd always like to
find the shortest route to a host, and send our message to it via that route.
The distance-vector solution works by keeping, for each vertex, a vector of distances
from it to every other vertex in the graph. The vector starts empty, and, by running an
algorithm to solve the problem, it is updated with shorter and shorter routes until a
stable state is reached and the vector converges. Each vertex only knows of its
immediate neighbors, and by exchanging their distance vectors between them the
solution is reached together.
The link-state solution works by gathering the graph's topology information from all
the vertices on it, so that every vertex eventually learns the entire topology of the
graph. Then, from that topology, each vertex can calculate for itself, independently,
the shortest path to every other vertex, by running an algorithm.
It's true - the distance-vector solution sounds like a much nicer concept: routers
working together, in unity, to reach a common goal. How ideal, compared to the
selfish and almost anti-social link-state, where each vector grabs the topology
information and then goes off to a corner and calculates his own distances in solitary.
In reality, however, the link-state solution has proven to be a much more efficient
solution, and convergence is reached much fasted this way, and that is why it is set to
replace distance-vector-based protocols, at least for large unstable networks where
RIP's inefficiency can create a perpetual state of non-convergence.
The reasons for creating OSPF
So why was OSPF created? one reason was already stated: it employs the faster link-
state solution, and is thus more suitable for larger networks than RIP. But there are
more reasons than that.
The original RIP protocol isn't suitable at all anymore to the modern networks and the
Internet, as it lacks support for subnet masking, so RIP version 2 was created which
improves the situation quite a bit, but still hasn't cured RIP from it's problems: The
RIP protocol is slow to converge (for networks with fast and constant change, it might
never become stable), its own protocol traffic bites a significant chunk off the total
bandwidth, and its metrics system (its way of telling the distance between routers is
by counting the networks between them, regardless of line quality or physical length)
limits the network's size: a distance of 16 hops from a router is considered infinity, so
a network running RIP can only grow so long as the longest distance between its
routers is less than 16 hops, which means the protocol doesn't scale well.
OSPF was created to overcome all those shortcomings, and to enable support for
many options:
OSPF is one of the first IGPs that can create separate routing tables for each
type of service.
OSPF supports CIDR and subnetting.
When several routes to a destination exist, OSPF can create a load balance by
using both routes intermittently.
OSPF is open source and offers support for multi-vendor hardware (whereas
some IGPs are proprietary and/or for certain types of hardware from certain
vendors).
OSPF can run on broadcast networks and on non-broadcast networks.
OSPF brings to a minimum the protocol traffic.
Frequently used terms and their meaning
Router - A device connected to two or more networks, whose purpose is the delivery
of IP packets, of which it is not the source nor the destination.
Network Neighbors - two routers R1 and R2 are neighbors if there exists some
physical network N, to which both R1 and R2 are connected. i.e. the following occurs
:
Interface - We say that some device D has an interface to some physical network N,
if D is connected to the network N. Usually, in internets, when a device has an
interface to some physical network, the interface is uniquely identified by an IP
address.
Point-to-Point network - A network between two devices. A link connecting those

two devices.
Broadcast - Sending a packet in a network, so that every device which is attached to

the network will receive it.
Multicast - Sending a packet in a network, so that a specific set of devices that are
attached to the network will receive it.
Autonomous System (AS) - A group of networks that are connected to each other
and use the same Interior Gateway Protocol. Usually, an internet is divided into
multiple Autonomous Systems.
MTU - (Maximum Transfer Unit) The maximum amount of data, which can be sent
on a physical network without being fragmented.
Unicast - Sending a packet from one specific device to another specific device.
OSPF: Overview
OSPF is a protocol that runs in the Transport Layer (OSPF runs over IP), and its
protocol number in the IP datagram is 89.
OSPF is an Interior Gateway Protocol, which means that it is used by all the routers
inside the same Autonomous System in order to route packets inside the AS. In an
internet, which is divided into several AS's, the routing between 2 hosts on different
AS's is done as follows: first, the packet is sent from the original host to some Border
Router using the Interior Gateway Protocol (IGP). The Border Router uses Border
Gateway Protocol (BGP) to route the packet to the AS of the destination. Inside that
AS, the packet is routed through the IGP of that AS.
The general idea behind OSPF is the following:
OSPF is a link-state routing protocol, which is based on the SPF (Shortest Path First)
algorithm to find the least cost path to any destination in the network.
Each router sends the list of his neighbors to all the other routers. When a router has
received that information from all other routers, it is ready to deduce the topology of
the network, which will enable it, through the use of the Dijkstra algorithm, to find the
least-cost path to any IP address on the entire network.
OSPF can be described as follows:
In OSPF, each router maintains a database that describes the current topology of the
network. However, since OSPF is run inside ASs and since ASs can be very large,
there is a division of ASs into small sets of networks which are called "Areas". The
main idea is that each router should maintain a database of the topology of the area in
which it resides.
This database is maintained in the following way:

At first, when a router comes online, it uses some protocol (The Hello Protocol) to
find his network neighbors and the cost it takes to reach each neighbor. This
information is referred to as the link-state information of the router. When, this is
done, each router floods his list of neighbors (Link State Advertisement) throughout
the entire area until all the routers have received it. This is continued until all the
routers in the area, have the list of neighbors from all the other routers.
When this process is done, each router has in its database some representation of the
topology of the area - each router has the list of neighbors of all other routers. This
information is sufficient to know the exact topology of the area, and in addition, it can
be used to build a routing table, to route packets inside the area using the best path
(The path which is the most suitable for the Type Of Service needed by the packet
which is to be delivered).
Whenever a change in the topology occurs (A router goes down, a new router comes
up), this change is quickly discovered using a protocol (Again, the use of the Hello
Protocol), and the router who discovered this change, changed his database, and
updates all the routers in the area by flooding the update throughout the network. This
ensures that all the routers in the same area have the same database.
In order to flood link state information throughout the area, OSPF introduces the
notion of Designated Routers. Once Designated Routers have been selected, whenever
some router want to send link state information, he will transfer it to the Designated
router in an exchange protocol. Next, the designated router will transfer the
information to all the other routers.
When all the routers are synchronized (All the routers have the same information in
their database), they use the Dijkstra algorithm and build a shortest path tree, whereas
shortest path means the least cost path (The quickest path to route a packet). In the
case where there are more than one path to the same destination with the same cost,
all the paths to the destination with the least cost are saved in the tree. This is later
used for load balancing when routing packets. In addition, there can be a few such
trees, each for a specified Type Of Service of packets, due to the fact that each Type
Of Service, can have a different definition of a cost of a path. (For example, when
routing packets of digital video, we would prefer a route with a very small delay).
The shortest-path tree (or trees) is later used to build the routing table of each router.
Some advanced features of OSPF:
OSPF supports router authentication before exchange of Link State
information. This enables other routers to verify that the Link State
information they have received, was sent by an authenticated router. This
feature is intended to prevent malicious users from interfering in the creation
of routing tables.
OSPF supports subnetting and supernetting - in OSPF each network is
identified by both an IP address and a subnet mask.
Differences between OSPF 1 and OSPF 2
Added Support for Stub Areas - Stub Areas are areas that are connected to
other areas through a single entry point, i.e. there exists only a single Area
Border Router. Therefore, routers inside Stub areas do not need to know
anything about other areas, since all packets whose destination is outside the
area, will be routed to the single Area Border Router. Therefore, a new option
was added which supports routers in stub areas so that no information about
other areas would be saved in their topology database.
OSPF enables routers not to route according to Type Of Service of packets - In
contrast to OSPF version 1 where all routing was according the Type Of
Service, in OSPF version 2, routers can be configured to create only 1 routing
table and not different tables for every Type Of Service.
OSPF version 2 introduces fixes to many problems which occurred in the
original OSPF.
In order to support all the changes and fixes, there was a need to change the
packet formats and the encoding of certain parameters (for example, there was
a change in the encoding of different Types of Service).
The topology database
As was already mentioned earlier, each OSPF router must keep a database, which
holds information that enables to construct the topology of the network from it.
Before actually starting to explain how the information is gathered, let's examine the
method of representing the network topology, i.e. the structure of the topology
database.
In the OSPF protocol, the topology of the AS is represented as a directed graph,

which the database describes. The vertices in the graph represent the routers and
networks in the AS: there's a single vertex for each router and for each network. The
directed edges in the graph represent the connections between routers and networks.
An edge connects either between two routers, or between a router and a network.
An edge connecting two router-vertices indicates that the two routers are directly
connected to each other (physical point-to-point connection). For such a directed edge
from router A to router B, there will almost always be another directed edge in the
other direction, since most point-to-point connections are bi-directional.
An edge connecting a router-vertex and a network-vertex indicates that that router has
an interface on that network, i.e. that it is connected to that network and has an
address on it.
Also note that there are two types of networks in the AS: networks that can and will
carry traffic going through them but which is not originated in them and nor is it for
them, and networks that will not do this. The former kind are called "Transit"
networks, and the latter kind are called "Stub" networks. Note that stub networks will
only have incoming edges and never outgoing edges.
One of OSPF's advantages over older protocols is its support of cost metrics. For each
of the output interfaces a router has on the networks it's connected to, we associate a
cost. The protocol, by trying to find the shortest path (i.e. the path with the lowest
total cost along its path), indicates that the lower the cost, the higher the probability
that that router interface will be used for data transfer. The costs can be determined by
the network administrator without reason, but, more often than not, they are a direct
derivation of the quality and speed of the connection to the network, so as to provide
better utilization of the networks.
The topology database in each router holds information that enables it to create a
directed graph that represents all the components of the AS. The database is in fact a
table, in which there is a row and a column for each vertex. A number X appearing in
column A and row B means that the graph has a directed edge from the vertex A to
the vertex B, with the cost X.
An example: For the network described by the following image :
The topology database is the following:
How routers establish neighbors
Every OSPF router maintains three tables: the neighbors table, the topology table, and
the routing table. The neighbors table lists all of the neighboring routers of the router,
i.e. all the other routers that are connected to one or more of the networks that the
router is connected to. The neighbors are discovered dynamically via the Hello
protocol, and then they start exchanging topology information, which is kept in the
topology table (whose structure was discussed in the previous section). Then the
algorithm for finding the shortest paths is run on the topology graph, and the routing
table is built. All of these operations will be discussed in their order of happening, and
first, the building of the neighbors table.
Identifying routers
Beyond the difficulty of exchanging topography information and the constant need to
keep it updated, the task would be tenfold more difficult if routers were misidentified.
For example, imagine two networks and two routers, and the two routers are
connected to both routers. On each network, each host has an IP address, so the
routers have two different IPs.
R1 will find that, on the first network, 1.0.1.2 is an OSPF router (how? We'll come to
that soon), and mark it as its neighbor on that network. On the second network, R1
will find that 2.3.18.2 is an OSPF router, and will mark it as its neighbor on that
network. So now R1's neighbors table contains two entries, and R1 has no idea that
they are both R2, which means that its view of the network is twisted and will not be
easily fixed (for example, if a third router on the second network reports that it's
connected to a third network, then R1 will know that 2.3.18.2 has access to that third
network also, but 1.0.1.2 doesn't have, in R1's tables, a connection to that network).
Therefore arises a need to uniquely identify every router, by attaching to each router a
unique router ID. From now on every router will be identified by its router ID and not
by it's IP address on a certain network, and such irregularities as were just described
would be avoided.
How is the router ID selected uniquely? The moment a router becomes active, it scans
all of its interfaces to discover to what networks it's currently connected and what is
its IP address on each network. Also, some routers have loopback IP addresses, and if
it has any it looks at them too. Now, if the router has at least one loopback address,
the router will choose the highest loopback address and that will become its router ID.
If the router has no loopback address, it will select the highest IP address of his
various interfaces in the AS, and that will become its router IP. It's important to
remember that this process only occurs when the router becomes active, and does not
repeat as long as the router is active. This means that even if, at a later stage, the
router is connected to another network and gets an even higher IP address, the router
ID will not become that address (as that would involve updating the records of all the
other routers). The router ID, once determined, is fixed for the duration of the
operation of the router.
Discovering neighbors
When a new OSPF router is attached to a network, it will try to discover neighboring
routers on that network by running the Hello protocol, which is also responsible for
maintaining neighbors (i.e. making sure they're still active). The Hello protocol uses
packets named "Hello packets" to announce new neighbors and establish bi-
directional neighbor relationship between other neighboring routers by changing the
state of the relationship as more information is gathered.
Before describing the structure of the Hello packet and the operation of the Hello
protocol, it's important to note the difference in operation between running it on
broadcast networks and non-broadcast (NBMA) networks, since from this point on
the explanation will refer to running in on broadcast networks for simplicity's sake
(the operation is the same on both types, but the overhead is higher). On non-
broadcast networks running the Hello protocol (and therefore running OSPF) requires
extra configuration for enabling it to do its job. Each router that will possibly become
the DR (Designated Router, which will be discussed later) needs to have a list of all
the routers on that network. It will then begin the DR election process as usual (the
process will be discussed later) with those routers that may also become the DR, and
then continue with running the Hello protocol with each of its neighbors. From this
point on the description will be for broadcast networks or point-to-point connections
(between two routers). In broadcast networks with multicasting capabilities, the Hello
packets are always directed to the address 224.0.0.5, which is the multicast address of
all the OSPF routers on that network. In broadcast networks with no multicast
capabilities, the Hello packets are just broadcasted to everyone.
The Hello packet's structure is as follows:
The first 24 bytes of the packet are common to all OSPF packets, and are named the
"OSPF message header". The packet fields are:
Version Number - the version of the OSPF protocol. For OSPF 2, it will have
the value "2".
Type - the type of the OSPF packet. As mentioned, all OSPF packets share the
first 24 bytes, so the Type field indicates what kind of message this is. The
value of "1" indicates that this is a Hello packet.
Packet Length - the total length of the packet.
Router ID - the ID of the router that sent this packet.
Area ID - the identification number of the area the message is for. We will
discuss using areas later.
FCS - the checksum on the packet, for detecting errors.
Authentication Type and the Authentication Fields - specify the method used
to authenticate that a participating router is indeed a legitimate router and not a
malicious user's router. The authentication is cryptographically, and is beyond
the scope of this text.
Network Mask - specifies the subnet mask of the network on which the packet
was sent.
Hello Interval - specifies how often Hello packets are sent through the
network, in seconds. On Ethernet, for example, the Hello Interval is usually set
to 10 seconds, which means each router must broadcast a Hello packet every
10 seconds.
Options - this field is a field of flags, specifying various operations of the
OSPF protocol that are supported by that router.
Priority - this field indicates to the router's neighbors his to treat this router
during the DR/BDR election process (which will be explained shortly).
Dead Interval - specifies how many seconds may elapse without hearing a
Hello packet from a certain neighbor router without declaring the router as
"dead". This is usually set to be four times the Hello interval.
Designated Router and Backup Designated Router - specify the router IDs of
the DR and BDR that were elected for that network.
Neighbor Router ID - this field is repeated for as many neighbors as the router
has, and each field specifies the router ID of one of the router's known
neighbors at the time of the sending of the packet.
Important Note: all the fields colored red are fields whose values must be set the same
for all the routers on the network.
Now that the structure of the Hello packet is known, we can begin to describe the
Hello protocol's operations. When a router first becomes active on a certain network,
it sends out a Hello packet to that network without any listed neighbors and with the
DR and BDR fields set to 0.0.0.0, also known as an empty Hello packet.
When another router on that network receives that Hello packet, it looks at its
neighbors table, sees that the specified Router ID in the Hello packet isn't on there,
and realizes that here is a new neighbors on that network. It therefore adds that router
ID to its list of neighbors on that network (i.e. on that interface).
The INIT state
Let's mark those routers, for our convenience, as router A and router B. So router A is
the new router sending out an empty Hello packet, and router B realizes router A is a
new neighbor, and lists it in its neighbors table. Router B has now entered what is
known as the INIT state, which means it has now learned of a new neighbor. The
same router can be in several different states in reference to different routers, and this
can be further complicated by the fact that routers can have interfaces on more than
one network, but this is still a rather simple concept.
After router B's Hello interval expires, it

sends out a new Hello packet on that
network, and now, router A will also be
listed on his neighbor router IDs list.
Here's an example of a network where
two routers just went online:
As router B's Hello packet reaches router

A, it realizes router B is his neighbor on
that network, and adds it to his neighbors table. Router A also notices that router B
has specified router A's ID in his neighbor router IDs list, and realizes that router B
has received its Hello packet. Router A now enters what is known as the 2WAY state,
which means, as far as router A is concerned, it has established a bi-directional
relationship with router B. On the next Hello packet that router A will send will also
be specified the router ID of router B, and thus router B will also enter the 2WAY
state with router A.
This process is repeated for every router on that network. Routers continue to send
new Hello packets every few seconds (as specified in the Hello Interval field), and
process each received Hello packet to see that routers hadn't disappeared (a router that
hasn't sent out a Hello packet for the length of time specified in the Dead Interval field
is considered dead on that network), and to discover new neighboring routers as they
become active. On a network, stability is reached when all the neighboring routers on
the network are in at least the 2WAY state with each other (there are other, "stronger"
states than 2WAY, which will be discussed later).
The designated router
The job of the designated router is to reduce protocol traffic by acting as the
distributor of topology information. In OSPF, changes in the networks topology are
flooded through the AS by routers in the form of special packets known as link-state
advertisements, or LSAs. These will be discussed a bit later. These packets are
somewhat lengthy, and the protocol states that these packets, in order that the OSPF
protocol could be run on various non-broadcast networks as well, are sent in unicast.
The problem with this is that when you have a certain network with more than two
routers, there's a lot of traffic generated by this, since all the routers that receive an
LSA will send it unicastly to all the other routers (except for the one they got it from),
even those who already got it.
OSPF's solution to this problem is to use a designated router (also known as DR) for
each network (on point-to-point connections there are only two routers so the solution
doesn't have a higher overhead than the simple transfer solution would take), which
will receive the LSAs from routers that have topology changes to report, and will
distribute them (by sending them unicastly) to all the other neighboring routers on that
network. This clearly removes all the redundant traffic within each network.
However, there is still the issue of electing and letting everyone know who the DR is.
In addition, since router problems aren't so common, it wouldn't be wise to let a single
router do all the work and thus become a single point of failure on that network, and
that is why there's a backup DR (referred to as BDR), which gets all the traffic sent to
the DR, and thus holds an exact copy of what the DR has. When the DR fails the
routers will detect it (via the Hello protocol all the routers will see that the DR is now
dead), and the BDR will simultaneously switched to be the DR, and there will be an
election for the new BDR among the active routers.
Before describing the election process, it's vital to understand how the use of both DR
and BDR is done. When two routers exchange topology change information, they
move to a new state, the FULL state, which is a higher state than 2WAY. However, as
already has been mentioned, we want to have as little protocol traffic as possible, and
using the DR as the distributor reduces the pairs of routers that are in the FULL state
to a minimum. When a router has a topology change to report, it will send it to both
DR and BDR (either by unicasting it to both - their router IDs are specified in all
Hello packets, or, if supported by the network, multicasting it to 224.0.0.6, which is
the multicast address for all OSPF designated routers on that network (which includes
the DR and BDR)). Then the DR will begin exchanging the topology information with
all the other routers, as will be described later.
The election of the DR and BDR proceeds as follows:
When a network first become

active, the first routers that become
active go through the stages of
discovering their neighbors. After they
all reach the state of 2WAY, they go
into a WAIT state and wait for an
interval of time similar to the interval
of time specified in the Dead Interval
fields. After that time period expires,
each router looks at its neighbors
table, and looks at all the routers
which specified, in their Hello packets,
a Priority value other than zero. It then
selects the two routers with the highest
priorities (if there is a tie, then the router with the higher router ID is chosen), making
the highest of the two the DR, and the second the BDR. Note that all active routers
will reach the same results. The next Hello packets from the routers will have the DR
and BDR's IDs specified in the DR and BDR fields of the Hello packet.
When a new router becomes active on a network that has already selected its DR and
BDR, it will first send an empty Hello packet (with DR and BDR fields set to 0.0.0.0),
and enter the WAIT state. However, since there are already routers on the network, it
will, before the time interval expires, already receive a Hello packet from another
router, and in it the DR and BDR fields will already contain a valid router ID. The
new router will now know the DR and BDR and no further processing is needed.
Once the DR and BDR are elected, and as long as they remain operational, OSPF
does not re-elect them, even if new routers with higher priorities or higher router IDs
become active on the network. What happens when the DR dies? The BDR will
notice it died, and, in its next Hello packet, state itself as the new DR and in the field
of the BDR it will choose, from its neighbors table, the next highest router (second
highest priority or router ID). If the BDR dies (and the DR doesn't), the DR will do
the same (elect a new BDR). If both dies, all the routers will notice and re-elect a DR
and BDR. The new DR and BDR will behave according to the specifications, and
their network interfaces will change status so they will be recognized as DR and BDR
(for example, for the multicast purpose).
Exchanging topology information between neighbors
In OSPF, each router maintains it's own topology database. This database needs to be
synchronized with the databases of all the other routers in the same area. In order to
synchronize the database with other databases, each router forms an adjacency with
the designated router and exchanges information with it. In addition, in case of a
change of network topology, once a router learns of the change, he notifies the
Designated Router, which, in turn, notifies all other routers.
Whenever a new router comes online, he uses the hello protocol to find his neighbors.
Once this router finds a neighbor, who is the Designated Router (or the Backup
Designated Router), an adjacency is formed between them in the following way:
The new router R1 sent a hello packet on all interfaces. Once some Designated Router
R2 received this packet, it adds the R1 to his list of neighbors. When R1 gets the
Hello packet from R2 with its Router ID in it, it sees that the Designated Router is R2.
R1 received a Hello packet from Designated Router R2 stating that R1 is a neighbor.
R1 enters the ExStart state, which means that he is about to exchange information
with R2.
When R1 is in the ExStart state, it sends R2 a packet, which is called "a Database
Description Packet", with some random sequence number. R2 upon receiving this
packet, also enters the ExStart state, and sends his own ExStart packet with his own
random sequence number. After this first exchange of Database Description packets,
both routers enter a new state - Exchange. The first 2 packets that were sent while R1
and R2 were in the ExStart state have only one purpose and that is to select a Master
and a Slave. Therefore, these first 2 packets do not contain any LSA headers. The
master is the router with the higher Router ID and the other router is the Slave. The
sequence number of the Master is denoted as SEQ.
Once both R1 and R2 are in the Exchange state, they exchange Database Description
packets, which summarizes the knowledge of each of them. The Database Description
packets contain a set of Link State Advertisement (LSA) headers. Link State
Advertisement describes the neighborhood of a specific router and an LSA header
uniquely identifies the LSA and its time of creation.
The Database Description packet exchange is done as follows:

The master sends his first Database Description packet (sometime, the database of the
router can take more than one Database Description packet), along with the sequence
number SEQ that he has chosen in the ExStart state. The Slave responds with a
Database Description packet of his own (which describe the Slave's database) and
with the same sequence number (SEQ). If needed, the Master then sends his next
Database Description packet, and attaches to it, the sequence number SEQ+1. The
Slave answers with his next Database Description packet and with SEQ+1. This
process goes on, and in each iteration, the Master sends his next Database Description
packet with the next sequence number (SEQ+n), and the Slave responds with his own
Database Description packet and with the same sequence number (SEQ+n).
When both sides have finished exchange Database Description packets, each side
knows which LSAs the other side has. The sides now enter the Loading state.
When both sides are in the Loading state, each side know what LSAs the other side
has, since this information is specified in the LSA headers, which are in the Database
Description packets. Each side goes over the list of LSA headers that it has received,
and marks the LSAs that it needs.
A router R1 needs an LSA that describes the Link State of some router R2 if one of
the following happens:
R1 has no prior LSAs of R2.
R1 has prior LSAs of R2 but the LSA header shows that the LSA that is
identified is a newer version. This means that one of the sides (the Master or
the Slave) has a newer description (LSA) of some router R2, and the other side
therefore needs this LSA.
After each side marks the LSAs it needs, each side sends to the other side a request
for the LSAs in a message which is called Link State Request (LSR). These packets
are responded to by special packets, which are called Link State Update (LSU), which
contain the requested LSAs.
The process of exchanging LSRs and LSUs is as follows:
If one of the sides needs some LSAs, it will put the list of LSA headers that it needs
into LSRs and will send the LSRs to the other side. The other side responds to each
LSR with an appropriate LSU. LSAs inside the LSU are acknowledged by a message,
which is called a Link State Acknowledgement. If one of the sides had sent an LSR
but didn't get an answer, it resends the LSR. When one side, finished receiving all the
LSAs that it had needed, it enters the FULL state, which means that it is in full
adjacency with the other side.
This process is continued until both sides are in the FULL state.
This process occurs when some router comes online and is forming full adjacency
with a Designated Router. However, the topology of the area can change and in that
case, OSPF needs to update the databases of each of the routers in the area. In
addition, when the Designated Router receives from one of its neighbors, some new
LSAs, it needs to inform the other routers of the new LSA.
Until now, we have seen that a router R1, which is not a designated router, forms
adjacencies with all the Designated Routers, which are connected to the same physical
networks as it is. However, R1 stays in 2WAY state with all the other routers (routers,
which are not Designated Routers).
Once some router learns of a new LSA, whether by being a Designated Router and
receiving a new LSA, or by discovering (using the Hello Protocol) a new neighbor, or
that a neighbor has gone down. The router, which has a new LSA, needs to flood it
throughout the network.
This process is done as follows:
Once a router R1 receives (or generates) a new LSA, it checks every interface. On
each interface, all the neighbors are checked (except for the neighbor, who has sent
R1, the new LSA). If a neighbor on a certain interface has started to form an
adjacency with R1 (or is already in full adjacency with R1), and R1 discovers that this
neighbor does not have this new LSA, then R1 does the following:
If R1 is the Designated Router or Backup Designated Router on that interface, it sends

the new LSA to all the routers on that interface. In networks, which support multicast,
the LSA is sent to the multicast address AllSPFRouters. Otherwise, unicast is used to
send the message to each router.
If R1 is not the Designated Router, nor the Backup Designated Router, it sends the
new LSA to the Designated Router and to the Backup Designated Router. On
networks which support multicast, the LSA is sent to the multicast address
AllDRouters. Otherwise, unicast is used.
The LSA is sent in an LSU (Link State Update) packet.
The routers, which have received the new LSA, will continue to send it on their
interfaces, and this causes the new LSA to be "Flooded" throughout the area.
The different packets
During the description of the information exchange in OSPF, some packet types were
mentioned. The following is a description of the packets format in OSPF.
Database Description Packets
The structure of these packets is the following:
This packet starts with the OSPF packet header (The first 24 bytes, that are in all
OSPF packets). The Type field in this header is set to 2.
After this come some other fields. The Meaning of the fields is:
Interface MTU - The MTU on the specified interface.
Options - This field is identical to the options field in the Hello Packet.
I bit (Init Bit) - This bit is set only in the first Database Description packet and its
purpose is to signal that this is the first packet.
M bit (More Bit) - This bit is set if this is not the last Database Description packet.
MS bit (Master/Slave Bit) - This bit is set in packets sent by the Master.
Database Description Sequence Number - This field saves the sequence number,
which is used in the Exchange state.
After these fields, there are a few LSA headers. Each LSA header has the same
format:
LSA header: (The LSA header is used to identify an LSA)
The fields in the LSA header are:
LS age - The age of the LSA (How much time ago, was it created.)
Options - This field is identical to the Options field of the Hello Packet and of the
Database Description Packet.
LS type - This field stores information of the type of the LSA. OSPF supports LSAs
of many types. LSAs which describe a regular router's state, a network's state, LSAs
which describe links of Autonomous Systems Border Routers, and LSAs, which
describe links that were discovered by some other form (not by OSPF).
Link State ID - This field uniquely defines what the LSA contains. LSAs specify the
current state of a device or a network. This field identifies that device or the network.
Advertising Router - The Router ID of the router, which published this LSA.
LS Sequence Number - the first LSA, which describes some device or network, has a
sequence number chosen. The next LSA, which describes the same device (or
network), will contain the next sequence number and so on.
LS checksum - A checksum of the LSA.
Length - The length of the LSA.
Link State Request
The packet starts with the regular OSPF header with the Type field containing 3. The
only fields in this packet (Besides the fields which are in all OSPF packets) are Link
State ID and Advertising Router, which were described before (During the description
of the LSA header). These fields uniquely identify the LSA that is needed.
Link State Update
This packet starts with the common OSPF header with the Type set to 4. After this,
comes a field that is called #LSAs and it contains the number of LSAs, which appear
in this packet. After this field, come all the LSAs.
There are several types of LSAs, which are supported by OSPF. These types include
LSAs, which describe the state of a specific router, LSAs that describe the state of a
network, and LSAs that contain information of Area Border Routers and LSAs that
contain information of AS Boundary Routers.
The main LSA type is the LSA, which describe a router state. The format of the
packet for such an LSA is the following:
The first 20 bytes are the LSA header that we have explained before. The LS type
field is set to 1 in this type of LSA packet.
The main fields are:
The E bit - This bit indicates whether this router is an AS boundary router.
The B bit - This bit indicates whether this router is an Area Border Router.
# links - The number of links, which will be described.
After this field, comes information for each of the described links:
Type - Describes the type of the link. There are 4 appropriate values, which are
described in the RFC.
Link ID - A unique identifier of the device that is on the other end of the link.
According to the Type field, this field is set. For example, if the Type field describes
that this is a Point-to-Point link to another router, then the Link ID is the other router's
Router ID.
Link Data - This field saves more information on the link, and it is again according to
the Type field. This field is very useful during the building of the Routing Table.
# TOS - Since OSPF supports TOS routing, each link can have a different cost for
each Type Of Service. Therefore, there can appear K different costs, each cost for a
different Type Of Service. The number K will be saved in this field.
Metric - The cost of this link without any relation to a specific Type Of Service.
After this field appears all the different Types Of Service, which are identified in the
TOS field by the appropriate IP Type Of Service number. For each such Type Of
Service, there appears the cost for this link in relation to the Type of Service, in the
TOS metric field.
Link State Acknowledgment
This packet is very simple. It consists of the OSPF packet header (The same header,
which is in all the OSPF packets) with the type set to 5.
After this, follows LSA headers of all the LSAs that the router wishes to
acknowledge.
The SPF problem
The OSPF protocol, as has been stated before, calculates the routing table for each
router by solving the SPF problem on the topology graph stored at that router. In the
literature, this problem is also referred to as the "Single-Source Shortest Paths"
problem. The definition of the SPF problem is this:
"Given a directed weighted graph and a vertex in it, find a sub-graph of the graph
which is a tree graph, on which the weight along the path from the specified vertex to
any other vertex is equal to the lowest weight path from the same source to the same
destination on the original graph".
For each router's topology graph a solution to the SPF problem will be calculated, and
from that tree the routing table will be constructed. Note that in our case, the weight
of the edge is the cost of the link.
Dijkstra's algorithm - a solution to SPF
One proven and well-known algorithm to solve the SPF problem for a given weighted
directed graph and a vertex in it is the Dijkstra algorithm. Dijkstra's algorithm
assumes all the weights on the graph are non-negative, but, since in OSPF there is no
reason to assign negative numbers, it can and in fact is used in the OSPF protocol.
To describe the algorithm, let's first explain the various symbols that will be used in
its description. The directed weighted graph will be denoted G, its group of vertices
will be denoted V, and its group of edges will be denoted E. An edge will be denoted
as a pair of vertices. For example, (v,u) will denote and edge starting from v and
ending in u. The weight associated with the edge (v,u) will be denoted w(v,u). The
algorithm works by maintaining a set S of vertices for whom we already figured out
the minimum cost of path from the given vertex. The denomination d[v] will state the
lowest cost of route from the given vertex to vertex v we found at a certain time. The
algorithm also keeps a priority queue Q of the vertices in G, in which the vertices are
ordered according to their d[v] values. In addition to all of those, for each vertex v the
algorithm also denoted by p[v] the predecessor of v. The p[v] value can be either
NULL or a vertex, and, when the algorithm is complete, for every vertex other than
the source vertex for which the algorithm is run will have a non-NULL predecessor,
and determining the lowest-cost path from v to the source vertex will be easily done
by running on the predecessor of v, and the predecessor of the predecessor of v, and
so on, until arriving at the source vertex.
So, given a weighted graph G and a source vertex s, the algorithm is the following:
For every vertex v in V such that v isn't s, set d[v]=infinity and p[v]=NULL.
Also set p[s]=NULL, and d[s]=0.
S is now an empty set.
Insert into the priority queue Q all the vertices in V.
While Q isn't empty, do:
Mark u as the minimum item in the priority queue Q.
Add u to S.
For every vertex v in the adjacency of u, if d[v] > d[u] + w(u,v), then do:
d[v]=d[u]+w(u,v)
p[v]=u
The algorithm's proof shows that the algorithm ends in a finite time, and in the end,
for a given vector v and the source vector s, the path of:
s->p[p[p[p[p...[p[p[p[v]]]...]]]]] -> ... -> p[p[v]] -> p[v] -> v
is a path that is in G, and it has a cost that is equal to the lowest cost of a path from s
to v in G.
Thus, Dijkstra's algorithm finds the shortest paths tree from the source vertex to every
other vertex in G. Here's an example of running the algorithm on a relatively
straightforward directed weighted graph:
Creating the routing table using the Dijkstra algorithm
We use Dijkstra's algorithm for creating the routing table for each OSPF router in the
following manner. First, we determine, for each network and link, what is its cost.
Then, for each router, we run Dijkstra's algorithm on the topography graph (stored in
its topography database), with itself as the source vertex.
Now, for every network in the AS, we will look at its vertex in the graph. We already
saw how to get the path to that vertex from the result of the algorithm, but in the
routing table we only need the next hop, so we take the first router that appears in path
which isn't the source router, and that, clearly, is the next hop router (since no two
networks are connected with an edge). If there is no such router, then the next hop
does not exist and the packet to be routed is locally generated and the router does not
forward it.
We're just about done. We've constructed the discovered neighbors, exchanged
topology information, and built the routing table. All that is left to discuss is how
weights are determined in the graph.
The weights on each link are of course determined by the network administrators,
which can have their own reasoning as to how to assign costs, but in most
circumstances, three elements should effect the decision of determining the cost Line
delay, Connection throughput and Network connectivity. Delay and throughput are
especially important when routing according to type of service (which will be
described later), and the connectivity of the network (how good is the connect, how
often does it break down) is naturally a topology factor as well. One OSPF standard
uses the bandwidth itself as the direct basis to computing the weights of links and
networks, by determining that the weight of a line is 10^8 divided by the bandwidth
of the line. Thus for example the cost of a 56Kbps link is 10^8 / 56000 = 1785, the
cost of a T1 link is 10^8 / 1544000 = 64, and the cost of a 100MB Ethernet is 10^ 8 /
(100 * 10^6) = 1.
OSPF Routing: IP routing
The OSPF protocol is used to build a routing table or a few routing tables (each
routing table for some Type Of Service). We already discussed how each router uses
the Hello Protocol and the Exchange Protocol to maintain the topology database, and
how each router use the Dijkstra algorithm to build a shortest path tree. From the
shortest path tree, the routers can derive the routing table, which contain for each IP
destination, the next hop.
OSPF supports different Types Of Service by building a routing table for each Type
Of Service. This was mentioned during the discussion on the Exchange Protocol,
when we showed that the LSA containss costs of a link for each Type Of Service.
This information is later used to build a shortest-path tree for each Type Of Service
(using the Dijkstra algorithm) and derive a Routing table for each Type Of Service.
In OSPF, the routing is based only on the destination IP address and the TOS field in
the IP datagram. The value in the TOS field in the IP datagram defines which routing
table will be used. Once we know which routing table to use, we look in the routing
table with the destination IP address, and we derive the next hop. This is how routing
is done, when using OSPF.
Areas in OSPF
Since Autonomous Systems tend to be quite large, if OSPF would be to run on an

entire Autonomous Systems, each router would have to receive a lot of LSAs (from
all other routers in the AS), which would mean that a lot of traffic taking place only to
transfer all the LSAs. In order to reduce the traffic, OSPF further divides ASs into
smaller sections, which are called Areas. All the OSPF operations, which was
describes before, are actually taking place inside an area. The routers in each area
only need to know how to route inside the area. This type of routing is called intra-
area. There are routers, however, which are in two or more areas, and are referred to
as Area Border Routers. These routers need to know how to route between areas. This
type of routing is called inter-area.
There is a special area, which is called a backbone area. This area is used to router IP
datagrams inside a whole Autonomous System. For this purpose, all the Area Border
Routers are contained within the backbone area.
Whenever there is an IP datagram to be routed, the following steps are taken:

If the destination is in the same area as the source then intra-area routing is
used - The datagram is routed inside the area.
If the destination is in a different area then the IP datagram will first be routed
to some Area Border Router. Since all Area Border Routers are in the
backbone area, the datagram is then routed within the backbone area (intra-
area) from the Area Border Router of the source area, to an Area Border
Router of the destination area. After this step, the datagram is in the
destination area, and it will be routed (using intra-area routing) to the
destination.
This is how routing is done using OSPF routing tables and according to the different
areas.
BORDER GATEWAY PROTOCOL (BGP 4 )
Border Gateway Protocol (BGP 4 )

INTRODUCTION
The Border Gateway Protocol (BGP), defined in RFC 1771, provides loop-free
Interdomain routing between autonomous systems. (An autonomous system [AS] is a
set of routers that operate under the same administration.) BGP is often run among the
networks of Internet service providers (ISPs). We will briefly study how BGP works
and how we can use it to participate in routing with other networks that run BGP.
Everyone responsible for Internet backbone wants to know about BGP. What is it?
How do you use it? What is it used for? Let us try to understand at least the basics of
BGP here.
The following points are covered:

BGP Fundamentals
BGP Decision Algorithm
Controlling the Flow of BGP Updates
BGP went through different phases and improvements from its earlier version, BGP1,
in 1989 to today‘s version , BGP4, deployment of which started in 1993. BGP4 is the
first version that handles aggregation (CIDR) and supernetting & allows the
announcement of "classless routes" - routes that aren't strictly on "Class A", "Class
B", or "Class C" boundaries - but instead can also be "subnets" or "supernets"..
BGP imposes no restrictions on the underlying Internet topology. It assumes that

routing within an autonomous system is not via an intra-autonomous system routing
protocol. BGP constructs a graph of autonomous systems based on the information
exchanged between BGP neighbors. This directed graph environment is sometimes
referred to as a tree. As far as BGP is concerned, the whole Internet is a graph of ASs,
with each AS identified by an AS number. Connections between two ASs together
from a path, and the collection of path information forms a route to reach a specific
destination. BGP ensures that loop-free interdomain routing is maintained.
Figure 1 illustrates this general path tree concept.

AS2
AS1
AS3
AS4 ASn-1
AS5 ASn
AS_Path Tree
-----------BGP
links
Figure 1 Example of AS_Path tree.
ROUTING: INTERNAL (INTERIOR) AND EXTERNAL

Internal routing is the art of getting each router in your network to know how to get to
every location (destination) in your network. You can do this simply, with static
routes, or in a more complicated but robust way, with active internal routing protocols
such as RIP, RIPv2, OSPF, and IS-IS.
It's obviously critical that any box inside your network know how to get (directly or
indirectly) to any other box inside your network. Before you invite people to send
data to your network, you've got to have a running and happy network to take the
data. If you default route into one or more providers, external routing isn't something
you have in your network. But if you do want to "peer" with someone - or to "multi-
home" to multiple providers and have a little bit more control over where your data
goes on the Internet, you will be taking at least some external routes into your
network and will do so with BGP.
WHY IS BGP INTERESTING?
Well, as mentioned above, it's nice to have routing data for parts of the Internet in
your routers. But it is much more useful to tell people outside your network (upstream
providers or "peers") about what routes (or portions of the IP address space) you
"know how to get to" inside your network. The primary purpose of BGP4 is to
advertise routes to other networks ("Autonomous Systems").
Autonomous Systems
An AS, or Autonomous System, is a way of referring to "someone's network". That

network could be yours; VSNL, MTNL, MCI's; Sprintlink's; or anyone's. Normally an
AS will have someone or ones responsible for it (a point of contact, typically called a
NOC, or Network Operations Center) and one or multiple "border routers" (where
routers in that AS peer and exchange routes with other ASs), as well as a simple or
complicated internal routing scheme so that every router in that AS knows how to get
to every other router and destination within that AS.
When you "advertise" routes to other entities (ASs), one way of thinking of those
route "advertisements" is as "promises" to carry data to the IP space represented in the
route being advertised. For example, if you advertise 192.204.4.0/24 (the "Class C"
starting at 192.204.4.0 and ending at 192.204.4.255), you promise that if someone
sends you data destined for any address in 192.204.4.0/24, you know how to carry
that data to its ultimate destination.
The cardinal sin of BGP routing is advertising routes that you don't know how to get
to. This is called "black-holing" someone - because if you advertise, or promise to
carry data to, some part of the IP space that is owned by someone else, and that
advertisement is more specific than the one made by the owner of that IP space, all of
the data on the Internet destined for the black-holed IP space will flow to your border
router. Needless to say, this makes that address space "disconnected from the 'net" for
the provider that owns the space, and makes many people unhappy. The second most
heinous sin of BGP routing is not having strict enough filters on the routes you
advertise.
Also, one terminology note: Classless routes are sometimes called "prefixes". When
someone talks about a prefix they're talking about a route with a particular starting
point and a particular specificity (length). So 207.8.96.0/24 and 207.8.96.0/20 are not
the same prefix (route).
Every IP address that you can get to on the Internet is reachable because someone,
some where, has advertised a route that covers it. The corollary to this is that if there
is not a generally-advertised route to cover an IP address, no one on the Internet will
be able to reach it.
HOW BGP WORKS?
BGP is a path vector protocol used to carry routing information between autonomous
systems. The term path vector comes from the fact that BGP routing information
carries a sequence of AS numbers, which indicates the path a route has traversed.
BGP uses TCP as its transport protocol (port 179). This ensures that all the transport
reliability such as retransmission is taken care of by TCP and does not need to be
implemented in BGP itself.
Two BGP routers form a transport protocol connection between each other. These
routers are called neighbors or peers. Figure 2 illustrates this relationship. Peer routers
exchange multiple messages to open and confirm the connection parameters, such as
the BGP version running between the two peers (for example, version3 for BGP 3 and
version 4 for BGP4). In case of any disagreement between the peers, notification
errors are sent, and the peer connection does not get established.
Initially all candidate BGP routes are exchanged, as illustrated in figure 3.

Incremental updates are sent as network information changes. The incremental update
approach has shown an enormous improvement as far as CPU overhead and
bandwidth allocation compared with complete periodic updates used by previous
protocols, such as EGP.
N1 N3
2.2.2.2 1.1.1.1
N2 N4
Establishing a neighboring Establishing a neighboring

Session with 1.1.1.1 Session with 2.2.2.2
Figure 2 . BGP routers become neighbors.
N1 N3
2.2.2.2 1.1.1.1
N2 N4
N3,N4
N1 N1,N2 N3
N2 N4
N3 N1
N4 N2
Figure 3 Exchanging all routing updates.
Routes are advertised between a pair of BGP routers in UPDATE messages. The
UPDATE message contains, among other things, a list of <length, prefix> tuples that
indicate the list of destinations reachable via each system. The UPDATE message
also contains the path attributes, which include such information as the degree of
preference for a particular route.
In case of information changes, such as route being unreachable or having a better

path, BGP informs its neighbors by withdrawing invalid routes and injecting new
routing information. As illustrated in figure 4, Withdrawn routes are part of the
UPDATE message. These are the routes not available for use. Figure 5 illustrates a
steady state situation: if no routing change occur, the routers exchange only
KEEPALIVE packets.
Withdraw N1
N1 N3
2.2.2.2 1.1.1.1
N2 N4
N1 N3
N2 N4
N3 N1
N4
N2
Figure 4 N1 goes down; partial update sent.
N3
2.2.2.2 1.1.1.1
N2 N4
N2 N3
N3 N4
N4 N2
Figure 5. Steady state; N1 is still down.
KEEPALIVE messages are sent periodically between BGP neighbors to ensure that
the connection is kept alive. KEEPALIVE packets (19 byte each) should not cause
any strain on the router CPU or link bandwidth as they consume a minimal bandwidth
(about 2.5 bits/sec for a periodic rate of 60 sec).
BGP keeps a table version number to keep track of the instance of the BGP routing
table. If the table changes, BGP will increment the table version. A table version that
is incrementing rapidly is usually an indication of instabilities in the network.
BGP FUNDAMENTALS :BGP MESSAGE HEADER FORMAT

The BGP message header format is a 16-byte marker field, followed by a 2-byte
length field and a 1-byte type field. Figure 6 illustrates the basic format of the BGP
message header.
0 7 15 23 31
Marker
Length Type
Figure 6. BGP message header format.
There may or may not be a data portion following the header, depending on the
message type. KEEPALIVE messages, for example, consist of the message header
only, with no following data.
The marker field is used to either authenticate incoming BGP messages or to detect
loss of synchronisation between two BGP peers. The marker field can have two
formats:
If the type of the message is OPEN or if the OPEN message has no
authentication information, the marker field must be all ones.
Otherwise, the marker field will be computed based on part of the
authentication mechanism used.
The length indicates the total BGP message length including the header. The smallest
BGP message is no less than 19 bytes (16+2+1) and no grater than 4,096.
The type indicates the message type, from the following possibilities:
OPEN
UPDATE
NOTIFICATION
KEEPALIVE
Now here we will examine the purpose and format of each of the four message types
in more detail.
BGP Neighbor Negotiation
One of the basic steps of the BGP protocol is establishing neighbors between BGP
peers. Without successful completion of this step, no exchange of updates will ever
take effect. Neighbor negotiation is based on the successful completion of a TCP
transport connection, the successful processing of the OPEN message, and periodic
detection of the KEEPALIVE messages.
OPEN Message Format

Figure 7 illustrates the format of the OPEN message.
0 7 15 23 31
Version
My Autonomous System
Hold Time
BGP Identifier
Opt parm Len
Optional Parameters
OPEN Message
Figure 7 OPEN Message format.

Version - A 1-byte field that indicate the version of BGP protocol such as
BGP3 or BGP4.
My autonomous system - A 2-byte field that indicates the AS number of the
BGP router.
Hold Time - The maximum time in seconds that may elapse between the
receipt of successive KEEPALIVE or update messages.
BGP indetifier - A 4-byte field that indicates the senders ID (Router ID)which
is calculated as the highest IP address on the router or the highest loop back
address at BGP session startup. (Loop back address is the representation of the
IP address of a virtual software interface that is considered to be up at all
times, irrespective of the state of any physical interface.)
Optional parameter - This field is represented by triplet <parameter type,
parameter length, parameter value>. Example - Authentication information
parameter
NOTIFICATION Message
A notification message is always sent whenever an error is detected, after

which the peer connection is closed. These are required to determine the specific
nature of errors that emerge in the routing protocol.
KEEPALIVE Message
KEEPALIVE messages are periodic messages exchanged between peers to determine

whether peers are reachable.
UPDATE Message and Routing Information
Central to the BGP protocol is the concept of routing updates. Routing updates
contain all the necessary information that BGP uses to construct a loop free picture of
the Internet. The following are basic blocks of an update message:
Network Layer Reachability Information (NLRI)
Path Attributes
Unreachable Routes
Figure 8 illustrates these components in the context of an update message format.

The NLRI is an indication, in the form of an IP prefix route, of the network being
advertised. The path attribute list provides BGP with the capabilities of detecting
routing loops and the flexibility to enforce local and global routing policies.
Unfeasible Routes Length (2 bytes) Unreachable

routes
Withdrawn Routes (variable) information
Total Path Attribute Length (2 bytes) Path

Attribute
information
Path Attribute (Variable)
Length (1byte) Prefix (variable)

NLRI
information
<length.prefix>
•
•
Figure 8 BGP Routing Update
EBGP vs. IBGP
EBGP and IBGP share the same low-level protocol for exchanging routes, and also
share some of the algorithms, but EBGP is used to exchange routes between different
Autonomous Systems, while IBGP is used to exchange routes between the same
Autonomous System. In fact, IBGP is one of the "interior routing protocols" that you
can use to do "active routing" inside your network.
The major difference between EBGP and IBGP is that EBGP tries like crazy to
advertise every BGP route it knows to everyone - you have to put "filters" in place to
stop it from doing so. IBGP is actually pretty difficult to get working because it tries
like crazy not to redistribute routes - in fact, all IBGP-speakers inside your network
have to peer with all other IBGP "speakers" in order to make it work. This is called a
"routing mesh" and, as you can imagine, is quite a mess. If you have 20 routers, each
router has to peer with every other router.
Also, IBGP has major drawbacks as an IGP. The main one is the necessity to "peer
up" every set of routers in the network (or in one POP if you're using confederations).
Protocols like OSPF and IS-IS just "find" each other over serial and Ethernet
interfaces (they're "broadcast" protocols). This can be a pain (you don't want to
accidentally merge your IGP with a customer's or peer's) but turning off broadcasting
on certain ports is easier than turning on peering sessions between a new router and
every other router on your network. Also, IBGP doesn't do as good a job at
"convergence" (closing the gap and re-routing around failed network segments) as
OSPF and IS-IS.
Routers that belong to the same AS and exchange BGP updates are said to be running
internal BGP (IBGP), and routers that belong to different ASs and exchange BGP
updates are said to be running external BGP (EBGP).
Figure 9 shows a network that demonstrates the difference between EBGP and IBGP.
Before it exchanges information with an external AS, BGP ensures that networks
within the AS are reachable. This is done by a combination of internal BGP peering
among routers within the AS and by redistributing BGP routing information to
Interior Gateway Protocols (IGPs) that run within the AS, such as Interior Gateway
Routing Protocol (IGRP), Intermediate System-to-Intermediate System (IS-IS),
Routing Information Protocol (RIP), and Open Shortest Path First (OSPF).
AS 100 100
AS 300
RA RD
A
129.213.1.2 D 192.208.10.1
EBGP
EBGP
129.213.1.1 192.208.10.2
IBGP
RB RC
B
175.220.212.1 C 175.220.1.2
AS 200
Fig 9 EBGP, IBGP and Multiple ASs
BGP uses the Transmission Control Protocol (TCP) as its transport protocol
(specifically port 179). Any two routers that have opened a TCP connection to each
other for the purpose of exchanging routing information are known as peers or
neighbors. In Figure 9, Routers A and B are BGP peers, as are Routers B and C, and
Routers C and D. The routing information consists of a series of AS numbers that
describe the full path to the destination network. BGP uses this information to
construct a loop-free map of ASs. Note that within an AS, BGP peers do not have to
be directly connected. BGP peers initially exchange their full BGP routing tables.
Thereafter, BGP peers send incremental updates only. BGP peers also exchange
keepalive messages (to ensure that the connection is up) and notification messages (in
response to errors or special conditions).
For routers that run EBGP, neighbors are usually directly connected, and the IP
address is usually the IP address of the interface at the other end of the connection.
For routers that run IBGP, the IP address can be the IP address of any of the router‘s
interfaces.
Refer the following about the ASs shown in Figure 9

Routers A and B are running EBGP, and Routers B and C are running IBGP.
Note that the EBGP peers are directly connected and that the IBGP peers are
not. As long as there is an IGP running that allows the two neighbors to reach
one another, IBGP peers do not have to be directly connected.
All BGP speakers within an AS must establish a peer relationship with each
other. That is, the BGP speakers within an AS must be fully meshed logically.
BGP4 provides two techniques that alleviate the requirement for a logical full
mesh: confederations and route reflectors.
AS 200 is a transit AS for AS 100 and AS 300—that is, AS 200 is used to
transfer packets between AS 100 and AS 300.
Internal BGP
Internal BGP (IBGP) is the form of BGP that exchanges BGP updates within an AS.
Instead of IBGP, the routes learned via EBGP could be redistributed into IGP within
the AS and then redistributed again into another AS. However, IBGP is more flexible,
provides more efficient ways of controlling the exchange of information within the
AS, and presents a consistent view of the AS to external neighbors. For example,
IBGP provides ways to control the exit point from an AS. Figure 10 shows a topology
that demonstrates IBGP.
Fig 10 Internal BGP Example
180.10.30.1 AS 100
RD
IBGP
D
190.10.50.1
150.10.30.1
RA IBGP RB
A B
170.10.20.1 175.10.40.2
170.10.20.2 175.10.40.1
RE RC
AS 300 AS 400
AS 500 170.10.0.0 175.10.0.0
When a BGP speaker receives an update from other BGP speakers in its own AS (that
is, via IBGP),the receiving BGP speaker uses EBGP to forward the update to external
BGP speakers only. This behavior of IBGP is why it is necessary for BGP speakers
within an AS to be fully meshed. For example, in Figure 10 if there were no IBGP
session between Routers B and D, Router A would send updates from Router B to
Router E but not to Router D. If you want Router D to receive updates from Router B,
Router B must be configured so that Router D is a BGP peer.
Loop back Interfaces
Loop back interfaces are often used by IBGP peers. The advantage of using loopback
interfaces is that they eliminate a dependency that would otherwise occur when you
use the IP address of a physical interface to configure BGP.
EBGP Multihop
Usually, the two EBGP speakers are directly connected (for example, over a wide-
area network [WAN] connection). Sometimes, however, they cannot be directly
connected. In this special case,the neighbor EBGP-multihop router configuration
command is used. Multihop is used only for EBGP, but not for IBGP.
Synchronization
When an AS provides transit service to other ASs and if there are non-BGP routers in
the AS, transit traffic might be dropped if the intermediate non-BGP routers have not
learned routes for that traffic via an IGP. The BGP synchronization rule states that if
an AS provides transit service to another AS, BGP should not advertise a route until
all of the routers within the AS have learned about the route via an IGP. The topology
shown in Figure 11 demonstrates the synchronization rule.
Fig 11 Synchronization
As 100
E
150.10.0.0
IGP IGP
RE
RA IBGP RB
2.2.2.2 A B
2.2.2.1
D
RC C RD
As 300 As 400
170.10.0.0 175.10.0.0
In Figure 11, Router C sends updates about network 170.10.0.0 to Router A. Routers
A and B are running IBGP, so Router B receives updates about network 170.10.0.0
via IBGP. If Router B wants to reach network 170.10.0.0, it sends traffic to Router E.
If Router A does not redistribute network 170.10.0.0 into an IGP, Router E has no
way of knowing that network 170.10.0.0 exists and will drop the packets.
If Router B advertises to AS 400 that it can reach 170.10.0.0 before Router E learns
about the network via IGP, traffic coming from Router D to Router B with a
destination of 170.10.0.0 will flow to Router E and be dropped.
This situation is handled by the synchronization rule of BGP, which states that if an
AS (such as AS 100 in Figure 11) passes traffic from one AS to another AS, BGP
does not advertise a route before all routers within the AS (in this case, AS 100) have
learned about the route via an IGP. In this case, Router B waits to hear about network
170.10.0.0 via an IGP before it sends an update to Router D. In some cases, you might
want to disable synchronization. Disabling synchronization allows BGP to converge
more quickly, but it might result in dropped transit packets.
You can disable synchronization if one of the following conditions is true:
Your AS does not pass traffic from one AS to another AS.

All the transit routers in your AS run BGP.
BGP and Route Maps
Route maps are used with BGP to control and modify routing information and to
define the conditions by which routes are redistributed between routing domains. The
format of a route map is as follows:
route-map map-tag [[permit | deny] | [ sequence-number]]
The map tag is a name that identifies the route map, and the sequence number
indicates the position that an instance of the route map is to have in relation to other
instances of the same route map.
Advertising Networks
A network that resides within an AS is said to originate from that network. To inform
other Ass about its networks, the AS advertises them. BGP provides three ways for an
AS to advertise the networks that it originates:
Redistributing Static Routes
Redistributing Dynamic Routes
Using the network Command
BGP Decision Algorithm
When a BGP speaker receives updates from multiple ASs that describe different paths
to the same destination, it must choose the single best path for reaching that
destination. Once chosen, BGP propagates the best path to its neighbors. The decision
making process is based on the value of following attributes:
AS path Attribute
Origin Attribute
Next Hop Attribute
Weight Attribute
Local Preference Attribute
Multi-Exit Discriminator Attribute
Community Attribute
BGP ATTRIBUTE Details
Value Code Possible Values

---- ----------------------------------------------------- ---------------------------------------------
1 ORIGIN 0 (IGP); 1 (EGP); 2 (Incomplete)
This attribute specifies the origin of a route.
Straightforward except that "Incomplete" means
that the route got into BGP by redistribution from
an IGP.
2 AS_PATH 0 - N, 2-byte values
A list of the ASNs of all ASs the route has traversed.
3 NEXT_HOP IP Address
The most critical attribute; where to send data destined
for this route.
4 MULTI_EXIT_DISC 0-2^32
A weight; designed to go outside and inside of an ASN.
5 LOCAL_PREF 0-2^32
A weight; not designed to go outside of an ASN.
6 ATOMIC_AGGREGATE TRUE/FALSE: If present, true; otherwise, false.
Present if this route was not the most specific one
known by the advertiser.
7 AGGREGATOR {ASN,Ip address} pair.
Data to indicate who formed the route if the route
is an aggregate of smaller routes.
8 COMMUNITY 0 - N, 4-byte values ("communities")
9 ORIGINATOR_ID Used for BGP Route Reflection
10 CLUSTER_LIST Used for BGP Route Reflection
AS-PATHS
Every time a route is advertised via BGP, it is "stamped" with the ASN of the router
doing the advertising. As a route moves from Autonomous System to Autonomous
System (network to network), it builds up an "AS-PATH". Each route starts out with a
"null AS-PATH", represented by the regular expression "^$". The AS-PATH is
useful for a number of reasons:
It provides a "diagnostic trace" of routing on the Internet. If you have "full
routes" in one of your routers, or have "query access" to a router that does
(such as telnet://route-server.cerf.net), you can find the route that encompasses
a particular IP address and see which ASNs have advertised it. If you do some
poking around, you can even see how a provider is actually connected.
It is one of a number of metrics that determines how routes "heard" via BGP
are inserted into the actual IP routing table.
It is something that allows you to do "policy routing" of sorts - basically, you
use the AS-PATH to filter routes. Why would you want to do this?
BGP PATH SELECTION PROCESS
BGP selects only one path as the best path. When the path is selected, BGP puts the
selected path in its routing table and propagates the path to its neighbors. BGP uses
the following criteria, in the order presented, to select a path for a destination:
1. If the path specifies a next hop that is inaccessible, drop the update.
2. Prefer the path with the largest weight.
3. If the weights are the same, prefer the path with the largest local preference.
4. If the local preferences are the same, prefer the path that was locally originated
(by BGP running on this router).
5. If no route was originated, prefer the route that has the shortest AS_path.
6. If all paths have the same AS_path length, prefer the path with the lowest origin
type (where IGP is lower than EGP, and EGP is lower than Incomplete).
7. If the origin codes are the same, prefer the path with the lowest MED attribute.
8. If the paths have the same MED, prefer the external path over the internal path.
9. If the paths are still the same, prefer the path through the closest IGP neighbor.
10. Prefer the path with the lowest IP address, as specified by the BGP router ID."
Controlling the Flow of BGP Updates
For controlling the flow of BGP updates, the techniques include the following:
Administrative Distance
BGP Filtering
BGP Peer Groups
CIDR and Aggregate Addresses
Confederations
Route Reflectors
Route Flap Dampening
Administrative Distance
Administrative distance is used to discriminate between routes learned from more

than one protocol The route with the lowest administrative distance is installed in the
IP routing table
BGP default distances
Distance Default value Function
External 20 Applied to routes learned from EBGP
Internal 200 Applied to routes learned from IBGP
Local 200 Applied to routes originated by the router
Distance does not influence the BGP path selection algorithm, but it does influence
whether BGP learned routes are installed in the IP routing table.
BGP Filtering
We can control the sending and receiving of updates by using the following filtering
methods:
Prefix Filtering
AS_path Filtering
Route Map Filtering
Community Filtering
BGP Peer Groups
A BGP peer group is a group of BGP neighbors that share the same update policies.
Update policies are usually set by route maps, distribution lists, and filter lists. Instead
of defining the same policies for each individual neighbor, you define a peer group
name and assign policies to the peer group. Members of a peer group inherit all of the
configuration options of the peer group. Peer group members can also be configured
to override configuration options if the options do not affect outgoing updates. That
is, you can only override options that are set for incoming updates.
CIDR and Aggregate Addresses
BGP4 supports classless interdomain routing (CIDR), which is a major improvement

over BGP3. (CIDR is also known as supernetting.) CIDR is a new way of looking at
IP addresses that eliminates the concept of classes (Class A, Class B, and so on). For
example, network 192.213.0.0, which is an illegal Class C network number, is a legal
supernet when it is represented in CIDR notation as 192.213.0.0/16. The /16 indicates
that the subnet mask consists of 16 bits (counting from the left).Therefore,
192.213.0.0/16 is similar to 192.213.0.0 255.255.0.0.CIDR makes it easy to aggregate
routes. Aggregation is the process of combining several different routes in such a way
that a single route can be advertised, which minimizes the size of routing tables.
A router cannot aggregate an address if it does not have a more specific route
of that address in the BGP routing table. The more specific route can be
injected in the BGP routing table by incoming updates from other ASs, can be
redistributed from an IGP, or can be established by the network router
configuration command.
Confederations
A confederation is a technique for reducing the IBGP mesh inside the AS. WE use
Confederations reduce the number of peers within the AS. confederations to divide
the AS into multiple mini-ASs and assign the mini-ASs to a confederation. Each mini-
AS is fully meshed, and IBGP is run among its members. Each mini-AS has a
connection to the other mini-ASs within the confederation. Even though the mini-ASs
have EBGP peers to ASs within the confederation, they exchange routing updates as
if they were using IBGP—that is, the next hop, MED, and local preference
information is preserved. To the outside world, the confederation looks like a single
AS.
Route Reflectors
Route reflectors are another solution for the explosion of IBGP peering within an AS.
As described earlier in the section ―Synchronization,‖ a BGP speaker does not
advertise a route learned from another IBGP speaker to a third IBGP speaker. Route
reflectors ease this limitation and allow a router to advertise (reflect) IBGP-learned
routes to other IBGP speakers, thereby reducing the number of IBGP peers within an
AS.
Route Flap Dampening
Route flap dampening is a mechanism for minimizing the instability caused by route
flapping. The following terms are used to describe route flap dampening:
Penalty—A numeric value that is assigned to a route when it flaps.
Half-life time—A configurable numeric value that describes the time required
to reduce the penalty by one half.
Suppress limit—A numeric value that is compared with the penalty. If the
penalty is greater than the suppress limit, the route is suppressed.
Suppressed—A route that is not advertised even though it is up. A route is
suppressed if the penalty is more than the suppressed limit.
Reuse limit—A configurable numeric value that is compared with the penalty.
If the penalty is less than the reuse limit, a suppressed route that is up will no
longer be suppressed.
History entry—An entry that is used to store flap information about a route
that is down.
A route that is flapping receives a penalty of 1000 for each flap. When the
accumulated penalty reaches a configurable limit, BGP suppresses advertisement of
the route even if the route is up. The accumulated penalty is decremented by the half-
life time. When the accumulated penalty is less than the reuse limit, the route is
advertised again (if it is still up).
Dampening is not applied to routes that are learned via IBGP. This restriction avoids
forwarding loops and prevents IBGP peers from having a higher penalty for routes
that are external to the AS.
WHAT IS ROUTE FLAP AND WHY IS IT BAD?

When you "assert" a route - saying "I know how to get to 192.204.4.0/24" based on
some internal knowledge that you actually do know how to get to 192.204.4.0/0, the
natural (and previously-though-to-be-correct-thing-to-do) is to "withdraw" that
assertion if you in fact no longer know how to get to 192.204.4.0.
But look at what happens when you withdraw that assertion. Your provider(s) must
then also withdraw that assertion. And then their provider(s) and peer(s) must do the
same. All in all, thousands of routers around the world now have to look at that route
and decide if they have a next-best path in their BGP (or other routing) table, and
insert it as the current best path in their IP routing table. This consumes many CPU-
seconds on routers that are sometimes very busy.
In fact, it was consuming so much CPU time a few years ago that Sean Doran of
Sprintlink said "this must stop" and a few people came up with an idea (which Cisco
implemented in record time) to "damp"(en) the "route flap"s.
What this means in practice today is that if your routes flap more than one or two
complete up-down-up cycles, you will be dampened by many providers for at least an
hour or so. So even if you're only "single-homed", you will be dampened if your
provider withdraws your routes every time your link flips up and down a few times.
INTERNET CONNECTIVITY WITHOUT BGP!
Let's review what happens when we are connected to the Internet without speaking
BGP to upstream provider. We can create a default route towards upstream provider,
and all non- local packets go out the interface specified by the route; and upstream
provider probably put static routes towards us on their side, and redistributes those
static routes into their IGP, and then probably redistributes their IGP into BGP -
unless all of their BGP is done statically .
Basically, if we have any address space "inside" of upstream provider's larger

"netblock" or "aggregate", we won't be advertised to the outside world specifically -
upstream provider will just advertise their larger block. If we have any other networks
(an old Class C; customers with address space; etc...) upstream provider will just
statically announce those routes to the world and statically route them inside their
network to our leased-line/ router interface(s).
With BGP, upstream provider gives us all of the routes they have (the easy part), and
listens to our route announcements and then redistributes some or all of those to their
peers and customers. The net difference is "just" that they may start advertising a
more specific route (no mean task in a complicated network designed, as most
networks are, to prevent the accidental "leaking" of more specific routes) or that the
routes that they normally advertise for us under just their ASN will now have our
ASN attached as well.
BGP AND THE SINGLE-HOMED
If you've only got one upstream provider, why speak BGP to them? Well, you could
say "practice", but in general, no upstream provider's going to waste their time
configuring BGP with you (since it generally involves a fair amount of behind-the-
scenes work on their part) unless you have a good reason. And you don't really need
"full routes" if you're single-homed. Since every packet destined for the Internet (as
opposed to your internal network ) is going to go out the same router interface, it
doesn't matter whether it's via one default route or via searching a list of 45,000 or
more routes heard via BGP.
The only really valid reason is that you want to be able to have more control in
advertising your routes. Of course, you'll have to argue around the flap argument
even if you have your own provider-independent address space (if you're singly-
connected to the 'net, why bother all of the routers in the world by telling them
whether you're reachable or not currently) and the routing-table space argument (if
you're in your provider's IP space or "aggregate announcement"), why pollute the
routing tables with an extra few routes by announcing your routes more specifically?
The ISPs have to answers to these questions and decide routing policies accordingly.
If you do want to configure BGP and are single-homed, follow the instructions on
how to announce your networks (routes), and either filter all incoming routes - or
accept them if you feel you really want to.
MULTI-HOMING AND LOAD-BALANCING
Generally, the goal of multi-homing is to use both connections in a same manner and
"load-balance" them somehow. Ideally, you'd like roughly half the traffic to go in and
out of each connection. You'd also like "fail-over" routing, where if one connection
goes down the other one keeps you connected to the Internet. In an ideal network,
you'd be able to have any one of your connections to the 'net go down and still
maintain connectivity and speed.
We'll talk a bit about how you load-balance incoming and outgoing traffic to and from
your network. Incoming traffic is controlled by how you announce your routes to the
world (packets will flow into your network because someone out there heard and is
using a route announcement). Outgoing traffic is controlled by the routes that you
allow to flow into your border router(s) - and is thus much easier to control and tune.
NIB-I Network
Cisco 7500 Series Product Overview

The Cisco 7500 series includes the following routers: Cisco 7505, Cisco 7507, Cisco
7513, and Cisco 7576. The Cisco 7500 series routers support multiprotocol,
multimedia routing and bridging with a wide variety of protocols and any
combination of Asynchronous Transfer Mode (ATM), Basic Rate Interface (BRI),
channel attachment, channelized E1, T1, and T3, Ethernet, Fast Ethernet, Fiber
Distributed Data Interface (FDDI), High-Speed Serial Interface (HSSI), multichannel,
Primary Rate Interface (PRI), Packet over OC-3, synchronous serial, and Token Ring
media.
The first four sections of this chapter describe the Cisco 7500 series routers, and
include the following:
Cisco 7507 Overview
Cisco 7513 Overview
The remaining sections of this chapter describe components in the Cisco 7500 series
routers, which are considered to be standard equipment and ship with each router:
Route Switch Processor (RSP) Overview
AC-Input and DC-Input Power Supply Overview
Arbiter Overview
Chassis Interface Overview
Fan Tray and Blower Assembly Overview
Interface Processor Overview
This section provides a general overview of interface processors; for a complete
discussion and description of all interface processors available for the Cisco 7500
series routers, refer to the companion publication Interface Processor Installation and
Configuration Guide.
System Software Overview
Terms and Acronyms
Following is a list of acronyms, initializations, and terms that identify the Cisco 7500
series system components and features:
AIP---Asynchronous Transfer Mode (ATM) Interface Processor.
Backplane---the single or dual system bus to which Cisco interface processors
and system processors attach within a Cisco 7500 series router.
Card cage---the assembly in which the backplane is mounted.
CIP2---Channel Interface Processor.
CT3IP---Channelized T3 Interface Processor.
CxBus---Cisco Extended Bus, the 533-megabit-per-second (Mbps) data bus in
the Cisco 7000 series routers.
CyBus---Cisco Extended Bus, the 1.067-gigabit-per-second (Gbps) data bus in
the Cisco 7500 series routers; the Cisco 7505 has one CyBus; the Cisco 7507
and the Cisco 7513 have two CyBuses (called the dual CyBus) for an
aggregate bandwidth of 2.134 Gbps. The Cisco 7576 has two dual CyBuses
on a single split backplane creating two independent routers. Each Cisco 7576
independent router has an aggregate bandwidth of 2.134 Gbps. (Interface
processors designed for the CxBus work with the CyBus.)
dBus---Diagnostic bus for Route Switch Processor diagnostic and control
access, system discovery and control, microcode download, and fault
diagnosis for all processors connected to the CyBus.
DIMM---dual in-line memory module.
DRAM---dynamic random-access memory.
EIP---Ethernet Interface Processor.
FEIP---Fast Ethernet Interface Processor.
FIP---FDDI Interface Processor.
FSIP---Fast Serial Interface Processor.
FRU---Field-replaceable unit, defined as any spare part that requires
replacement by a Cisco-certified service provider.
Gbps---gigabits per second.
HSA---High System Availability.
HIP--- HSSI Interface Processor.
Interface processor---printed circuit card attached to a metal carrier that
provides the electrical interfaces used by the Cisco 7500 series routers.
Mbps---megabits per second.
MIP---MultiChannel Interface Processor.
NVRAM---nonvolatile random-access memory.
PCMCIA---Personal Computer Memory Card International Association.
POSIP---Packet over OC-3 Interface Processor.
Processor modules---describes all interface processors and main system
processors used in the Cisco 7500 series routers.
RSP---Route Switch Processor; the main system processor. In this publication,
the term RSP includes all RSP models (differences between RSP models are
clearly noted)
RSP1---specific main system RSP for the Cisco 7505.
RSP2---specific main system RSP for the Cisco 7507 and Cisco 7513.
RSP4---optional main system RSP for the Cisco 7507 and Cisco 7513, and
the specific main system RSP for the Cisco 7576.
SIMM---single in-line memory module.
Spares---spare parts that do not require replacement by a Cisco-certified
service provider.
SRAM---static random-access memory.
TDM bus---Connectors on the backplane of the Cisco 7576 that are designed
for future Time Division Multiplexing hardware as it becomes available.
TRIP---Token Ring Interface Processor.
VIP2---Second-Generation Versatile Interface Processor: incorporates
interchangeable port and service adapters for flexible interface functionalities.
Cisco 7507 Overview
The Cisco 7507 supports multiprotocol, multimedia routing and bridging with a wide
variety of protocols and any combination of available electrical interfaces and media.
Network interfaces reside on interface processors that provide a direct connection

between the two CyBuses in the Cisco 7507 and your external networks. The Cisco
7507 has seven slots: interface processor slots 0 and 1, Route Switch Processor
(RSP2 or RSP4) slots 2 and 3, and interface processor slots 4 through 6.
There are bays for up to two AC-input or DC-input power supplies. The chassis will
operate with one power supply. While a second power supply is not required, it allows
load sharing and increased system availability.
Caution Due to agency compliance and safety issues, mixing AC-input and
DC-input power supplies in the same Cisco 7507 is not a supported
configuration and should not be attempted. Doing so might cause damage.
The Cisco 7507 front panel, shown in Figure 1-4, contains three status indicators and
two removable panels for access to the internal components. The three light emitting
diodes (LEDs) on the front panel indicate normal system operation and the currently
active power supplies. On the back of the router, a normal LED on the RSP2 (or
RSP4) and LEDs on the power supplies indicate the same status.
Figure 1-4: Cisco 7507 (Front View)
Figure 1-5 shows details on the rear, interface-processor end of the Cisco 7507.
Figure 1-5: Cisco 7507 (Rear View)
Cisco 7507 Dual CyBus Backplane
The dual CyBus backplane provides the physical connections for the RSPs and
interface processors, and transfers information at up to 2.134 Gbps (1.067 Gbps per
CyBus). The dual CyBus has seven slots: interface processor slots 0 and 1 (Cybus 0),
RSP slots 2 and 3, and interface processor slots 4 through 6 (CyBus 1), as shown in
Figure 1-6.
Figure 1-6: Dual CyBus Backplane in the Cisco 7507
An RSP2 or RSP4 in either slot 2 or slot 3 controls both CyBus 0 and CyBus 1. The
dual CyBus backplane in the Cisco 7507 has an aggregate bandwidth of 2.134 Gbps.
The two CyBuses are independent of one another. Interface processors connected to
one CyBus are unaffected by the traffic generated by the interface processors
connected to the other.
The backplane slots are keyed so that the processor modules can be installed only in
the slots designated for them. Keys on the backplane fit into two key guides on each
module. Although the RSP uses unique keys, all five interface processor slots use the
same key, so you can install an interface processor in any interface processor slot, but
not in the RSP slot.
Cisco 7513 Overview
The Cisco 7513 router supports multiprotocol, multimedia routing and bridging with a
wide variety of protocols and any combination of available electrical interfaces and
media. Network interfaces reside on interface processors that provide a direct
connection between the two CyBuses in the Cisco 7513 and your external networks.
The Cisco 7513 has thirteen slots: interface processor slots 0 through 5, Route Switch
Processor (RSP2 or RSP4) slots 6 and 7, and interface processor slots 8 through 12.
There are bays for up to two AC-input or DC-input power supplies. The chassis will
operate with one power supply. While a second power supply is not required, it allows
load sharing and increased system availability. The Cisco 7513 is shown in Figure 1-
7. The three front-panel LEDs indicate system and power supply status, and LEDs on
the RSP, interface processors, and power supplies indicate status.
Caution Due to agency compliance and safety issues, mixing AC-input and
DC-input power supplies in the same Cisco 7513 is not a supported
configuration and should not be attempted. Doing so might cause damage.
Figure 1-7: Cisco 7513 (Front View)
Figure 1-8 shows details on the rear, interface-processor end of the Cisco 7513.
Figure 1-8: Cisco 7513 (Rear View)
Cisco 7513 Dual CyBus Backplane
The dual CyBus backplane, located at the rear of the Cisco 7513's removable card
cage, provides the physical connections for the RSPs and interface processors, and
transfers information at up to 2.134 Gbps (1.067 Gbps per CyBus).
The dual CyBus has 13 slots: interface processor slots 0 through 5 (CyBus 0); two
RSP slots (slots 6 and 7); interface processor slots 8 through 12 (CyBus 1), as
shown in Figure 1-9.
Figure 1-9: Dual CyBus Backplane in the Cisco 7513
An RSP2 or RSP4 in either slot 6 or slot 7 controls both CyBus 0 and CyBus 1. The
dual CyBus backplane in the Cisco 7513 has an aggregate bandwidth of 2.134 Gbps.
Interface processors connected to one CyBus are unaffected by the traffic generated
by the interface processors connected to the other CyBus. The two CyBuses are
independent of one another.
The backplane slots are keyed so that the processor modules can be installed only in
the slots designated for them. Keys on the backplane fit into two key guides on each
module. Although the RSP uses unique keys, all eleven interface processor slots use
the same key, so you can install an interface processor in any interface processor slot,
but not in the RSP slot.
Note A spare card cage assembly ships as Product Number MAS-7513CDCAGE=.

For maintenance information about the card cage assembly, refer to the section
"Removing and Replacing the Cisco 7513 and Cisco 7576 Card Cage Assembly" in
the chapter "Maintaining the Cisco 7513 and Cisco 7576."
Cisco 7513 System Specifications
Table 1-3 lists the specifications for the Cisco 7513 system.
Table 1-3: Cisco 7513 Specifications

Description Specification
Backplane Two 1.0677-Gbps CyBuses: 11 interface processor slots, two

RSP slots
Dimensions 33.75 x 17.5 x 22 in. (85.73 x 44.45 x 55.88 cm)

(H x W x D) Chassis width including rack-mount flanges is 18.93 in. (48.1
cm)
Chassis depth including power cables and cable-management
bracket is 24 in. (60.96 cm)
Weight Chassis with blower module: 75 lb (34.02 kg)

Chassis with blower module and one power supply: 100 lb
(45.36 kg)
Chassis with blower module and two power supplies: 125 lb
(56.7 kg)
Chassis with blower module, two power supplies, and all slots
filled: ~160 lb (72.58 kg), each processor module weighs ~2.5
lb (1.13 kg)
Power dissipation 1600W with a maximum configuration and one AC-input power
supply
1600W with a maximum configuration and one DC-input power
supply
1700W nominal with a maximum configuration and either two
AC-input or two DC-input power supplies
Heat dissipation 1600W (5461 Btu/hr)
AC-input voltage 100 to 240 VAC
Frequency 50/60 Hz
AC-input cable 12 AWG, with three leads, an IEC-320 plug on the router end,
and a country-dependent plug on the power source end
AC-input voltage 100 VAC at 16 amps (A) maximum, wide input with power
and current factor correction (PFC)
240 VAC at 7A maximum
DC-input voltage -48 VDC nominal, at 35A in North America

and current (-60 VDC at 35A in the European Community)
DC-input cable 8 AWG (recommended minimum), with three leads and rated for
at least 194° F (90° C) (you supply the cable)
Power distribution +5.2 VDC @ 75A, +12 VDC @ 15A, -12 VDC @ 3A, +24
VDC @ 5A
Airflow/noise level Bottom to top through chassis by variable-speed blower (62 to

70 dBA)
Temperature 32 to 104° F (0 to 40° C), operating; -4 to 149° F (-20 to 65° C),

nonoperating
Relative humidity 10 to 90%, noncondensing
Software Cisco IOS Release 10.3(571) or later for the RSP2 and Cisco
requirement 7513.
Cisco IOS Release 11.1(8)CA or later for the RSP4 in the Cisco
7513
Agency approvals Safety: UL 1950, CSA 22.2-950, EN60950, EN41003, TS001,

AS/NZS 3260
EMI: FCC Class A, EN60555-2, EN55022 Class B, VDE 0878
Part 3, 30 Class B
Immunity: EN55101/2 (ESD), EN55101/3 (RFI), EN55101/4
(Burst), EN55101/5 (Surge), EN55101/6 (Conducted), IEC77B
(AC Disturbance)
Catalyst 5500 Switch
The Catalyst 5500 switch chassis has 13 slots. Slot 1 is for the supervisor engine,
which provides switching, local and remote management, and multiple uplink
interfaces. Slot 2 can contain an additional redundant supervisor engine, which acts as
a backup in case the first module fails. A failure of the active supervisor engine is
detected by the standby module, which takes control of supervisor engine switching
functions. If a redundant supervisor engine is not required, slot 2 is available for any
switching module.
Slots 3 through 12 are available for any combination of switching modules.
Slot 13 is a dedicated slot, which accepts only the ATM switch processor (ASP)
module or the Catalyst 8510 Campus Switch Router (CSR) switch route processor
(SRP). When using the ASP in slot 13, the Catalyst 5500 switch accepts LightStream
1010 ATM port adapters in slots 9 through 12. When using the Catalyst 8510 CSR
SRP in slot 13, the Catalyst 5500 switch accepts Catalyst 8510 CSR modules in slots
9 through 12.
The Catalyst 5500 switch has a 3.6-Gbps media-independent switch fabric and a 5-
Gbps cell-switch fabric. The backplane provides the connection between power
supplies, supervisor engine, switching modules, and backbone module. The 3.6-Gbps
media-independent fabric supports Ethernet, Fast Ethernet, Gigabit Ethernet,
FDDI/CDDI, ATM LANE, ATM dual PHY DS3, RSM, and RSM/VIP2 modules.
The 5-Gbps cell-based fabric supports an ASP module and ATM port adapters. See
Table 1-1 for additional information.

Figure 1-6: Catalyst 5500 Switch
Cisco AS5800 Product Overview
The Cisco AS5800 is a high-density, ISDN and modem WAN aggregation system
that provides both digital and analog call termination. It is intended to be used in
service provider dial point-of-presence (POP) or centralized enterprise dial
environments.
The access server components include a Cisco 5814 dial shelf and a Cisco 7206 router
shelf. Two versions of an optional AC power shelf is also available, either standard or
enhanced. Dial shelf cards communicate with the host router shelf over a dial shelf
interconnect cable. This nonblocking interconnect cable supports 100-Mbps, full-
duplex data transfer.
The access server is designed with environmental monitoring and reporting functions
to help maintain normal system operation and resolve adverse environmental
conditions prior to loss of operation. If conditions reach critical thresholds, the system
shuts down to avoid equipment damage from excessive heat or electrical current.
Downloadable software and microcode allow you to load new software images into
Flash memory remotely, without having to physically access the router shelf, for fast
and reliable upgrades.
This chapter provides physical and functional overviews to familiarize you with your
new Cisco AS5800. It contains physical descriptions of system hardware and major
components and functional descriptions of component features.

Note Descriptions and examples of software commands appear in this document only
when they are necessary for installing the system hardware. For software
configuration information, refer to the Cisco AS5800 Universal Access Server
Software Installation and Configuration Guide that shipped with your system. The
Cisco AS5800 Universal Access Server Software Installation and Configuration
Guide will be replaced by the Cisco AS5800 Universal Access Server Operation,
Administration, Maintenance, and Provisioning Guide, available later this year.
System Components
The following sections in this chapter describe the core system components:
Cisco 5814 Dial Shelf
Dial Shelf Backplane
Dial Shelf Field-Replaceable Units
Dial Shelf Controller Card
Dial Shelf Filter Module
Cisco 7206 Router Shelf
DC-Input Power Specifications
Power Requirements
The Cisco AS5800 is designed to be rack-mounted. A rack-mount kit is included with
each Cisco 5814 dial shelf and each Cisco 7206 router shelf. Each rack-mount kit
provides the hardware needed to mount the dial shelf and router shelf in a standard,
19-in. equipment rack or standard telco rack. If you plan to use a 23-in. equipment
rack, you must provide your own brackets or shelves to accommodate the Cisco 7206
router shelf and optional AC power supply. For clearance requirements and rack-
mount installation considerations, refer to the section "Site Specifications" in the
chapter "Preparing for Installation."
Figure 1-1 shows a front view of a Cisco AS5800, and Figure 1-2 shows a rear view.
Figure 1-3 shows a front view of a Cisco AS5800 with the enhanced power supply,
and Figure 1-4 shows a rear view of a Cisco AS5800 with the enhanced power supply.

Figure 1-1:Cisco AS5800—Front View
Figure 1-2: Cisco AS5800—Rear View

Figure 1-3: Cisco AS5800 with Enhanced AC-Input Power Shelf—Front View
Figure 1-4: Cisco AS5800 with Enhanced AC-Input Power Shelf—Rear View

Cisco 5814 Dial Shelf
The Cisco 5814 dial shelf contains 14 slots (numbered 0 to 13 on the backplane) and
can support as many as 10 modem cards, 2 T3 or 4 T1 trunk cards, and 2 dial shelf
controllers (DSCs). Slots 12 and 13 in the dial shelf are dedicated slots for the DSCs.
Metal guard pins on the backplane module prevent you from installing any other type
of card in these two slots. The modular chassis supports online insertion and removal
(OIR) and redundant power and includes environmental monitoring and feedback
control.
The dial shelf contains CT1/CE1 or CT3 Primary Rate Interfaces (PRIs) that
terminate ISDN and modem calls and break out individual calls from the appropriate
telco services. Digital signal level 0 (DS0) or ISDN calls are terminated on the trunk
card High-Level Data Link Control (HDLC) controllers, and analog calls are sent to
modem resources on the modem cards. As a result, any DS0 can be mapped to any
HDLC controller or modem module. You can install multiple ingress interface cards
of like or different types, which enables you to configure your systems as fully
operative, port redundant, or card redundant, depending on your specific needs.
Dial Shelf Backplane
The Cisco AS5800 is equipped with a field-replaceable backplane module, which is

designed to meet critical safety, isolation, and electromagnetic compatibility (EMC)
requirements. The Cisco 5814 dial shelf backplane includes 14 slots that seat the
ingress trunk cards, the modem cards, and the dial shelf controller cards. Figure 1-6
shows the Cisco 5814 dial shelf with no cards installed, as viewed from the system
front.
Figure 1-6: Cisco 5814 Dial Shelf Backplane—Front View
The dial shelf backplane contains no active components, except for the nonvolatile
random-access memory (NVRAM) used for system identification. This is located
toward the top of the backplane and provides 1024 bits of nonvolatile read-write
memory.

The dial shelf backplane contains the connectors that connect directly with the dial
shelf cards and dial shelf controller cards. It also includes a 20-pin molex MiniFit
connector that connects to the blower assembly. The dial shelf backplane also
includes additional maintenance bus (MBus) connectors to the power-entry modules
(PEMs) and filter module, which are used for monitoring environmental conditions.
The dial shelf backplane first receives -48 VDC power from the DC-input power
supplies by way of the filter module, and the power is then distributed throughout the
dial shelf. The DC PEMs connect to the backplane using four blind-mating 1.25-in.
power studs, which are located near the bottom of the backplane.
Three bus connections are routed over the backplane:

The backplane interconnect bus (BIC bus) connects the dial shelf cards to the
dial shelf controller cards and provides communication between the dial shelf
and the router shelf.
The TDM bus transmits clocks and frame pulses to all dial shelf cards and dial
shelf controller cards.
The maintenance bus (MBus) monitors system environmental conditions.
Dial Shelf Controller Card
The dial shelf controller card is the main processor card for the dial shelf, and it
performs the following functions:
Links the dial shelf to the router shelf, where data is transferred as Ethernet
packets encapsulated in proprietary protocol
Interconnects trunk cards and modem cards
A backplane interconnect concentrator on each dial shelf controller card
connects to each dial shelf card installed in the dial shelf.
Boots and reloads software images
Provides source clocks used by all dial shelf cards and power supplies
Extracts an external reference clock from an external E1 or T1 signal through
a BNC connector on the front panel
Connects to an external alarm source through a DB-15 serial connector located
on the front panel
Install the dial shelf controller card in the Cisco 5814 dial shelf in either of the two
far-right slots (numbered 12 and 13). The card plugs directly into the backplane.
The dial shelf controller card consists of the following components:

CPU (IDT R4700)
150-MHz microprocessor
I/O controller
Onboard Flash memory
PCMCIA Flash memory

Boot Flash memory
EPROM
Cisco 7206 Router Shelf
This section provides physical and functional overviews of the Cisco 7206 router
shelves. It contains physical descriptions of the router hardware and major
components and functional descriptions of hardware-related features.
The Cisco 7206 router supports call signaling for PRI interfaces; packet processing;
and multiprotocol, multimedia routing and bridging with all commonly used high-
speed LAN and WAN interfaces, including Ethernet, Fast Ethernet (FE),
Asynchronous Transfer Mode (ATM), High-Speed Serial Interface (HSSI), and Fiber
Distributed Data Interface (FDDI).
The Cisco 7206 router shelf handles upper layer routing tasks and provides the
following features:
OIR—Allows you to add, replace, or remove port adapters without interrupting the
system or entering any console commands.
Dual hot-swappable, load-sharing power supplies—Provide system power

redundancy; if one power supply or power source fails, the other power supply
maintains system power without interruption. Also, when one power supply is
powered off, the second power supply immediately takes over the router's power
requirements without interrupting normal operation.
Environmental monitoring and reporting functions—Allow you to maintain normal

system operation by resolving adverse environmental conditions prior to loss of
operation.
Downloadable software—Allows you to load new images into Flash memory

remotely, for fast, reliable upgrades without having to physically access the Cisco
7206 router.

Note In Figure 1-19 a blank port adapter is installed in slot 5. To ensure adequate
airflow across the port adapters, each slot must be filled with either a port adapter or a
blank port adapter.
Network Interfaces
Network interfaces reside on port adapters that provide the connection between the
router's three peripheral component interconnect (PCI) buses and external networks.
The Cisco 7206 has six slots (slots 1 to 6) for the port adapters, one slot for an
Input/Output (I/O) controller, and one slot for a network processing engine (NPE).
You can place port adapters in any of the six available slots.
The front of the Cisco 7206 provides access to an I/O controller and up to six network
interface port adapters. The I/O controller contains the following:
Local console port for connecting a data terminal or data terminal equipment (DTE)
and an auxiliary port for connecting a modem or other data communications
equipment (DCE) or other devices for configuring and managing the router
Two personal computer memory card international association (PCMCIA) slots for
Flash memory cards
Optional Fast Ethernet port, which provides a 100-Mbps connection to the network
Note The I/O controller is available with or without a Fast Ethernet port. The I/O
controller with a Fast Ethernet port is equipped with both a media-independent
interface (MII) receptacle and an RJ-45 receptacle; however, only one of these two
receptacles can be used at a time.
The port adapters installed in the Cisco 7206 router are of the same type as those
installed on the second-generation Versatile Interface Processors (VIP2s) in the Cisco

7500 series routers, in Cisco 7000 series routers using the Cisco 7000 series Route
Switch Processor (RSP7000) and Cisco 7000 series Chassis Interface (RSP7000CI),
and in the Cisco uBR7246 universal broadband router. The port adapters installed in
the Cisco 7206 support OIR. For an explanation of OIR, see the "Online Insertion and
Removal" section.
Note The I/O controller does not support OIR. You must power down the Cisco 7206
before removing the I/O controller from either router shelf.
Port adapter slots in the Cisco 7206 routers are numbered from left to right from the
bottom up, beginning with port adapter slot 1 and continuing through port adapter slot
6. Port adapter slot 0 is the Fast Ethernet port on the I/O controller. (See Figure 1-20.)
Figure 1-20: Port Adapter Slot Numbering
Power Supplies
The Cisco 7206 router is equipped with one 280W AC-input or one 280W DC-input
power supply. A fully configured Cisco 7206 router operates with only one installed
power supply; however, a second, optional power supply of the same type provides
hot-swappable, load-sharing, redundant power. Figure 1-21 shows the rear of a Cisco
7206 router configured with a single AC-input power supply. (A power supply filler
plate is installed over the second power supply bay.)
Caution Do not mix power supplies in the Cisco 7206. In dual power supply
router configurations, both power supplies must be of the same type (two AC-
input power supplies or two DC-input power supplies).
The power supply has the router's main power switch and either an AC-input power
receptacle or a hardwired DC-input power cable (depending on the type of installed
power supply). The rear of the Cisco 7206 router provides access to the network
processing engine and the power supplies. Adjacent to the power supply bays are two
chassis ground receptacles that provide a chassis ground connection for ESD
equipment or a two-hole grounding lug. (See Figure 1-21.)

Figure 1-21: Cisco 7206 Router—Rear View
Three internal fans draw cooling air into chassis and across internal components to
maintain an acceptable operating temperature. The three fans are enclosed in a tray
that is located in the subchassis.
Caution To ensure the proper flow of cooling air across the internal components,
make sure blank port adapters are installed in all unoccupied port adapter slots
and power supply filler plates are installed in unoccupied power supply bays.

Router Configuration
Lesson 1 - Becoming familiar with the Router

The initial display when you access a router through the console port.
You will see the prompt "Router>". This is the user mode prompt.
Type "?" and press enter. This will show you the commands available from this
prompt.
Do not run any of the commands yet, you will use all commands in later lessons.
Type "enable" and press enter. This will take you into privileged mode.
Type "?". This will show you the commands available from this prompt.
You will see the prompt "Router#". This is the privileged mode prompt.
Type "config" to enter configuration mode.
When prompted, "Configuring from terminal, memory, or network [terminal]?",
press enter.
Type "line vty 0 4". This is the virtual terminal (telnet) configuration
Type "exit" to return to the config prompt.

Type "interface ethernet 0". This is the configuration for the Ethernet port.
Press CTRL-Z to exit from config mode, to privileged mode.
Type "show running-config" to show how your router is configured.
There should not be much information here yet. Later, after you configure your router,
you will observe how this changes.
Type "show history" to view the recent commands that you typed.
Type "disable" to exit privileged mode.

Type "show version" to gather information about your IOS.

Lesson 2 - Changing hostname and passwords

You will see the prompt "Router>". This is the user mode prompt.
Type "enable" to take you into privileged mode.
You will see the prompt "Router#"
Type "config terminal" to go directly into configuration mode.
Type "hostname Router1" to change the name of the router to Router1
Note that your prompt has now changed to reflect the new hostname.
You will now add security to your router by adding passwords. The first two
passwords that you will enter are the password [i.e simple password or password
which is saved unencrypted in router] and the secret [i.e. encrypted password]. Both
of these passwords are used to challenge users as they enter privileged mode. The
simple password is only used if there is no secret password or else secret will override
the simple password.
While still in config mode, type "enable password en123". (To configure simple
password on your router).
Now let's try the password.
Use CTRL-Z to exit configure mode.
Type "disable" to leave privileged mode.
Type "enable" to re-enter privileged mode.
You will be prompted for a password. Type "en123", or the password you chose.
Your password should be accepted, and you should now be in privileged mode.
Type "show running-config". Notice that your password is displayed in the
configuration.
Type "config terminal" to enter configuration mode.

Type "enable secret secret123". (You can use any valid password for this exercise).
This is the secret that you will provide when you next enter privileged mode.
Now let's try the password.

Use CTRL-Z to exit configure mode.
Type "disable" to leave privileged mode.
Type "enable" to re-enter privileged mode.
You will be prompted for a password. Type "en123". Notice that your access is
denied.Type "secret123". Your password should be accepted, and you should now be
in privileged mode.

Type "line vty 0 4". This is the configuration command for virtual terminals of 5
users i.e. 0-4, and is used for telnet sessions. Here you can provide the telnet
password. The maximum number of users supported for telnet session may change
from router to router.
Type "password vty123". This enters the password vty123 for telnet connections.
Type "login". This command tells the router to allow users to connect through telnet.
Type "exit" to leave virtual terminal configuration. Please note: The password you
have just assigned applies to telnet sessions.
Now, we will configure a password on a line console.

Type "line console 0" to enter the console configuration.
Type "login"
Type "password con123". This sets the console password to con123. The console
password is used to log into routers via direct console connection.
Type "ctrl-z" to exit config mode.

If you want to remove the passwords, follow these steps:
Type "configure terminal" to enter config mode.
Type "no enable password en123" to remove the enable simple password.
Type "no enable secret secret123" to remove the enable secret.
Type "ctrl-z" to exit config mode.

Lesson 3 - Saving and Restoring configurations

Enter the router in user mode. (If you are in config mode, type exit to enter user
mode).
Type "show running-config" to show how your router is configured. ( or you can use
“do” keyword before “show” command in order to run ―show‖ command in config
mode i.e. you can type ―do show running-config‖ in config mode to show how your
router is configured.)
Your running configuration is the settings that are currently stored in memory on your
router. Your startup configuration is the configuration that the router will load when
you reboot. Since these are not always the same, it is important to save your running
configuration to your startup configuration, whenever permanent changes are made to
the router's configuration.
Type "enable" to enter privileged mode.

Type "configure terminal" to enter config mode.
Type "hostname router1" to change the name of the router.
Type "Ctrl-z" to exit out of configuration mode.
Type "copy running-config startup-config" to save the configuration in memory to
your start-up configuration.
Now restart your router. Note that the hostname is "Router1", and not the default
"Router".
Type "enable" to enter privileged mode.
Now change the router name to whatever you like.
Type "Ctrl-z" to exit out of configuration mode.
Now, in privileged mode , type "copy startup-config running-config" to load the

start-up config into memory without rebooting the router.
Note that when the startup config loads, the prompt returns to "Router1"
At this point, you have learned how to:
How to navigate through the different prompts on your router.
How to change the hostname of your router.
How to configure and remove passwords on your router.
How to save your configurations on your router.

Lesson 4 - Setting up the Interfaces

Type “show interface ?” to get the list of interfaces available in the router.
Type "show interface ethernet 0". (Note here that line protocol is down because you may not
be connected through cable to this port. 0 here represents number through which router
identifies Ethernet port. If there is one Ethernet port in your router, then its number will
always be 0. If there are two then one is identified by 0 and other by 1. The same concept
applies for more than two Ethernet ports. The number and type of ports supported in router
may change from router to router. For example, some router may not have Ethernet port but
they may be having Fast Ethernet or Gigabit Ethernet port or combination of both.)
Type "show interface serial 0". (To see the description of serial port if available in your
router. If no cable is connected then line protocol will be down else it will be up.)
Type "interface ethernet 0" to enter interface configuration mode for the Ethernet interface.
Suppose network interface of the router is to be configured with an IP address of 172.10.0.1.

We will assign this IP address and a default subnet mask to this interface:
Type "ip address 172.10.0.1 255.255.0.0" to assign the IP configuration.
Type "no shutdown" to enable the interface.
Type "exit" to leave the Ethernet interface configuration.
Here's how you configure the serial interface:
Type "interface serial 0" to enter interface configuration mode for the serial interface.
Type "ip address 210.16.54.1 255.255.255.0" to assign the IP address and subnet mask.
Type "no shutdown" to enable the interface.
Type "exit" to leave the serial interface configuration.
Type "ctrl-z" to leave config mode.
Now we can check our configurations:
Make sure you are in privileged mode.
Type "show interface ethernet 0". Note that line protocol is up. If it is not up, repeat this lab.
Type "show interface serial 0". Note that line protocol is up. If it is not up, repeat this lab.
Type "show running-config". Note the IP addresses of Ethernet0 and Serial0 entries.

Lesson 5 - Static Routing

Type "show ip route". Note that two directly connected routes are shown.
Enter configuration mode to enter routing information. (Type "configure terminal"
or the abbreviated version "config t". Either command can be used on a router).
To add a route, you must specify the destination network and the port that traffic must
use to reach the remote network. To reach 192.168.10.0 traffic must flow through the
serial port 210.16.54.1.
Type "ip route 192.168.10.0 255.255.255.0 210.16.54.1". This command establishes
an IP route to network 192.168.10.0 with a 24 bit net-mask through port 210.16.54.1
Type "ip route 192.168.50.0 255.255.255.0 210.16.54.1". This command establishes

an IP route to network 192.168.50.0 with a 24 bit net-mask through port 210.16.54.1
Type "Ctrl-z" to exit from config mode.
Type "show ip route". Note that the two static routes are shown in addition to the two
direct routes. If you do not see both static routes, repeat this lesson from the
beginning.
We will now look at how to remove static routes:

Enter config mode. (Type "configure terminal" or "config t")
To undo a command, like setting a route, we need to type the same command, with
the word NO in front of it:
Type "no ip route 192.168.10.0 255.255.255.0 210.16.54.1". This command removes
the route to network 192.168.10.0
Type "no ip route 192.168.50.0 255.255.255.0 210.16.54.1". This command removes
the route to network 192.168.50.0
Type "Ctrl-z" to exit from config mode.

Type "show ip route". Note that the two static routes are now gone, and only directly
connected routes remain
At this point, you have learned how to:

How to configure interfaces with IP address and subnet masks.
How to display configurations for the interfaces.
How to configure static routes on your router.
How to remove static routes on your router.

Lesson 6 - Dynamic Routing

Note: To use dynamic routing, the other routers in your network must use the same
routing protocol. For this the other router will work with either RIP or OSPF.
Start the router Go into privileged mode.
Type "show ip route". Note that two directly connected routes are shown.
Type "router rip" to enable RIP on your router.
Once RIP is enabled on a router, you must specify each network in which the router
will advertise routing.
Type "network 210.16.54.0"

Type "network 172.10.0.0"
Dynamic routing is now configured through RIP.
Type Ctrl-z to exit config mode.
Type "show ip route". Note that routes to all four networks are shown.
The same steps would be used to establish OSPF routing:

First remove RIP by typing "no router rip"
Type "router OSPF" to enable OSPF on your router.
Once OSPF is enabled on a router, you must specify each network in which the router
will advertise routing.
Type "network 210.16.54.0 0.0.0.255 area 0" (If this interface is in area 0. The
format of mask is complement (i.e. opposite) of the format that is usually used. This
mask is obtained by replacing 1 by 0 and 0 by 1 in the original mask).
Type "network 172.10.0.0 0.0.255.255 area 0"
Dynamic routing is now configured through OSPF.
Type Ctrl-z to exit config mode.
Type "show ip route". Note that routes to all four networks are shown.

Lesson 7 - On your own: Practice makes perfect!

Check to see how well you do from memory. Each of the following exercises comes
from the lessons above. See if you can remember the commands and complete this
lesson without reviewing previous lessons.
Now proceed with the following exercises:

1. Copy your running configuration to your startup configuration.
2. Set up passwords for privileged mode, Telnet, and the console.
3. Change the hostname of the router to "Router1".
4. Set the IP address of the serial interface.
5. Set the IP address of the LAN interface.
6. Establish static routing.
7. Establish Dynamic routing on the router using RIP.

8. Establish Dynamic routing through OSPF.
9. Verify your connections by pinging the other hosts in your network (if available it
will work).

Module 2-Ip Routing Basic

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Module 2-Ip Routing Basic

Uploaded by

Copyright:

Available Formats

Bharat Sanchar Nigam Limited Hkkjr lapkj fuxe fyfeVsM

JTO Ph-II DATA NETWORK

BHARAT RATNA BHIMRAO AMBEDKAR

PHASE II SPECIALIZATION TRAINING

Week-2 IP ROUTING BASICS:-

S No Topic Page No.

Networking Switches must implement a normal path selection

The routing function must achieve the following requirements :

Efficiency of a routing technique/ algorithm gets decided by the quantum of overhead

Thus, Routing is essentially a method of path selection and is an overhead activity.

100.3.4.0 100.1.1.5 7 100.1.1.5 3CE9...

Fig.1 Routing & Switching

Routing & Network Layer Addresses

Fig. 2 Use of Network Layer Addresses in Routing

Three general prerequisites must be met to perform routing :

Types of Routing : Static, Default, Dynamic

Refers to routes to destinations being setup manually

Refers to a ―last resort‖ outlet – traffic to destinations

Figure 3 below illustrates the concept of Static and default Routing.

Static Routing 10.1/16

Fig.3 Static and Default Routing

Refers to routes being learnt via an internal or

Fig. 4 Dynamic Routing

Routing protocols bear a resemblance to capitalist market economics. In both systems,

To make this work, two things are needed :

This algorithm do not base their routing decisions on measurements or estimates of

The success of dynamic routing depends on two basic router functions :

Representing Distance with Metrics

Metrics can be calculated based on a single characteristic of the path or by combining

Path cost is the sum of cost associated with each link to

Distance Vector Routing

Routing Routing Routing Routing

Fig. 5 Distance Vector Routing Updates

Distance vector information is similar to the information found on signs at a highway

Distance Vector Network Discovery

Routing Table Routing Table Routing Table

100.2.0.0 S2 0 100.3.0.0 S1 0 100.4.0.0 S1 0

100.3.0.0 S2 1 100.4.0.0 S1 1 100.2.0.0 S0 1

100.4.0.0 S2 2 100.1.0.0 S2 1 100.1.0.0 S0 2

Fig. 6 Distance Vector Route Discovery

Link State Routing

The 5 step concept is stated below :

1. Discover the neighbors and learn their network addresses

Link-State Network Discovery

Routing Table Routing Table Routing Table

Fig. 7 Link State Routing

Link-State Network discovery proceeds as follows :

Comparison of Distance Vector Routing & Link-State Routing

Distance Vector Link State

Network Topology is viewed from Entire Network Topology is common to all

Fig. 8 General illustration of Protocol relationships

Distance Vector Protocols :

Link State Protocols :

Larger address space

Stateless autoconfiguration is only suitable for hosts: routers must be configured

Most environments do not currently have their network infrastructures configured to

The m6bone is catering for deployment of a global IPv6 Multicast network.

With the notable exceptions of stateless autoconfiguration, more flexible addressing

Additional information can be found in RFC 4291 - IP Version 6 Addressing

Literal IPv6 Addresses in URLs

In a URL the IPv6-Address is enclosed in brackets. Example:

IPv6 networks are written using CIDR notation.