Internet Protocol (IPv4)
Version (4 bits) - IP version (4 or 6)
Header length (4 bits) - Length of header plus any options
Type of Service (TOS) (8 bits) - Used for QoS; can also be evaluated as DiffServ Code Point (DSCP)
Total length (16 bits) - Total packet size
Identifier (16 bits) - Identifies fragments belonging to a single original packet
Fragmentations flags (3 bits) - Three flags: unused, Don't Fragment (DF), and More Fragments (MF)
Fragment offset (13 bits) - Specifies the offset of a fragment from the beginning of the original packet (in units of eight bytes)
Time to Live (TTL) (8 bits) - Tracks hop count
Protocol (8 bits) - Identifies the upper-layer protocol
Header checksum (16 bits) - Used for header error detection
Source address (32 bits)
Destination address (32 bits)
Options (variable length) - Optional attributes generated by the originator
Common IP options:
Loose source routing - A list of IP addresses (router interfaces) the packet should traverse
Strict source routing - A routing path which must be followed exactly
Record route - Routers traversed record the address of their outbound interface on the packet
Timestamp - Like record route but also includes a timestamp
Address Resolution Protocol (ARP)
ARP header:
Hardware type (16 bits) - Identifies the type of layer 2 technology (Ethernet, HDLC, etc.)
Protocol type (16 bits) - Identifies the network-layer protocol
Hardware address length (8 bits) - Length of the data link address in bytes (e.g. MAC =6)
Protocol address length (8 bits) - Length of the network address in bytes (e.g. IP = 4)
Operation (16 bits) - Packet type (request/reply type)
Sender's hardware address
Sender's network address
Target hardware address
Target network address
Cisco routers cache ARP entries for four hours by default (this can be modified with Arp timeout
Proxy ARP
Proxy Arp allows a router to issue ARP replies to one subnet on behalf of a host in another subnet, to
facilitate inter-subnet communication with a host not configured with a default gateway.
The proxy ARP reply will contain the router's own hardware address for that subnet.
Gratuitous ARP
A gratuitous ARP request is one requesting a reply for the sender's own IP address.
Gratuitous ARP can be used to check for duplicate addresses or to announce the existence of a new host.
Reverse ARP (RARP)
Reverse ARP occurs when the sender requests the network address for a given hardware address.
For purposes of initial device addressing, RARP has been superseded by BOOTP and DHCP.
Internet Control Message Protocol (ICMP)
ICMP header:
Type (8 bits)
Code (8 bits)
Checksum (16 bits)
Other fields... (variable)
Common ICMP types:
0 - Echo reply
3 - Destination unreachable
5 - Redirect
6 - Alternate host address
8 - Echo
9 - Router advertisement
10 - Router selection
11 - Time exceeded
12 - Parameter problem
13 - Timestamp
14 - Timestamp reply
30 - Traceroute
Transmission Control Protocol (TCP)
TCP header:
Source port (16 bits)
Destination port (16 bits)
Sequence number (32 bits) - Identifies the position of a segment within a stream
Acknowledgment number (32 bits) - Identifies the sequence number the source next expects to receive
Header length (4 bits)
Reserved (4 bits)
Flags (8 bits)
Window size (16 bits) - Flow control; specifies the amount of data that may be transmitted from the peer between acknowledgments
Checksum (16 bits) - Error detection for the header and payload
Urgent pointer (16 bits) - Points to the end of urgent data; used only when the URG flag is set
Options (variable)
TCP flags:
URG - Urgent data
ACK - Acknowledgment
PSH - Push
RST - Reset
SYN - Synchronize
FIN - Final
User Datagram Protocol (UDP)
UDP header:
Source port (16 bits)
Destination port (16 bits)
Length (16 bits)
Checksum (16 bits)
IPv6 Addressing
IPv6 addresses are presented in 16-bit hexadecimal groups separated by colons. For example,
3ffe:1944:0100:000a:0000:00bc:2500:0d0b.
Shorthand rules:
One group of all-zero segments can be presented with a double-colon (::)
Leading zeros in each segment may be omitted
Subnet identification is performed in CIDR (bit count) notation (/64).
::/0 indicates an all-zeros or wildcard address.
::/128 represents an unspecified address.
Address Types
IPv6 addresses can be one of three types: unicast, anycast, or multicast.
Broadcast functionality is provided by the "all-nodes" multicast address.
Address types are identified by their leading bits:
Binary Hex Type
11111111 FF00::/8 Multicast
11111110 10 FE80::/10 Link-local unicast
11111110 11 FEC0::/10 Site-local unicast (deprecated)
001 2000::/3 Global unicast (currently allocated)
Global Unicast
A global unicast address is broken into three sections:
Global routing prefix (48 bits)
Subnet ID (16 bits)
Interface ID (64 bits)
Local Unicast
Link-local unicasts are unique only to a single layer 2 link.
Site-local unicasts were defined in the original IPv6 standard but have been replaced by Unique Local
Addresses (FC00::/7) in RFC 4193.
Anycast
An anycast address is one address configured on multiple end nodes; dynamic routing will ideally
forward traffic to the "nearest" or least-cost anycast server.
Any global unicast address applied to more than one device can be considered any anycast address.
Multicast
A multicast address identifies a logical group of devices.
Multicast address structure:
Multicast prefix (8 bits) - Always 0xFF
Flags (4 bits)
Scope (4 bits)
Group ID (112 bits)
Address Scopes:
0x0 - Reserved
0x1 - Node-local
0x2 - Link-local
0x5 - Site-local
0x8 - Org-local
0xE - Global
0xF - Reserved
Embedded IPv4 Addresses
Different transition technologies have different ways of embedding an IPv4 address in an IPv6 address.
Some examples for 10.23.1.5 are:
FE80::5EFE:10.23.1.5 (ISATAP)
::FFFF:10.23.1.5 (SIIT)
FEC0:0:0:1::10.23.1.5 (TRT)
2002:0A17:0105::/48 (6to4)
IPv6 Header
IPv6 headers have a fixed 40-byte length.
Header format:
Version (4 bits) - Always set to 6
Traffic class (8 bits) - DiffServ Code Point (DSCP)
Flow label (20 bits) - An arbitrary field for differentiating traffic flows
Payload length (16 bits) - Indicates the length of the payload (header length is not included)
Next header (8 bits) - Identifies the extension header or upper-layer protocol that follows
Hop limit (8 bits) - Decrementing hop counter (TTL)
Source address (128 bits)
Destination address (128 bits)
Extension Headers
Extension headers provide for optional extended capabilities such as hop-by-hop options and IPsec encryption.
Next header values:
0 - Hop-by-hop options
43 - Routing
44 - Fragment
50 - ESP
51 - AH
59 - No next header
60 - Destination options
If a header is the last in the stack, its next header field will identify the upper-layer protocol that follows
(e.g. 6 for TCP or 17 for UDP).
RFC 1883 specifies the order in which extensions headers should appear if they are used.
ICMPv6
IPv6 implements its own version of ICMP, defined in RFC 2463.
Like ICMPv4, ICMPv6 uses type/code pairings to identify field types.
Common field types:
1 - Destination unreachable
2 - Packet too big
3 - Time exceeded
4 - Parameter problem
128 - Echo request
129 - Echo reply
130 - Group membership query
131 - Group membership report
132 - Group membership reduction
Static Routing
A routing table can be populated in three ways:
Subnets gleaned from directly connected networks
Manual configuration (static routes)
Automatically via one or more dynamic routing protocols
A route's next hop must be reachable for the route to take effect.
Configuring Static Routes
IPv4:
Router(config)# ip route [] []
Router(config)# ip route 172.16.0.0 255.255.0.0 192.168.1.1
Router(config)# ip route 10.0.0.0 255.0.0.0 Serial0/0 192.168.2.2
Specifying only an outbound interface rather than a next-hop address assumes that the destination
network is directly connected to that interface.
IPv6:
IPv6 requires the next-hop address to be specified when configuring a route destined out a broadcast
(Ethernet) interface.
Advanced Static Routing
Floating Static Routes
A floating static route is one configured with a higher administrative distance. It will only be used if more preferable routes for a destination fail.
Load Sharing
Multiple static routes can be configured to support equal-cost load sharing.
By default, Cisco Express Forwarding (CEF) performs load balancing per source-destination pair; all packets from one source to one destination will traverse one interface.
CEF also supports per-packet load balancing for IPv4 traffic.
The CEF load-balancing method can be adjusted:
Recursive Lookups
A recursive lookup occurs when a route points to a network not directly connected; one or more subsequent lookups are required to determine the next hop.
Troubleshooting Static Routes
Remember to verify both directions of traffic flow when tracing a path.
When a router or interface hardware is replaced, a new EUI-64 identifier will be used; this may require redefining a static route.
Dynamic Routing Protocols
Distance Vector Routing Protocols
The term distance vector is derived from a list (vector) of distances and directions to destinations.
Distance vector protocols include:
Routing Information Protocol (RIP)
Xerox Networking System (XNS) RIP
Novell IPX RIP
Cisco Interior Gateway Routing Protocol (IGRP)
Cisco Enhanced IGRP (EIGRP)
DEC DNA Phase IV
Appletalk Routing Table Maintenance Protocol (RTMP)
Common distance vector characteristics:
Periodic updates
Reliance on neigbhors to propagate advertisements
Broadcast updates
Full routing table updates (advertising the entire table every time)
The per-hop nature of distance vector advertisements is known as routing by rumor.
Route invalidation timers control how long a route will remain in the routing table without being confirmed by a neighbor.
Split horizon prevents routing loops by preventing the re-advertisement of a route to the neighbor from which it was learned. Router A will not advertise routes learned from router B back to router B.
Poison reverse extends the concept of spit horizon by readvertising a learned route back to the neighbor with an infinite metric. Router A will advertise routes learned from router B back to router B with an infinite metric, ensuring router B knows said routes are not reachable via router A.
Hold down timers place a restriction on how often a route may be updated in the table.
Link State Routing Protocols
Link state routers all share the same complete view of the network.
Link state protocol include:
Open Shortest Path First (OSPF)
ISO Intermediate System to Intermediate System (IS-IS)
DEC DNA Phase V
Novell NetWare Link Services Protocol (NLSP)
Neighbors synchronize their databases upon forming an adjacency. Hello packets are used to form and maintain adjacencies.
Link state protocols converge faster than distance vector protocols because routes can be flooded to neighbors without having to run the routing algorithm.
Sequence numbers are used to identify the revision of an advertisement.
Advertisements are aged and will eventually expire from the database if they are not refreshed periodically.
Networks are commonly divided into link state areas to reduce demand on CPU, memory, and bandwidth required to maintain the database.
Interior and Exterior Gateway Protocols
An autonomous system (AS) is a logical network under a common administration.
Interior Gateway Protocols (IGPs) run within an autonomous system, while Exterior Gateway Protocols
(EGPs) run between autonomous systems.
Routing Information Protocol (RIP)
There are two versions of RIP:
RIPv1 - Classful
RIPv2 (or RIPng) - Classless
RIPv1 is defined in RFC 1058, and operates on UDP port 520.
RIP uses only hop count as its metric, with a maximum of 15 (a metric of 16 indicates unreachability).
Upon initialization, RIP routers issue requests for routes from neighbors. Neighbors issue responses containing their full tables.
Routers broadcast their entire table to the link-local broadcast address of 255.255.255.255 every 30 seconds (on average; a small jitter is included to prevent simultaneous flooding).
Timers
Update (30 seconds) - How often routes are advertised (+/- a small random delay)
Invalid (180 seconds) - How long a received route will stay in the table without being received again, before being marked as invalid.
Flush (240 seconds) - 60 seconds longer than the invalid timer; invalid routes will be flushed from the table when this timer
Holddown (180 seconds) - Routes will be kept in the table for this time before being replaced by an advertisement with a higher metric.
Timer configuration:
Header Format
Command (8 bits) - 1 for requests, 2 for responses
Version (8 bits)
The header is followed by 1-25 route entries, each consisting of an address family identifier (set to 2 for
IP), network address, and metric.
Configuration
Network configuration:
Designating passive interfaces:
Specifying neighbors to which advertisements should be sent as unicasts:
An offset list can be implemented to artificially increase the metric for certain routes:
Triggered extensions (defined in RFC 2091) can be enabled per interface to eliminate periodic updates:
RIPv2, RIPng, and Classless Routing
RIPv2
RIPv2 (defined in RFC 1723) expands on its predecessor to support:
Classless routing
Authentication
Next hop addresses
External route tags
Multicast advertisements (to 224.0.0.9) instead of broadcasts
RIPv2 uses space that was unused in the RIPv1 header to embed a 16-bit route tag in the header, and subnet mask and next hop information in each route entry.
RIPv2 can be run in compatibility mode, broadcasting advertisements to ensure backward compatibility with RIPv1.
Authentication can be implemented by inserting a plaintext password or MD5 hash before the first route entry in every advertisement.
RIPv1 header:
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Command | Version | 0 | |||||||||||||||||||||||||||||
| RIPv1 entry table ::: | |||||||||||||||||||||||||||||||
RIPv2 header:
| 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Command | Version | 0 | |||||||||||||||||||||||||||||
| RIPv2 entry table ::: | |||||||||||||||||||||||||||||||
RIPv1 entry table. Variable length.
An array of RIPv1 entries. Each RIPv1 entry contains the following structure:
RIPv2 entry table. Variable length.
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Address family 0 IPv4 address 0 0 Metric
An array of RIPv2 entries. Each RIPv2 entry contains the following structure:
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Address family Route tag IPv4 address Subnet mask Next hop Metric
Address family. 16 bits.
Route tag. 16 bits.
Cleared to 0 for RIPv1. For RIPv2, this is an attribute assigned to a route which must be preserved and readvertised with a route. The intended use of this tag is to provide a method of separating routes for networks within the RIP routing domain from routes which may have been imported from an EGP or another IGP.
IPv4 address. 32 bits.
Subnet mask. 32 bits.
Cleared to 0 for RIPv1. For RIPv2, this is the subnet mask that can be applied to the IPv4 address to resolve the network portion of the address. If the field is cleared to 0, no subnet mask is specified.
Next hop. 32 bits.
Cleared to 0 for RIPv1. For RIPv2, this is the IP where packets for this entry should be forwarded to.
Metric. 32 bits.
Contains a value from 1 to 15 which specifies the current metric for the destination. A value of 16 indicates that the destination is not reachable.
RIPng
Next-Generation RIP (RIPng) is an entirely new protocol designed for IPv6; it does not support IPv4.
RIPng uses the same timers, procedures, message types, and metric as RIPv2.
A next hop address is included in a single designated route entry, and all entries which follow it are assumed reachable by that address.
Configuring RIPv2
Base configuration:
By default, RIPv2 summarizes on classful boundaries. This can be disabled:
The version of RIP advertisements sent and listened for can be configured per interface:
Key chains can be used to implement authentication per interface:
Configuring RIPng
IPv6 routing is required to support RIPng:
RIPng is enabled per interface rather than in global config:
Details can be modified per RIPng process:
Router(config)# ipv6 router rip
Router(config-router)# port multicast ff02::9
Router(config-router)# distance
RIPng can be configured to artificially increment the metric per interface:
Enabling summarization:
Enhanced Interior Gateway Routing Protocol (EIGRP)
EIGRP is an advanced version of Cisco's proprietary IGRP.
EIGRP runs the Diffusing Update Algorithm (DUAL) instead of Bellman-Ford to attain fast convergence
while remaining loop-free.
Protocol-dependent modules are used to support protocols other than IP (such as IPX and AppleTalk).
Reliable Transport Protocol (RTP) provides ordered delivery of packets between EIGRP neighbors.
EIGRP can consider bandwidth, delay, reliability, and load in calculating a metric; only bandwidth and delay are considered by default.
EIGRP packet types:
Hello - Peer discovery and maintenance
Acknowledgment - Empty hello packets used to acknowledge messages
Update - Convey route information
Query - Request for a route
Reply - Answer to a query
The default hello interval is 5 seconds on a fast link or 60 seconds on a slow (<= T1) link; this can be
adjusted with ip hello-interval eigrp at interface configuration.
Each hello packet includes a hold time (three times the hello interval by deault); this an be adjusted with
ip hold-time eigrp at interface configuration.
DUAL
Of all routes to a destination, the one with the lowest metric will be designated the successor route.
The feasibility condition states that a route's advertised distance must be less than the router's
feasible distance to a destination for it to be considered a feasible successor, to avoid creating a routing loop. Traffic will be load-balanced across multiple paths with the same feasible distance.
DUAL Finite State Machine
Routes remain in the passive state while no DUAL calculations are being performed.
An input event such as an interface state transition or the reception of an update, query, or reply
packet, will cause the router to recalculate the distance for all its feasible successors for the affected
route. If a feasible successor cannot be found, the route enters the active state, and queries for a new path are issued to EIGRP neighbors. If a router does not receive responses from all neighbors to which it issued queries within the active timer (3 minutes by default), the route is considered stuck in active, and unresponsive neighbors are removed from the neighbor table. If all replies are received, the router calculates the feasible distance for all advertised routes, and adds the lowest valid route (if any) as the new successor.
Packet Header
EIGRP is IP protocol 88.
Header format:
Version (8 bits)
Opcode (8 bits) - Packet type (hello, update, etc.)
Checksum (16 bits) - Error detection for the packet
Flags (32 bits)
Sequence (32 bits) - Sequence number used by RTP
ACK (32 bits) - Last sequence number from neighbor
Autonomous System (AS) Number (32 bits)
Type/Length/Value (TLV) triplets follow the header to provide routes and other information.
Configuring EIGRP
Base configuration:
EIGRP will automatically load-balance across up to 16 equal-cost links (4 by default). Unequal-cost
balancing can be enabled by specifying a multiplier by which metrics may differ:
The maximum number of paths used in load balancing can be configured:
To designate a passive interface:
EIGRP summarizes at classful boundaries by default. To disable automatic summarization:
Routers can be configured as stubs to limit the types of routes advertised:
Neighbors do not send queries to stub routers.
Summarization boundaries can be implemented at interfaces:
EIGRP only supports MD5 authentication, which is enabled per interface:
OSPFv2
Open Shortest Path First (OSPF) version 2 is defined in RFC 2328. Link State Advertisements (LSAs) are flooded to all routers within an area, to ensure all routers have a complete database of the network within the area. This database is used by each router to construct an independent shortest path tree.
Adjacencies
Cisco OSPF routers will obtain a router ID from one of three sources, in order:
An administratively configured value (the 1. router-id command)
2. The IP of the highest loopback interface
3. The IP of the highest other interface
Hello packets are used to establish and maintain neighbor relationships.
Network Types
OSPF supports five network types:
Point-to-point - Connects exactly two routers
Broadcast - Multiaccess network with broadcast capability
Nonbroadcast Multiaccess (NBMA) - Multiaccess network without broadcast capability
Pont-to-multipoint - An NBMA treated as a collection of point-to-point links
Virtual link - A virtual connection designed to bridge areas
Designated Routers
A Designated Router (DR) and Backup Designated Router (BDR) are elected on multiaccess links to
limit the number of adjacencies formed.
Each OSPF interface is assigned a priority between 0 and 255 (1 is default).
The DR and BDR are elected based on highest priority, or by highest router ID in the event of a tie.
Once a DR and BDR are elected, they may not be preempted by a new router with a higher priority.
The DR and BDR multicast LSAs to the AllSPFRouters address (224.0.0.5), while all other routers
multicast LSAs to AllDRouters (224.0.0.6).
OSPF Interfaces
Detailed interface characteristics can be viewed with show ip ospf interface.
Interface states:
Down
Point-to-point - Applicable only to point-to-point links
Waiting - DR/BDR election occurring
DR
BDR
DRother
Loopback - Interface is looped (unusable), but still advertised in LSAs
Neighbors
Neighbor states:
Down
Attempt (NBMA only) - Hellos are sent to a neighbor at the hello interval when an interface
transitions to active
Init - A hello has been received from the neighbor but did not list the local router's ID
2-Way - A hello containing the local router's ID was received from the neighbor; bidirectional
communication has been established
ExStart - A master/slave relationship is formed to facilitate exchange of database
descriptions
Exchange - Routers exchange database description packets summarizing the entire
contents of their link state databases
Loading - Routers exchange LSRs and LSUs to obtain new LSAs
Full
LSAs exchanged can be acknowledged one of two ways:
Explicitly - Replying with an LSAck containing the header of the LSA received
Implicitly - Sending an update with the same instance of the LSA received
Flooding
Two OSPF packet types are used to flood LSAs throughout an area:
Link State Update (LSU) - Type 4
Link State Acknowledgment (LSAck) - Type 5
All LSAs are acknowledged to ensure reliable flooding.
Each LSA has a 16-bit sequence number and a 16-bit age (in seconds).
Areas
An OSPF domain is segmented into areas to alleviate the demands of maintaining an entire link state
database.
Area 0 is the backbone; all other areas must connect through it.
There are four non-exclusive router types:
Internal Router - All interfaces belong to a single area
Area Border Router (ABR) - Connects one or more areas to the backbone
Backbone Router - At least one interface is in the backbone area
Autonomous System Boundary Router (ASBR) - Participates in one or more additional routing domains; can be located anywhere in the OSPF domain
A virtual link can be configured to provide a virtual path to the backbone. Virtual links must be
configured between ABRs and cannot traverse a stub area. At least one end of the virtual link must
reside in the backbone area.
Link State Database
All OSPF routers in an area must have the same link state database to construct accurate shortest path
trees. All LSAs are refreshed every LSRefreshTime (default 30 minutes). LSAs older than MaxAge (default 60 minutes) are deleted. The LSRefreshTime is staggered for efficiency so that LSAs are flooded in groups at pseudorandom intervals; this is known as group pacing.
LSA Types
1. Router LSA
2. Network LSA
3. Network Summary LSA
4. ASBR Summary LSA
5. AS External LSA
6. Group Membership LSA (unused)
7. NSSA External LSA
8. External Attributes LSA (unused)
9. Opaque LSA (link-local scope)
10. Opaque LSA (area-local scope)
11. Opaque LSA (AS scope)
Router LSAs (type 1) are produced by all OSPF routers, and identify all of a router's links.
Network LSAs (type 2) are produced by the DR on a multiaccess segment to represent the
pseudonode.
Network Summary LSAs (type 3) are originated by ABRs to advertise destinations from one are to
another.
ASBR Summary LSAs (type 4) are similar to network summary LSAs, but instead advertise the location
of an ASBR.
AS External LSAs (type 5) are originated by an ASBR to represent an external route, and flooded
throughout the OSPF domain.
Group Membership LSAs (type 6) are used by Multicast OSPF (unsupported by Cisco IOS).
NSSA External LSAs (type 7) are essentially AS External LSAs originated by an ASBR in a not-so-stubby
area; type 7 LSAs are only flooded within the area.
External Attributes LSAs (type 8) were proposed as an alternative to iBGP but are not implemented in
Cisco IOS.
Opaque LSAs (types 9 through 11) can provide transport for application-specific information (for
example, to support MPLS traffic engineering).
Area Types
Stub areas do not receive type 4 or 5 LSAs. Instead, ABRs for a stub area advertise a default route out
of the area.
A totally stubby area expands on the stub area concept to also block type 3 LSAs. Routers in a totally
stubby area receive only a default route from ABRs.
A not-so-stubby area (NSSA) is a stub area containing one or more ASBRs. These ASBRs advertise type
7 LSAs representing external routes.
Type 7 LSAs are converted to type 5 LSAs by the ABR if they are to be advertised out of the area.
Route Table
Each OSPF route is one of four types (listed in order of preference):
Intra-area - Within the local area
Inter-area - To another area
External Type 1 (E1) - A route outside the AS which factors external cost plus internal cost
to the ASBR
External Type 2 (E2) - A route outside the AS which only includes external cost
External routes are type 2 by default.
OSPF over Demand Circuits
Periodic LSA refreshes can be disabled for on-demand circuits. This will ensure the link is only brought up during the initial configuration or when it is otherwise needed.
Hellos are not transmitted out interfaces designated as on-demand, except for multiaccess network
types (the hellos are needed to facilitate the DR/BDR election process).
LSAs transmitted over a demand circuit have their DemandCircuit and DoNotAge bits set to 1, disabling
the effect of the MaxAge timer.
Demand interfaces are designated with ip ospf demand-circuit at interface configuration.
Periodic flooding can also be disabled for regular (non-on-demand) circuits with ip ospf flood reduction.
Configuring OSPF
Base configuration:
Router(config)# router ospf
Router(config-router)# network area
OSPF can be configured to perform reverse DNS lookups on router IDs (assuming at least one DNS
server has been configured):
OSPF views secondary addresses as stub networks; the primary address on an interface must
participate in the OSPF process for any of its secondary addresses to be included.
All routers in a stub area must be configured to recognize the area as a stub:
The cost of a default route injected into a stub area by an ABR is 1 by default. This can be adjusted:
The designation of a totally stubby area only has to be made on its ABRs:
All routers in a not-so-(totally)-stubby area (NSSA) must be configured:
Redistribution into an NSSA can be enabled by appending no-redistribute to the area statement.
Inter-area summarization:
Including the not-advertise command prevents routes within the specified range from being
advertised.
Prefix lists can also be used to prevent certain prefixes from being advertised into or out of an area:
Implementing MD5 authentication:
Multiple keys can be configured per interface to enable transitioning passwords without breaking the
adjacency.
Configuring a virtual link through area 123 to router 4.4.4.4:
Virtual link operation can be verified with show ip ospf virtual-link.
Neighbors must be manually configured for NBMA segments:
The default priority for a manually defined neighbor is 0.
Alternatively, NBMA segments can be configured to act as broadcast segments:
A third option is to configure the segment as point-to-multipoint, eliminating the need for a DR:
The addition of the non-broadcast command requires manual neighbor definition.
Enabling demand circuits:
OSPFv3
A successor to OSPFv2 was developed to address some areas of depreciation as well as provide IPv6
support. OSPFv3 is defined in RFC 2740.
Differences From OSPFv2
OSPFv3 is processed per link rather than per subnet, as an IPv6 interface typically has several
addresses.
IP addresses are removed from router and network LSAs.
Neighbors on all link types are always identified by their router ID; never by interface address.
In addition to domain- and area-local, a link-local flooding scope is introduced, supported by a new Link
LSA type.
OSPFv3 supports multiple instances per link by adding an instance ID to packet headers.
OSPF-specific authentication has been removed. Instead, authentication is provided by
IPv6/Authentication Header.
OSPFv3 provides more flexible handling of unknown LSA types, with an option to ignore but flood to
neighbors. This can provide greater ease in implementing future additions to the protocol.
OSPFv3 Messages
OSPFv3 uses the same five message types as OSPFv2:
Hello
Database Description (DD)
Link State Request (LSR)
Link State Update (LSU)
Link State Acknowledgment (LSAck)
OSPFv3 hellos have a larger options field (24 bits vs. 16), a smaller dead interval field (16 bits vs. 32),
and do not include a network mask.
OSPFv3 database description messages also have a larger options field.
The other three message types remain unchanged.
OSPFv3 LSA Types
The OSPFv3 LSA header provides an expanded Link State Type field, of which the first three bits are
flags:
U - Determines whether to ignore or store and flood unknown the LSA if its type is unknown
to the router
S1 and S2 - A two-bit value indicating the scope of the LSA (link-local, area, domain, or
reserved)
LSA types:
0x2001 - Router LSA (v2 Router LSA)
0x2002 - Network LSA (v2 Network LSA)
0x2003 - Inter-area Prefix LSA (v2 Network Summary LSA)
0x2004 - Inter-area Router LSA (v2 ASBR LSA)
0x4005 - AS-External LSA (v2 AS-External LSA)
0x2006 - Group Membership LSA (v2 Group Membership LSA)
0x2007 - Type-7 LSA (v2 NSSA External LSA)
0x0008 - Link LSA
0x2009 - Intra-area prefix LSA
OSPFv3 Router and Network LSAs do not carry address information. Instead, addressing is decoupled
from the SPF tree structure and carried in Intra-Area Prefix LSAs.
OSPFv3 also introduces a Link LSA for advertising information which is only pertinent to directly
connected neighbors.
Configuring OSPFv3
Configuration of OSPFv3 is largely similar to that of OSPFv2, merely substituting the ipv6 command
for ip and using the relevant address formats.
One major difference is that areas and other interface-specific parameters are defined on the interface
for OSPFv3, rather than with the network command under the OSPF process:
All IPv6 addresses configured on an interface are included in OSPFv3.
Because hello packets are sourced from a router's link-local interface address, an adjacency will be
formed even if the neighbor is configured in a different prefix.
Multiple instances of OSPFv3 can be configured per-link to limit adjacencies:
Default Routes and On-Demand Routing
Default routes are beneficial in that they reduce resource utilization, however they sacrifice detail and
granularity to achieve this. On-Demand Routing (ODR) provides the ability to automatically discover stub networks while the stub routers rely only on a default route.
ODR is not a true routing protocol; it relies on Cisco Discovery Protocol (CDP) to discover stub networks, and is consequently limited to one hop. ODR-learned routes have an administrative distance of 160, and their metric is always 1.
Configuration
Configuring static default routes for IPv4 and IPv6:
Static default routes can be redistributed into some routing protocols using redistribute static.
OSPF and IS-IS use the default-information originate command instead.
ODR is enabled with router odr; it has no other parameters.
ODR routes can be redistributed into another protocol with redistribute odr:
Route Filtering
Route feedback occurs when an advertised route is redistributed back into its protocol of origin.
Route filtering is used to control the propagation of routes between routers.
Route filters can be applied inbound to limit the routes received or outbound to control the routes being
advertised.
Configuration
Applying a distribute list to filter inbound routes:
Distribute lists can reference an ACL or a prefix list.
Defining a prefix list:
Applying a distribute list outbound for a link-state routing protocol has no effect, as link-state protocols
like OSPF and IS-IS advertise link-state information, not routes.
Using a distribute list to control routes redistributed to another protocol:
Altering the administrative distance of a routing protocol:
Chapter 14: Route Maps
Route maps provide a greater level of flexibility than access lists for redistribution and policy routing.
Characteristics that can be matched by a redistribution route map include:
Outbound interface
Destination address
Next hop
Route source
Route metric
Route type
Route tag
Properties which can be modified by a redistribution route map:
IS-IS level or OSPF area type
Route metric
Route metric type
Next hop
Tag
Policy routing matches:
ACL match
Packet length
Policy routing sets:
Outbound interface
Next hop
QoS properties
Configuration
Route map configuration:
Router(config)# route-map permit 10
Router(config-map)# match
Router(config-map)# match
Router(config-map)# set
Router(config-map)# set
Router(config-map)# route-map permit 20
...
Configuring policy routing:
To apply policy routing to locally-originated traffic:
Using route maps for redistribution or route tagging:
Introduction to BGP4
Border Gateway Protocol (BGP) was developed to replace Exterior Gateway Protocol (EGP). The current incarnation of the protocol is version four, introduced in RFC 1771. BGP is typically only required for Internet connectivity, and even then often only when peering with multiple service providers. BGP behaves as a distance vector protocol, but uses an AS path instead of a single metric. For this reason, it is referred to as path vector. Load balancing (by default, across a maximum of 6 paths) is only provided by eBGP; iBGP can only use one link.
BGP message types:
Open - Used to form peer relationships
Keepalive - Periodic maintenance of relationships
Update - Communicates routing information
Notification - Communicates an error
BGP neighbor states:
Idle
Connect - A TCP connection is being attempted
Active - A TCP connection has failed; the router is waiting to be contacted by its peer
OpenSent - TCP session established, open message sent
OpenConfirm - Waiting for a keepalive from the peer
Established
Path Attributes
Attribute classes:
Well-known mandatory attributes must be supported and included
Well-known discretionary attributes must be supported but may not be included
Optional transitive attributes don't have to be supported, but must be passed onto peers
Optional nontransitive attributes don't have to be supported, and can be ignored
Attributes:
Origin (WM) - The source of the route (IGP > EGP > unknown)
AS Path (WM) - An ordered list of the ASs the route has traversed
Next Hop (WM) - Specifies the next-hop address for the route
Local Preference (WD) - Communicated between iBGP peers to favor a route out of the
AS
Multi Exit Discriminator (ON) - Advertised to eBGP peers to indicate a preferred entrance
into the local AS
Atomic Aggregate (WD) - Notes that route summarization has been performed
Aggregator (OT) - Identifies the router and AS where summarization was performed
Community (OT) - Provides route tagging capability
Originator ID (ON) - Identifies a route reflector
Cluster List (ON) - Records the route reflector clusters the route has traversed
Administrative weight is a Cisco proprietary attribute, a 16-bit value referenced only by the local router.
An AS Path can be one of two types (as distinguished by its type code):
AS Sequence - An ordered list
AS Set - An unordered list
An AS Set is used to record AS numbers lost when aggregation is performed. The Atomic Aggregate attribute does not have to be included to indicate aggregation has been performed if an AS Set is included.
BGP Operation
Decision Process
Prefer the route with the highest administrative 1. weight
2. If weights are equal, select highest local preference
3. If local preferences are equal, prefer locally originated routes
4. If origins are equal, prefer the shortest AS Path
5. If AS Path lengths are equal, prefer the most favorable origin code (IGP > EGP > incomplete)
If origin codes are equal, prefer lowest MED (only if all candidates routes are advertised from
the same AS)
6.If MEDs are equal, prefer eBGP > eBGP confederation 7. > iBGP
8. If the route types are equal, prefer the route with the lowest IGP metric to its next hop
9. If IGP metrics are equal and are from the same AS, load balance
10. If multipath is not enabled, select the route with the lowest BGP router ID
Route Dampening
Route dampening reduces the effects of flapping routes by preventing their propagation through a network. A route is assigned a penalty when it flaps. This penalty increases with the rate of flapping. The penalty is decreased gradually. The time it takes to decrease by half is its half-life. When the accumulated penalty exceeds the suppress limit, the route is suppressed. The route is put back in use when the penalty drops below the reuse limit. The maximum suppress limit defines a maximum suppress time.
iBGP Synchronization
iBGP peers must be fully meshed, as iBGP-learned routes are not passed to other iBGP peers.
The rule of synchronization requires that an iBGP-learned route must be known by an IGP before it
enters the BGP routing table.
The synchronization requirement can be disabled with no synchronization.
Managing Large-Scale Peering
Peer groups can be defined to simplify assigning characteristics to similar BGP neighbors.
In addition to simplifying configuration, peer groups improve performance by requiring fewer
consultations of the policy database.
Communities can be implemented to apply policies to a group of routes (by appending one or more
Community attributes).
Route reflectors can alleviate the iBGP relationships needed within an AS by purposefully relaying
routes between iBGP peers. A route reflector and its clients is referred to as a cluster.
Route reflectors employ the Originator ID and Cluster List attributes to avoid loops within the AS.
A confederation is an AS which has been divided into sub-autonomous systems (members).
Like regular ASs, confederations use two types of AS Path for loop avoidance:
AS Confed Sequence - An ordered list of member ASNs
AS Confed Set - An unordered list of member ASNs
These confederation-specific attributes are not communicated outside the confederation.
Within a confederation, eBGP routes external to the confederation are preferred over eBGP routes
from another confederation member AS.
Configuring and Troubleshooting BGP
Basic configuration:
The BGP router ID can be taken from one of the following sources, listed in order of preference:
The bgp 1. router-id command
2. The highest IP address of a loopback interface
3. The highest IP address of a physical interface
BGP will summarize to classful boundaries by default. As in other protocols, this is disabled with no
auto-summary. Manually specifying routes to be advertised in BGP:
Enabling redistribution into BGP:
Manually specified routes (by the network command) are marked as originating from an IGP ("i"),
whereas redistributed routes are marked with an incomplete origin ("?").
A BGP router can be configured to advertise a default route to its neighbors:
The synchronization requirement can be disabled, allowing BGP to import internal routes not already
known by an IGP into the routing table: The next hop attribute for routes advertised to iBGP peers can be changed to the advertising router: BGP timers can be adjusted (in seconds):
The source address from which a neighbor relationship is formed can be explicitly set (especially
necessary for sourcing relationships from loopback interfaces):
eBGP multihop must be enabled to increase the default TTL of eBGP packets from the default of 1:
eBGP multihop is required if using loopback interfaces.
Route Aggregation
There are two methods to advertise aggregated routes: static routes and the aggregate-address
command.
Using static routes:
Using an aggregate address:
If the summary-only keyword is included, only the aggregate address is advertised. If it is omitted, the
more-specific routes will be advertised as well as the aggregate.
Alternatively, a number of selected more-specific routes can be suppressed with a suppress map:
An aggregate address can also be assigned an attribute map to modify its attributes (for example, to
set its origin):
By default, no AS Set is included with the aggregate route. To include an AS Set:
When the AS Set is included, the aggregate route inherits all the attributes of its aggregated routes. An
advertise map can be included so that the aggregate only inherits attributes from selected routes:
Managing BGP Connections
A human-friendly description can be added to each BGP neighbor for clarity:
Password authentication can be enabled per neighbor (an MD5 hash is included in BGP packets):
An advertisement interval can be configured per neighbor, to specify the time to wait between sending
advertisements (0 to 600 seconds):
BGP version negotiation can be disabled by statically declaring the version to be used:
A router can be configured to remove consideration of the AS Path length from the BGP decision
process: The number of prefixes received from a neighbor can be limited: The warning threshold percentage defines what percentage of the maximum must be reached before generating a warning message.
The warning-only keyword allows the connection to be maintained even if the peer exceeds the
maximum. The neighbor shutdown command can be used to temporarily disable a peer without deleting its
configuration.
Routing Policies
Distribute lists can be applied to neighbors to restrict the routes advertised or accepted:
Filter lists can be applied to filter routes based on their AS Path:
Route maps can be used to achieve the same functionality as distribute and filter lists, but provide
greater flexibility as well as the option to modify attributes.
Applying a route-map to a neighbor:
An administrative weight (0-65535) can be locally assigned to routes from specific neighbors:
Locally-originated routes receive a weight of 32,768 by default whereas all others have a weight of 0.
Weight can be assigned to only selected routes by implementing a route-map, or by appending the
weight keyword after the filter-list parameter:
External BGP routes have an administrative distance of 20. Internal and local (originated by the local
router with the network command) have a distance of 200.
A backdoor link is a private link between ASs which should be favored over eBGP routes. For this to
work, the administrative distance of the eBGP route must be artificially inflated by inserting the distant
network in the BGP process with the backdoor keyword:
The BGP route to the specified network will be treated as local and will have an administrative distance
of 200, allowing IGP-learned routes to be favored instead.
Local Preference (32-bit, default 100) is communicated among iBGP peers. It can be set with ip
default local-preference or with set local-preference in a route-map.
The MED (or "metric") can be set to influence the path a neighboring AS takes into the local AS.
set metric-type internal can be used in a route-map to set the MED to the IGP's metric for the
route. bgp always-compare-med can be used under the BGP process to force a router to compared the MED
of multiple routes to the same destination even if they originate from different ASs.
It is possible to influence the routing decisions of autonomous systems beyond directly connected
neighbors by artificially lengthening the AS Path of routes. This is done by using set as-path prepend
in a route-map.
Typically the local AS is prepended one or more times. For example, routers AS in 123 might use the
following:
Route tagging is useful for preserving BGP information across redistribution into and out of an IGP.
By default, BGP routes redistributed into an IGP are tagged with their AS Path. This can be extended to
include the origin by using set automatic-tag in a route map.
To automatically set the AS Path from the IGP tag when redistributing back into BGP, use set as-path
tag in a route-map.
Route tags can also be used to preserve BGP communities.
To enable BGP route dampening:
show ip bgp dampened-paths will display suppressed routes. show ip bgp flap-statistics
displays all dampened routes as well as routes with a history of dampening.
clear ip bgp dampening will put suppressed routes back into service. clear ip bgp
flap-statistics will additionally clear all flapping histories.
Large-Scale BGP
Peer group definition example:
Policies applied to individual peer group members take precedence over those applied to the whole
group.
Communities
BGP communities can be set in a route-map with set community . Additionally, each
neighbor or peer group must be configured with send-community for the communities to be included in
advertisements.
Well-known communities:
no-export - Included with a route advertised to eBGP peers to instruct them not to
advertise it beyond the neighbor AS
no-advertise - Sent to iBGP peers to prevent them from propagating the route
local-as - Used to restrict the propagation of a route to within a confederation
Custom communities can be set in decimal format or in AA:NN (ASN:number) format.
Defining a standard community list:
An extended community list:
Community lists can be matched by using match community in a route-map.
Communities can be added to a route without disturbing any communities already present by
appending the additive keyword to the set community statement.
Specific communities matching a community list can be deleted with set comm-list
delete.
Private AS Numbers
The private ASNs are 64512 through 65535. The remove-private-as parameter can be applied to a neighbor to strip all private ASNs from the AS Path of routes received from that neighbor:
Confederations
A confederation is an AS which has been divided into smaller sub-ASs, which typically use private ASNs.
eBGP is run between member ASs. Routers within a confederation must be configured to recognize it as such:
Additionally, routers which peer with other member ASs must be configured to recognize that the peer
AS belongs to the same confederation:
Route Reflectors
A route reflector must be configured to recognize which internal peers it should reflect routes to:
A route reflector will add an Originator ID, identifying the originator of the route, and a Cluster List,
identifying the reflection cluster for loop avoidance. By default, a route reflector enters its router ID in the Cluster List. A cluster ID can be manually specified with bgp cluster-id. This is necessary when there are multiple reflectors in a cluster. If reflector clients are fully meshed, no bgp client-to-client reflection can be used to disable route reflection between clients. Routes from outside the cluster will still be reflected normally.
Network Address Translation
NAT is described in RFC 3022.
There are four types of NAT address:
Inside Local - Inside addresses as seen from the inside
Inside Global - Inside addresses as seen from the outside
Outside Global - Outside addresses as seen from the outside
Outside Local - Outside addresses as seen from the inside
NAT entries can be static or dynamic. The default translation timeout of 86,400 seconds (24 hours) can be changed with ip nat translation timeout.
Port Address Translation (PAT), or NAT overloading, maps multiple internal hosts to a single outside
address using layer 4 port numbers.
NAT/PAT can also be used for load balancing and server virtualization.
NAT Issues:
The TCP or UDP header checksum must be recalculated
Fragments must be tracked
NAT must be able to recognize protocols which embed addresses beyond the IP header
NAT cannot alter IP addresses in encrypted data
Configuring NAT
Designating inside and outside interfaces:
Defining static assignments:
To allow static mappings of one inside local address to multiple inside global addresses, append the
extendable keyword to the statement.
Creating an address pool for dynamic NAT:
Configuring dynamic NAT from private inside addresses to a pool of public addresses:
The type match-host parameter can be appended to the ip nat pool statement so that the host
portion of the address is reserved in the inside-to-outside translation.
NAT mappings can be viewed with show ip nat translations [verbose].
Route maps can be used to determine how packets should be NATted out multiple outside interfaces:
PAT is enabled with the overload keyword:
TCP load balancing pools are created with type rotary:
Router Management
SNMP
Simple Network Management Protocol (SNMP) consists of managers and agents. Managers collect data
provided by agents.
SNMP message types:
Get
Set
Trap
Parameter are defined in a Management Information Base (MIB).
Configuring an SNMP community:
An ACL, if appended, matches hosts which may query the device. ro or rw designates the community
as read-only or read-write, respectively.
Views can be defined to limit access to only parts of the MIB tree:
Configuring a host to receive traps:
To enable or disable specific trap types:
RMON
The Remote Monitoring (RMON) engine on a router polls SNMP MIB variable locally. An SNMP trap is
only sent when a variable crosses its rising or falling threshold.
Configuring an RMON alarm:
Configuring an event to be triggered by an alarm:
Logging
Enabling log timestamps:
Logging levels:
0 - Emergencies
1 - Alerts
2 - Critical
3 - Errors
4 - Warnings
5 - Notifications
6 - Informational
7 - Debugging
Configuring syslog:
No comments:
Post a Comment