COMP313 – Computer Systems

IP Routing Notes
The following set of notes were extracted from Wikipedia (http://www.wikipedia.com), and covers
the following topics:
• Routing Tables (RIB)
• Interior Gateway Protocols
◦ Routing Information Protocol (RIP)
◦ Open Shortest Path First (OSPF)
◦ Intermediate System to Intermediate System (IS-IS)
• Exterior Gateway Protocols
◦ Border Gateway Protocol (BGP)
• Address Resolution Protocol (ARP)

Introduction
When a URL, such as http://www.moodle.cs.ukzn.ac.za/cs, is requested by a web browser, a
number of Internet protocols are involved in delivering IP packets from the source to the
destination. In this particular case, the destination is a webserver hosted by a computer system on
one of the UKZN LANs, and is, therefore not likely to be on LAN the URL was requested from.
(e.g. your home PC)
The first protocol involved in delivering IP packets, is the Domain Name System (DNS). It is used
by the browser to look up the destination IP address that has been registered for the
www.moodle.cs.ukzn.ac.za domain name. Once the IP address has been obtained (e.g.
146.230.90.21), and it has been determined that the destination address is on a remote LAN, the IP
packets are routed to the next gateway, or hop, along the route to the destination LAN. On the
source system, this is called the default gateway. One or more hops, or gateways, might need to be
traversed in order for the IP packets to arrive at their destination LAN.
The TCP/IP protocol is the second protocol involved, as it is used to establish a socket-based
connection to the webserver. The contents of the IP packets sent over the connection will be the
HTTP protocol messages to request the 'cs' resource from the webserver. HTTP is a text-based
protocol, and is the third protocol involved in our example scenario.
Throughout the routing process, each router along the way determines if the IP packet is destined
for a local network (which it is directly connected to), or a remote LAN. This calculation is done by
looking at the destination network address (e.g. 146.230.90.0), which is extracted from the
destination IP address of the IP packet by use of the network mask (e.g. 255.255.255.0) of the LAN.
If the destination is a remote LAN, the router performs a Routing Information Base (RIB), query to
deternine the next router to forward the IP packets to. This process is repeated until the packets
arrive at their destination network.
At this point the IP routing process is over, and all that needs to be done is to resolve the destination
IP Address to the hardware address of the destination system on the LAN. This is done via the
Address Resolution Protocol (ARP), which is the fourth protocol in our scenario, and the packets
are delivered to their destination.
There are other protocols involved, however, but they do not necessarily take place during the
actual routing of packets. They are the routing protocols, and are usually run between routers of
MANs and WANs periodically. In order for our HTTP scenario to work, we say that the routing
protocols need to have stabilised at time of the web URL query – i.e. the routing protocols occur
before the HTTP query, but not in any particular order. The remainder of these notes describe the
routing protocols, all of which are centered around a common data structure – the routing table, or
routing information base.

Routing Information Base (RIB)

In computer networking a routing table, or routing information base (RIB), is a data table stored in a
router or a networked computer that lists the routes to particular network destinations, and in some
cases, metrics (distances) associated with those routes. The routing table contains information about
the topology of the network immediately around it. The construction of routing tables is the primary
goal of routing protocols. Static routes are entries made in a routing table by non-automatic means
and which are fixed rather than being the result of some network topology "discovery" procedure.
A routing table uses the same idea that one does when using a map in package delivery. Whenever a
node needs to send data to another node on a network, it must first know where to send it. If the
node cannot directly connect to the destination node, it has to send it via other nodes along a proper
route to the destination node. Most nodes do not try to figure out which route(s) might work;
instead, a node will send an IP packet to a gateway in the LAN, which then decides how to route the
"package" of data to the correct destination. Each gateway will need to keep track of which way to
deliver various packages of data, and for this it uses a Routing Table. A routing table is a database
which keeps track of paths, like a map, and allows the gateway to provide this information to the
node requesting the information.
With hop-by-hop routing, each routing table lists, for all reachable destinations, the address of the
next device along the path to that destination: the next hop. Assuming that the routing tables are
consistent, the simple algorithm of relaying packets to their destination's next hop thus suffices to
deliver data anywhere in a network. Hop-by-hop is the fundamental characteristic of the IP
Internetwork Layer and the OSI Network Layer.
The primary function of a router is to forward a packet toward its destination network, which is the
destination IP address of the packet. To do this, a router needs to search the routing information
stored in its routing table.
A routing table is a data file in RAM that is used to store route information about directly connected
and remote networks. The routing table contains network/next hop associations. These associations
tell a router that a particular destination can be optimally reached by sending the packet to a specific
router that represents the "next hop" on the way to the final destination. The next hop association
can also be the outgoing or exit interface to the final destination.
The network/exit-interface association can also represent the destination network address of the IP
packet. This association occurs on the router's directly connected networks.
A directly connected network is a network that is directly attached to one of the router interfaces.
When a router interface is configured with an IP address and subnet mask, the interface becomes a
host on that attached network. The network address and subnet mask of the interface, along with the
interface type and number, are entered into the routing table as a directly connected network. When
a router forwards a packet to a host, such as a web server, that host is on the same network as a
router's directly connected network.
A remote network is a network that is not directly connected to the router. In other words, a remote
network is a network that can only be reached by sending the packet to another router. Remote
networks are added to the routing table using either a dynamic routing protocol or by configuring
static routes. Dynamic routes are routes to remote networks that were learned automatically by the
router, using a dynamic routing protocol. Static routes are routes to networks that a network
administrator manually configured.
The need to record routes to large numbers of devices using limited storage space represents a
major challenge in routing table construction. In the Internet, the currently dominant address
aggregation technology is a bitwise prefix matching scheme called Classless Inter-Domain Routing
(CIDR).
The routing table consists of at least three information fields:
1. the network id: i.e. the destination subnet
2. cost/metric: i.e. the cost or metric of the path through which the packet is to be sent
3. next hop: The next hop, or gateway, is the address of the next station to which the packet is
to be sent on the way to its final destination
Depending on the application and implementation, it can also contain additional values that refine
path selection:
1. quality of service associated with the route. For example, the U flag indicates that an IP
route is up.
2. links to filtering criteria/access lists associated with the route
3. interface: such as eth0 for the first Ethernet card, eth1 for the second Ethernet card, etc.
Routing tables are also a key aspect of certain security operations, such as unicast reverse path
forwarding (uRPF). In this technique, which has several variants, the router also looks up, in the
routing table, the source address of the packet. If there exists no route back to the source address,
the packet is assumed to be malformed or involved in a network attack, and is dropped.
Shown below is an example of what the table above could look like on an average computer
connected to the internet via a home router:

Network Destination Netmask Gateway Interface Metric

0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.100 10
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.0.0 255.255.255.0 192.168.0.100 192.168.0.100 10
192.168.0.100 255.255.255.255 127.0.0.1 127.0.0.1 10
192.168.0.255 255.255.255.255 192.168.0.100 192.168.0.100 10

• The columns Network Destination and Netmask together describe the Network id as
mentioned earlier. For example, destination 192.168.0.0 and netmask 255.255.255.0 can be
written as network id 192.168.0.0/24.
• The Gateway column contains the same information as the Next hop, i.e. it points to the
gateway through which the network can be reached.
• The Interface indicates what locally available interface is responsible for reaching the
gateway. In this example, gateway 192.168.0.1 (the internet router) can be reached through
the local network card with address 192.168.0.100.
• Finally, the Metric indicates the associated cost of using the indicated route. This is useful
for determining the efficiency of a certain route from two points in a network. In this
example, it is more efficient to communicate with the computer itself through the use of
address 127.0.0.1 (called “localhost”) than it would be through 192.168.0.100 (the IP
address of the local network card).
Routing tables are generally not used directly for packet forwarding in modern router architectures;
instead, they are used to generate the information for a smaller forwarding table. A forwarding table
contains only the routes which are chosen by the routing algorithm as preferred routes for packet
forwarding. It is often in a compressed or pre-compiled format that is optimized for hardware
storage and lookup.
This router architecture separates the Control Plane function of the routing table from the
Forwarding Plane function of the forwarding table. This separation of control and forwarding
provides uninterrupted performance.

Interior Gateway Protocols (IGP)

An Interior Gateway Protocol (IGP) is a type of protocol used for exchanging routing information
between gateways (commonly routers) within an Autonomous System (for example, a system of
corporate local area networks). This routing information can then be used to route network-level
protocols like IP.
Interior gateway protocols can be divided into two categories: distance-vector routing protocols and
link-state routing protocols. Specific examples of IGP protocols include Open Shortest Path First
(OSPF), Routing Information Protocol (RIP) and Intermediate System to Intermediate System (IS-
IS).
By contrast, exterior gateway protocols are used to exchange routing information between
Autonomous Systems and rely on IGPs to resolve routes within an AS.

Distance-vector routing protocol

Distance-vector routing protocols use the Bellman–Ford algorithm. In these protocols, each router
does not possess information about the full network topology. It advertises its distance value (DV)
calculated to other routers and receives similar advertisements from other routers unless changes are
done in local network or by neighbours (routers). Using these routing advertisements each router
populates its routing table. In the next advertisement cycle, a router advertises updated information
from its routing table. This process continues until the routing tables of each router converge to
stable values.
Some of these protocols have the disadvantage of slow convergence.
Examples of distance-vector routing protocols:
• Routing Information Protocol (RIP)
• Routing Information Protocol Version 2 (RIPv2)
• Routing Information Protocol Next Generation (RIPng), an extension of RIP version 2 with
support for IPv6
• Interior Gateway Routing Protocol (IGRP)
Link-state routing protocol
In link-state routing protocols, each router possesses information about the complete network
topology. Each router then independently calculates the best next hop from it for every possible
destination in the network using local information of the topology. The collection of best-next-hops
forms the routing table.
This contrasts with distance-vector routing protocols, which work by having each node share its
routing table with its neighbours. In a link-state protocol, the only information passed between the
nodes is information used to construct the connectivity maps.
Examples of link-state routing protocols:
 • Open Shortest Path First (OSPF)
• Intermediate system to intermediate system (IS-IS)

Routing Information Protocol (RIP)

The Routing Information Protocol (RIP) is one of the oldest distance-vector routing protocols,
which employs the hop count as a routing metric. RIP prevents routing loops by implementing a
limit on the number of hops allowed in a path from the source to a destination. The maximum
number of hops allowed for RIP is 15. This hop limit, however, also limits the size of networks that
RIP can support. A hop count of 16 is considered an infinite distance, in other words the route is
considered unreachable.
RIP implements the split horizon, route poisoning and holddown mechanisms to prevent incorrect
routing information from being propagated. These are some of the stability features of RIP. It is also
possible to use the Routing Information Protocol with Metric-Based Topology (RMTI) algorithm to
cope with the count-to-infinity problem. With RMTI, it is possible to detect every possible loop
with a very small computation effort.
Originally, each RIP router transmitted full updates every 30 seconds. In the early deployments,
routing tables were small enough that the traffic was not significant. As networks grew in size,
however, it became evident there could be a massive traffic burst every 30 seconds, even if the
routers had been initialized at random times. It was thought, as a result of random initialization, the
routing updates would spread out in time, but this was not true in practice. Sally Floyd and Van
Jacobson showed in 1994 that, without slight randomization of the update timer, the timers
synchronized over time. In most current networking environments, RIP is not the preferred choice
for routing as its time to converge and scalability are poor compared to EIGRP, OSPF, or IS-IS (the
latter two being link-state routing protocols), and (without RMTI) a hop limit severely limits the
size of network it can be used in. However, it is easy to configure, because RIP does not require any
parameters on a router unlike other protocols.
RIP uses the User Datagram Protocol (UDP) as its transport protocol, and is assigned the reserved
port number 520.
RIP defines two types of messages.
1. Request Message
2. Response Message
When a RIP router comes up, it sends a broadcast Request Message on all of its RIP enabled
interfaces. All the neighbouring routers which receive the Request message respond back with the
Response Message containing their Routing table. The Response Message is also gratuitously sent
when the Update timer expires. On receiving the Routing table, the router processes each entry of
the routing table as per the following rules
1. If there are no route entry matching the one received then the route entry is added to the
routing table automatically, along with the information about the router from which it
received the routing table
2. If there are matching entry but the hop count metric is lower than the one already in its
routing table, then the routing table is updated with the new route.
3. If there are matching entry but the hop count metric is higher than the one already in its
routing table, then the routing entry is updated with hop count of 16 (infinite hop). The
packets are still forwarded to the old route. A Holddown timer is started and all the updates
for that from other routers are ignored. If after the Holddown timer expires and still the
router is advertising with the same higher hop count then the value is updated into its routing
table. Only after the timer expires, the updates from other routers are accepted for that route.
Limitations
• Without using RMTI, the hop count cannot exceed 15, otherwise it will be considered
invalid.
• Most RIP networks are flat. There is no concept of areas or boundaries in RIP networks.
• Variable Length Subnet Masks are not supported by RIP version 1.
• Without using RMTI, RIP has slow convergence and count to infinity problems.

Open Shortest Path First (OSPF)

Open Shortest Path First (OSPF) is a link-state routing protocol for Internet Protocol (IP)
networks. It uses the link state routing algorithm and falls into the group of interior routing
protocols, operating within a single autonomous system (AS). It is defined as OSPF Version 2 in
RFC 2328 (1998) for IPv4. The updates for IPv6 are specified as OSPF Version 3 in RFC 5340
(2008).
OSPF is perhaps the most widely used interior gateway protocol (IGP) in large enterprise networks.
IS-IS, another link-state dynamic routing protocol, is more common in large service provider
networks. The most widely used exterior gateway protocol is the Border Gateway Protocol (BGP),
the principal routing protocol between autonomous systems on the Internet.
OSPF is an interior gateway protocol that routes Internet Protocol (IP) packets solely within a single
routing domain (autonomous system). It gathers link state information from available routers and
constructs a topology map of the network. The topology determines the routing table presented to
the Internet Layer which makes routing decisions based solely on the destination IP address found
in IP packets. OSPF was designed to support variable-length subnet masking (VLSM) or Classless
Inter-Domain Routing (CIDR) addressing models.
OSPF detects changes in the topology, such as link failures, and converges on a new loop-free
routing structure within seconds. It computes the shortest path tree for each route using a method
based on Dijkstra's algorithm, a shortest path first algorithm.
The OSPF routing policies to construct a route table are governed by link cost factors (external
metrics) associated with each routing interface. Cost factors may be the distance of a router (round-
trip time), network throughput of a link, or link availability and reliability, expressed as simple
unitless numbers. This provides a dynamic process of traffic load balancing between routes of equal
cost.
An OSPF network may be structured, or subdivided, into routing areas to simplify administration
and optimize traffic and resource utilization. Areas are identified by 32-bit numbers, expressed
either simply in decimal, or often in octet-based dot-decimal notation, familiar from IPv4 address
notation.
By convention, area 0 (zero) or 0.0.0.0 represents the core or backbone region of an OSPF
network. The identifications of other areas may be chosen at will; often, administrators select the IP
address of a main router in an area as the area's identification. Each additional area must have a
direct or virtual connection to the backbone OSPF area. Such connections are maintained by an
interconnecting router, known as area border router (ABR). An ABR maintains separate link state
databases for each area it serves and maintains summarized routes for all areas in the network.
OSPF does not use a TCP/IP transport protocol (UDP, TCP), but is encapsulated directly in IP
datagrams with protocol number 89. This is in contrast to other routing protocols, such as the
Routing Information Protocol (RIP), or the Border Gateway Protocol (BGP). OSPF handles its own
error detection and correction functions.
OSPF uses multicast addressing for route flooding on a broadcast domain. For non-broadcast
networks special provisions for configuration facilitate neighbor discovery. OSPF multicast IP
packets never traverse IP routers (never traverse Broadcast Domains), they never travel more than
one hop.
For routing multicast IP traffic, OSPF supports the Multicast Open Shortest Path First protocol
(MOSPF) as defined in RFC 1584. Cisco does not include MOSPF in their OSPF implementations.
PIM (Protocol Independent Multicast) in conjunction with OSPF or other IGPs, (Interior Gateway
Protocol), is widely deployed.
The OSPF protocol, when running on IPv4, can operate securely between routers, optionally using a
variety of authentication methods to allow only trusted routers to participate in routing. OSPFv3,
running on IPv6, no longer supports protocol-internal authentication. Instead, it relies on IPv6
protocol security (IPsec).
OSPF version 3 introduces modifications to the IPv4 implementation of the protocol. Except for
virtual links, all neighbor exchanges use IPv6 link-local addressing exclusively. The IPv6 protocol
runs per link, rather than based on the subnet. All IP prefix information has been removed from the
link-state advertisements and from the Hello discovery packet making OSPFv3 essentially protocol-
independent. Despite the expanded IP addressing to 128-bits in IPv6, area and router Identifications
are still based on 32-bit values.
OSPF was the first widely deployed routing protocol that could converge a network in the low
seconds, and guarantee loop-free paths. It has many features that allow the imposition of policies
about the propagation of routes that it may be appropriate to keep local, for load sharing, and for
selective route importing more than IS-IS. IS-IS, in contrast, can be tuned for lower overhead in a
stable network, the sort more common in ISP than enterprise networks. There are some historical
accidents that made IS-IS the preferred IGP for ISPs, but ISP's today may well choose to use the
features of the now-efficient implementations of OSPF, after first considering the pros and cons of
IS-IS in service provider environments.
As mentioned, OSPF can provide better load-sharing on external links than other IGPs. When the
default route to an ISP is injected into OSPF from multiple ASBRs as a Type I external route and
the same external cost specified, other routers will go to the ASBR with the least path cost from its
location. This can be tuned further by adjusting the external cost.
In contrast, if the default route from different ISPs is injected with different external costs, as a Type
II external route, the lower-cost default becomes the primary exit and the higher-cost becomes the
backup only.
The only real limiting factor that may compel major ISPs to select IS-IS over OSPF is if they have a
network with more than 850 routers. There is mention of an OSPF network with over 1000 routers,
but that is quite uncommon and the network must be specifically designed to minimize overhead to
achieve stable operation.

Neighbor relationships
Routers in the same broadcast domain or at each end of a point-to-point telecommunications link
form adjacencies when they have detected each other. This detection occurs when a router identifies
itself in a hello OSPF protocol packet. This is called a two-way state and is the most basic
relationship. The routers in an Ethernet or frame relay network select a designated router (DR) and
a backup designated router (BDR) which act as a hub to reduce traffic between routers. OSPF uses
both unicast and multicast to send "hello packets" and link state updates.
As a link state routing protocol, OSPF establishes and maintains neighbor relationships in order to
exchange routing updates with other routers. The neighbor relationship table is called an adjacency
database in OSPF. Provided that OSPF is configured correctly, OSPF forms neighbor relationships
only with the routers directly connected to it. In order to form a neighbor relationship between two
routers, the interfaces used to form the relationship must be in the same area. Generally an interface
is only configured in a single area, however you can configure an interface to belong to multiple
areas. In the second area, such an interface must be configured as a secondary interface. (A
neighbor state simulation shows how neighbor state changes from Down to Full Adjacency
progressively with exchanging Hello, DD, Request, Update, and Ack packets).

OSPF message types

Unlike RIP, OSPF does not send its information using the User Datagram Protocol (UDP). Instead,
OSPF forms IP datagrams directly, packaging them using protocol number 89 for the IP Protocol
field. OSPF defines five different message types, for various types of communication:
Hello:
As the name suggests, these messages are used as a form of greeting, to allow a router to discover
other adjacent routers on its local links and networks. The messages establish relationships between
neighboring devices (called adjacencies) and communicate key parameters about how OSPF is to be
used in the autonomous system or area.
Database Description:
These messages contain descriptions of the topology of the AS or area. That is, they convey the
contents of the link-state database for the autonomous system or area from one router to another.
Communicating a large LSDB may require several messages to be sent; this is done by having the
sending device designated as a master device and sending messages in sequence, with the slave
(recipient of the LSDB information) responding with acknowledgements.
Link State Request:
These messages are used by one router to request updated information about a portion of the LSDB
from another router. The message specifies exactly which link(s) about which the requesting device
wants more current information.
Link State Update:
These messages contain updated information about the state of certain links on the LSDB. They are
sent in response to a Link State Request message, and also broadcast or multicast by routers on a
regular basis. Their contents are used to update the information in the LSDBs of routers that receive
them.
Link State Acknowledgment:
These messages provide reliability to the link-state exchange process, by explicitly acknowledging
receipt of a Link State Update message.

Intermediate System to Intermediate System (IS-IS)

Intermediate System to Intermediate System (IS-IS) is a routing protocol designed to move
information efficiently within a computer network, a group of physically connected computers or
similar devices. It accomplishes this by determining the best route for datagrams through a packet-
switched network. The protocol was defined in ISO/IEC 10589:2002 as an international standard
within the Open Systems Interconnection (OSI) reference design. Though originally an ISO
standard, the IETF republished the protocol as an Internet Standard in RFC 1142. IS-IS has been
called "the de facto standard for large service provider network backbones."
IS-IS (pronounced "i-s i-s") is an interior gateway protocol, designed for use within an
administrative domain or network. This is in contrast to Exterior Gateway protocols, primarily
Border Gateway Protocol (BGP), which is used for routing between autonomous systems (RFC
1930).
IS-IS is a link-state routing protocol, operating by reliably flooding link state information
throughout a network of routers. Each IS-IS router independently builds a database of the network's
topology, aggregating the flooded network information. Like the OSPF protocol, IS-IS uses
Dijkstra's algorithm for computing the best path through the network. Packets (datagrams) are then
forwarded, based on the computed ideal path, through the network to the destination.
The IS-IS protocol was developed by Digital Equipment Corporation as part of DECnet Phase V. It
was standardized by the ISO in 1992 as ISO 10589 for communication between network devices
which are termed Intermediate Systems (as opposed to end systems or hosts) by the ISO. The
purpose of IS-IS was to make possible the routing of datagrams using the ISO-developed OSI
protocol stack called CLNS.
IS-IS was developed at roughly the same time that the Internet Engineering Task Force IETF was
developing a similar protocol called OSPF. IS-IS was later extended to support routing of
datagrams in the Internet Protocol (IP), the Network Layer protocol of the global Internet. This
version of the IS-IS routing protocol was then called Integrated IS-IS (RFC 1195)

Comparison with OSPF

Both IS-IS and OSPF are link state protocols, and both use the same Dijkstra algorithm for
computing the best path through the network. As a result, they are conceptually similar. Both
support variable length subnet masks, can use multicast to discover neighboring routers using hello
packets, and can support authentication of routing updates.
While OSPF is natively built to route IP and is itself a Layer 3 protocol that runs on top of IP, IS-IS
is natively an OSI network layer protocol (it is at the same layer as CLNS). The widespread
adoption of IP worldwide may have contributed to OSPF's popularity. IS-IS does not use IP to carry
routing information messages. IS-IS is neutral regarding the type of network addresses for which it
can route. OSPF, on the other hand, was designed for IPv4. This allowed IS-IS to be easily used to
support IPv6. To operate with IPv6 networks, the OSPF protocol was rewritten in OSPF v3 (as
specificed in RFC 2740).
IS-IS routers build a topological representation of the network. This map indicates the subnets
which each IS-IS router can reach, and the lowest-cost (shortest) path to a subnet is used to forward
traffic.
IS-IS differs from OSPF in the way that "areas" are defined and routed between. IS-IS routers are
designated as being: Level 1 (intra-area); Level 2 (inter area); or Level 1-2 (both). Level 2 routers
are inter area routers that can only form relationships with other Level 2 routers. Routing
information is exchanged between Level 1 routers and other Level 1 routers, and Level 2 routers
only exchange information with other Level 2 routers. Level 1-2 routers exchange information with
both levels and are used to connect the inter area routers with the intra area routers.
In OSPF, areas are delineated on the interface such that an area border router (ABR) is actually in
two or more areas at once, effectively creating the borders between areas inside the ABR, whereas
in IS-IS area borders are in between routers, designated as Level 2 or Level 1-2. The result is that an
IS-IS router is only ever a part of a single area.
IS-IS also does not require Area 0 (Area Zero) to be the backbone area through which all inter-area
traffic must pass. The logical view is that OSPF creates something of a spider web or star topology
of many areas all attached directly to Area Zero and IS-IS by contrast creates a logical topology of a
backbone of Level 2 routers with branches of Level 1-2 and Level 1 routers forming the individual
areas.
IS-IS also differs from OSPF in the methods by which it reliably floods topology and topology
change information through the network. However, the basic concepts are similar.
OSPF has a larger set of extensions and optional features specified in the protocol standards.
However IS-IS is more easy to expand: its use of type-length-value data allows engineers to
implement support for new techniques without redesigning the protocol. For example, in order to
support IPv6, the IS-IS protocol was extended to support a few additional TLVs, whereas OSPF
required a new protocol draft (OSPFv3). In addition to that, IS-IS is less "chatty" and can scale to
support larger networks. Given the same set of resources, IS-IS can support more routers in an area
than OSPF. This has contributed to IS-IS as an ISP-scale protocol.
The TCP/IP implementation, known as "Integrated IS-IS" or "Dual IS-IS", is described in RFC
1195.

Exterior Gateway Protocols (EGP)

In contrast to an interior gateway protocol, an exterior gateway protocol is a routing protocol used
to exchange routing information between autonomous systems. This exchange is crucial for
communications across the Internet.
Notable exterior gateway protocols include Exterior Gateway Protocol and Border Gateway
Protocol.

Border Gateway Protocol (BGP)

Border Gateway Protocol (BGP) is a standardized exterior gateway protocol designed to exchange
routing and reachability information between autonomous systems (AS) on the Internet. The
protocol is often classified as a path vector protocol, but is sometimes also classed as a distance
vector routing protocol. The Border Gateway Protocol does not use Interior Gateway Protocol (IGP)
metrics, but makes routing decisions based on paths, network policies and/or rule-sets configured
by a network administrator. The Border Gateway Protocol plays a key role in the overall operation
of the Internet and is involved in making core routing decisions.
The Border Gateway Protocol is the successor to the Exterior Gateway Protocol (EGP) and is
currently the most widely used exterior gateway protocol by Internet service providers because BGP
allows for fully decentralised routing. BGP was originally designed to help transition from the core
ARPAnet model to a decentralized system that included the NSFNET backbone and its associated
regional networks.
The current version of BGP is version 4 (BGP4) codified in RFC 4271 since 2006. Early versions of
the protocol are widely considered obsolete and are rarely supported.[2] RFC 4271, which went
through more than 20 drafts based on the earlier RFC 1771 version 4. RFC 4271 version corrected a
number of errors, clarified ambiguities and brought the RFC much closer to industry practices.
Version 4 of BGP has been in use on The Internet since 1994. The major enhancement in version 4
was support for Classless Inter-Domain Routing and use of route aggregation to decrease the size of
routings.

Uses
Most Internet service providers must use BGP to establish routing between one another (especially
if they are multihomed).[citation needed] Therefore, even though most Internet users do not use it
directly, BGP is one of the most important protocols of the Internet.[citation needed] Compare this
with Signaling System 7 (SS7), which is the inter-provider core call setup protocol on the PSTN.
[citation needed]
Very large private IP networks use BGP internally. An example would be the joining of a number of
large OSPF (Open Shortest Path First) networks where OSPF by itself would not scale to size.
Another reason to use BGP is multihoming a network for better redundancy, either to multiple
access points of a single ISP or to multiple ISPs.
Operation
BGP neighbors, called peers, are established by manual configuration between routers to create a
TCP session on port 179. A BGP speaker sends 19-byte keep-alive messages every 30 seconds to
maintain the connection. Among routing protocols, BGP is unique in using TCP as its transport
protocol.
When BGP runs between two peers in the same autonomous system (AS), it is referred to as
Internal BGP (iBGP or Interior Border Gateway Protocol). When it runs between different
autonomous systems, it is called External BGP (EBGP or Exterior Border Gateway Protocol).
Routers on the boundary of one AS exchanging information with another AS are called border or
edge routers or simply eBGP peers and are typically connected directly, while iBGP peers can be
interconnected through other intermediate routers. Other deployment topologies are also possible,
such as running eBGP peering inside a VPN tunnel, allowing two remote sites to exchange routing
information in a secure and isolated manner. The main difference between iBGP and eBGP peering
is in the way routes that were received from one peer are propagated to other peers. For instance,
new routes learned from an eBGP peer are typically redistributed to all other iBGP peers as well as
all eBGP peers (if transit mode is enabled on the router). However, if new routes were learned on an
iBGP peering, then they are re-advertised only to all other eBGP peers. These route-propagation
rules effectively require that all iBGP peers inside an AS are interconnected in a full mesh.
Filtering routes learned from peers, their transformation before redistribution to peers or before
plumbing them into the routing table is typically controlled via route-maps mechanism. These are
basically rules which allow to apply certain actions to routes matching certain criteria on either
ingress or egress path. These rules can specify that the route is to be dropped or, alternatively, its
attributes are to be modified. It is usually the responsibility of the AS administrator to provide the
desired route-map configuration on a router supporting BGP.
In the simplest arrangement all routers within a single AS and participating in BGP routing must be
configured in a full mesh: each router must be configured as peer to every other router. This causes
scaling problems, since the number of required connections grows quadratically with the number of
routers involved. To alleviate the problem, BGP implements two options: route reflectors (RFC
4456) and BGP confederations (RFC 5065). The following discussion of basic UPDATE processing
assumes a full iBGP mesh.

Basic update processing

A given BGP router may accept NLRI UPDATEs from multiple neighbors and advertise NLRI
(Network Layer Reachability Information) to the same, or a different set, of neighbors.
Conceptually, BGP maintains its own "master" routing table, called the Loc-RIB (Local Routing
Information Base), separate from the main routing table of the router. For each neighbor, the BGP
process maintains a conceptual Adj-RIB-In (Adjacent Routing Information Base, Incoming)
containing the NLRI received from the neighbor, and a conceptual Adj-RIB-Out (Outgoing) for
NLRI to be sent to the neighbor.
Conceptual, in the preceding paragraph, means that the physical storage and structure of these
various tables are decided by the implementer of the BGP code. Their structure is not visible to
other BGP routers, although they usually can be interrogated with management commands on the
local router. It is quite common, for example, to store the two Adj-RIBs and the Loc-RIB together in
the same data structure, with additional information attached to the RIB entries. The additional
information tells the BGP process such things as whether individual entries belong in the Adj-RIBs
for specific neighbors, whether the peer-neighbor route selection process made received policies
eligible for the Loc-RIB, and whether Loc-RIB entries are eligible to be submitted to the local
router's routing table management process.
By eligible to be submitted, BGP will submit the routes that it considers best to the main routing
table process. Depending on the implementation of that process, the BGP route is not necessarily
selected. For example, a directly connected prefix, learned from the router's own hardware, is
usually most preferred. As long as that directly connected route's interface is active, the BGP route
to the destination will not be put into the routing table.

Route selection
The BGP standard specifies a number of decision factors, more than are used by any other common
routing process, for selecting NLRI (Network Layer Reachability Information) to go into the Loc-
RIB (Routing Information Base). The first decision point for evaluating NLRI is that its next-hop
attribute must be reachable (or resolvable). Another way of saying the next-hop must be reachable is
that there must be an active route, already in the main routing table of the router, to the prefix in
which the next-hop address is reachable.
Next, for each neighbor, the BGP process applies various standard and implementation-dependent
criteria to decide which routes conceptually should go into the Adj-RIB-In. The neighbor could
send several possible routes to a destination, but the first level of preference is at the neighbor level.
Only one route to each destination will be installed in the conceptual Adj-RIB-In. This process will
also delete, from the Adj-RIB-In, any routes that are withdrawn by the neighbor.
Whenever a conceptual Adj-RIB-In changes, the main BGP process decides if any of the neighbor's
new routes are preferred to routes already in the Loc-RIB. If so, it replaces them. If a given route is
withdrawn by a neighbor, and there is no other route to that destination, the route is removed from
the Loc-RIB, and no longer sent, by BGP, to the main routing table manager. If the router does not
have a route to that destination from any non-BGP source, the withdrawn route will be removed
from the main routing table.

Address Resolution Protocol (ARP)

Address Resolution Protocol (ARP) is a telecommunication protocol used for resolution of network
layer addresses into link layer addresses, a critical function in multiple-access networks. ARP was
defined by RFC 826 in 1982. It is Internet Standard STD 37. It is also the name of the program for
manipulating these addresses in most operating systems.
ARP is used to convert an IP address to a physical address such as an Ethernet address. ARP has
been implemented with many combinations of network and data link layer technologies, such as
IPv4, Chaosnet, DECnet and Xerox PARC Universal Packet (PUP) using IEEE 802 standards,
FDDI, X.25, Frame Relay and Asynchronous Transfer Mode (ATM). IPv4 over IEEE 802.3 and
IEEE 802.11 is the most common case.
In Internet Protocol Version 6 (IPv6) networks, the functionality of ARP is provided by the
Neighbor Discovery Protocol (NDP).

Operating scope
The Address Resolution Protocol is a request and reply protocol that runs encapsulated by the line
protocol. It is communicated within the boundaries of a single network, never routed across
internetwork nodes. This property places ARP into the Link Layer of the Internet Protocol Suite,[2]
while in the Open Systems Interconnection (OSI) model, it is often described as residing between
Layers 2 and 3, being encapsulated by Layer 2 protocols. However, ARP was not developed in the
OSI framework.

Packet structure
The Address Resolution Protocol uses a simple message format that contains one address resolution
request or response. The size of the ARP message depends on the upper layer and lower layer
address sizes, which are given by the type of networking protocol (usually IPv4) in use and the type
of hardware or virtual link layer that the upper layer protocol is running on. The message header
specifies these types, as well as the size of addresses of each. The message header is completed with
the operation code for request (1) and reply (2). The payload of the packet consists of four
addresses, the hardware and protocol address of the sender and receiver hosts.
The principal packet structure of ARP packets is shown in the following table which illustrates the
case of IPv4 networks running on Ethernet. In this scenario, the packet has 48-bit fields for the
sender hardware address (SHA) and target hardware address (THA), and 32-bit fields for the
corresponding sender and target protocol addresses (SPA and TPA). Thus, the ARP packet size in
this case is 28 bytes. The EtherType for ARP is 0x0806.

Example
For example, the computers Matterhorn and Washington are in an office, connected to each other on
the office local area network by Ethernet cables and network switches, with no intervening
gateways or routers. Matterhorn wants to send a packet to Washington. Through DNS, it determines
that Washington's IP address is 192.168.0.55. In order to send the message, it also needs to know
Washington's MAC address. First, Matterhorn uses a cached ARP table to look up 192.168.0.55 for
any existing records of Washington's MAC address (00:eb:24:b2:05:ac). If the MAC address is
found, it sends the IP packet on the link layer to address 00:eb:24:b2:05:ac via the local network
cabling. If the cache did not produce a result for 192.168.0.55, Matterhorn has to send a broadcast
ARP message (destination FF:FF:FF:FF:FF:FF MAC address which is accepted by all computers)
requesting an answer for 192.168.0.55. Washington responds with its MAC address (and its IP).
Washington may insert an entry for Matterhorn into its own ARP table for future use. The response
information is cached in Matterhorn's ARP table and the message can now be sent.

ARP spoofing and Proxy ARP

A successful ARP spoofing attack allows an attacker to perform a man-in-the-middle attack.

Because ARP does not provide methods for authenticating ARP replies on a network, ARP replies
can come from systems other than the one with the required Layer 2 address. An ARP proxy is a
system which answers the ARP request on behalf of another system for which it will forward traffic,
normally as a part of the network's design, such as for a dialup internet service. By contrast, in ARP
spoofing the answering system, or spoofer, replies to a request for another system's address with the
aim of intercepting data bound for that system. A malicious user may use ARP spoofing to perform
a man-in-the-middle or denial-of-service attack on other users on the network. Various software
exists to both detect and perform ARP spoofing attacks, though ARP itself does not provide any
methods of protection from such attacks.