Before we get into the layer 3 troubleshooting methods, we first need to make sure we have a basic understanding of how routers and multilayer switches route traffic.  Three tables are used: the routing table, ARP table, and CEF mappings.

The routing table pairs network prefixes with the router’s preferred next hop address or interface.  Packets are routed based on the output of the routing table by first matching the longest prefix and then using other IGP-specific metrics.  The show ip route command displays the contents of the routing table.

After the router has determined what the next-hop address is, the router then needs to translate that into a layer 2 MAC address.  The ARP table is exactly what this is for.  The show ip arp command will display the current ARP pairings.

Lastly, CEF is used in layer 3 switches to optimize routing and layer 2 headers.  To view the CEF entries, use the show ip cef command.

Troubleshooting Any Routing Protocol

Regardless of what routing protocols are in use, there are some common troubleshooting steps that can be applied.  First, try to ping the destination to determine reachability.  Next, look at the routing table to make sure a route to the destination exists.  Finally, run a traceroute from the source towards the destination to see where the last reachable hop is.

For further digging, the show ip protocols command gives some very helpful information on the current routing protocols in use (like timers, AS numbers, etc.).

Routing Protocol Troubleshooting Methodology

There are three key questions that can be extremely helpful when troubleshooting a routing issue – regardless if you are running EIGRP, OSPF, or BGP.
 

1. Is the route being advertised properly?

2. Is the route being received?

3. Is there a more desirable route being used (longer prefix or lower administrative distance)?

 
Now let’s dissect each of these for the major routing protocols one at a time.

EIGRP

First, verify connectivity to the remote networks using pings and by taking a look at the local routing table.

As a reminder, EIGRP stores its information in three different tables: the EIGRP interface table, neighbor table, and topology table.

EIGRP Interface Table

The EIGRP interface table displays interfaces participating in the local EIGRP processes.  Use the show ip eigrp interface command to display its contents.

EIGRP Neighbor Table
The EIGRP neighbor table contains a list of discovered EIGRP neighbors.  Use the show ip eigrp neighbors command to display its contents.

EIGRP Topology Table
The topology table contains a complete list of EIGRP-learned routes. Use the show ip eigrp topology command to display its contents.

Is the EIGRP route being advertised properly?

Remember those three troubleshooting questions listed above?  Let’s start with the first one – is the route being advertised properly?

The first step is to identify the router that is connected to the destination subnet as it should be advertising the route out.  There are two simple ways to check if that router is advertising the routes properly.

First, do a show run | section eigrp.  This will display the running EIGRP configuration, including what networks are being advertised with the network statements.

Another option is to do a show ip protocol.  The nice thing about this command is that it displays the EIGRP network statements.  Remember, EIGRP only advertises subnets of interfaces that match an EIGRP network statement.

Is the EIGRP route being received?

Routers must be EIGRP neighbors for the routing information to be shared.  To check this, issue a show ip eigrp neighbors on the two routers exchanging hellos.  You should see the neighbor listed on each device.

You can also perform a debug ip eigrp packets to make sure hellos are being sent out from each router.

If all of that looks good, look at the EIGRP running configuration and make sure the AS numbers match, the timers are close, and that any authentication configurations are the same.

Next, issue a show ip eigrp interface to make sure the interfaces you expect are participating in the EIGRP process.  Lastly, route maps or distribution lists could be blocking routing traffic.  Do a show ip protocols to display any distribute lists.

Is there a more desirable route being used?

It’s possible that EIGRP knows about the route, but it is not being used in the routing table.  If a more desirable path is known, that will be used instead.   Compare the EIGRP topology table to the local routing table.

OSPF

These steps for troubleshooting OSPF are very similar to EIGRP.  First, verify that there is a problem using pings and by taking a look at the routing table.

OSPF stores its information in three different tables: the OSPF interface table, neighbor table, and link-state database.

OSPF Interface Table
The OSPF interface table displays interfaces participating in the local OSPF processes.  Use the show ip ospf interface command to display its contents.

OSPF Neighbor Table
The neighbor tables contains a list of discovered OSPF neighbors.  Use the show ip ospf neighbors command to display its contents.

OSPF Link State Database
The link state database contains the received LSAs. 

 Use the show ip ospf database command to display its contents.

Is the OSPF route being advertised properly?

The first step is to identify the router that is connected to the destination subnet as it should be advertising the route out.  There are two simple ways to check if that router is advertising the routes properly. 

First, do a show run | section ospf.  This will display the running OSPF configuration, including what networks are being advertised with the network statements.  Another option is to do a show ip protocol. 

Remember, OSPF only advertises subnets of interfaces that match an OSPF network statement.

Is the OSPF route being received?

Routers must be OSPF neighbors for the routing information to be shared.  To check this, issue a show ip ospf neighbors on the two routers.  You should see the neighbor listed on each device.

You can also perform a debug ip ospf adj to show any issues that would prevent the routers from forming an adjacency.

OSPF is more particular about matching protocol variables than EIGRP.  OSPF requires that all of the following parameters match between devices:

• Bidirectional communication
• AS number
• Timers
• Common area type
• Common subnet prefix
• Authentication

The OSPF protocol values can be seen using the show ip ospf interfaces command.

Lastly, route maps or distribution lists could be blocking routing traffic.  Do a show ip protocols to display any distribute lists.

Is there a more desirable route being used?

It’s possible that OSPF knows about the route, but it is not being used in the routing table.  If a more desirable path is known, that will be used instead.   Compare the OSPF topology table to the local routing table.  Take the time to check each hop along the expected  path and look at the routing tables on each router. 

BGP

BGP stores its information in two tables: the BGP neighbor table and the BGP table.

BGP Neighbor Table
The neighbor tables contains a list of known BGP neighbors.  Use the show ip bgp neighbors command to display its contents.

BGP Table
This table contains all the received BGP prefixes as well as their associated attributes lists.  Perhaps most importantly, it also shows the BGP best path to each destination. Use the show ip bgp command to display its contents.

Are the BGP routers neighbors?

BGP neighbors must be administratively assigned on each router running BGP.  If the routers are not neighbors, BGP routing and network information will not be passed between them.  Start by doing a show ip bgp neighbors.  If the expected BGP peers do not show up in the output, make sure they have L3 connectivity using a simple ping test.  If you need to investigate further, a debug ip bgp updates should show the BGP hellos and advertisements.

Remember that BGP requires bidirectional communication as well as matching AS numbers and authentication.  The show run or show ip bgp command will display that information.

Also, consider that route maps or distribution lists could be blocking routing traffic.  Do a show ip protocols to display any distribute lists.

Is the BGP route being advertised?

As with the other routing protocols, make sure that the router connected to the destination subnet is advertising the route out.  There are two simple ways to check if that router is advertising the routes properly. 

Perform a show run | section bgp to look at the neighbor statements.  You should also keep in mind that BGP will only advertise routes when (1) they are defined using neighbor statements and (2) the router knows about the route from another source.

Route Redistribution

Route redistribution can be a tricky situation to troubleshoot, but understanding the following concepts should be helpful.

1. Redistributed routes require an existing entry in the routing table.  If the redistributing router does not have a routing table entry for the route being redistributed, it will not work.  Seems simple, but it should checked right away.

2. Routing loops are a common problem with multi-router routing redistribution.  Use a single router to perform the redistribution if possible.

3. Understand that redistributed routes lose their native metric information.  When redistributing into EIGRP, a default metric MUST be set or no route will be imported.  When redistributing into OSPF, all routes will be imported as classful unless the subnets keyword is appended to the end of the redistribution statement.

Most performance issues on switches are related to one of three errors:

1. Cabling and port problems (layer 1)
2. Duplex mismatches between switch ports and an attached device
3. TCAM issues.

Physical layer Troubleshooting Commands

show interface

show interface counters

show interface counters errors

Look for the following errors:

FCS-Err
Usually a cabling issue.

Xmit-Err
The transmission buffers are full.  This is sometimes seen when switching from a fast link to a slower one.

Undersize, Giants
The transmitting NIC may have problems.

Single-Col, Multi-Col, Late-Col, Excess-Col
All of these are collision types, which can point to a duplex mismatch.  Cisco recommends setting all interfaces, switch and server, to auto.

Spanning Tree

Spanning Tree Protocol is a loop prevention mechanism to allow redundant Ethernet network connections.  Here is an important summary of how each switch determines Spanning Tree port roles:

1.

Each switch periodically transmits BPDUs that include its bridge ID, current root bridge, and cost to that root bridge.  Additionally, each switch starts assuming it is the root bridge.

2.

If a switch receives a BPDU from another switch with a different root, it does a comparison.  If the BPDU has a lower advertised root, the switch changes its root to match and recalculates the cost to the new root.  The port that received the BPDU is now the root port – all others become designated ports.

3.

If a switch receives two BPDUs with the same root, it then compares costs and uses the port with the lowest cost.  The port with the higher cost is blocked – also called a non-designated port.

To quickly review STP costs, below is a list of link costs based on interface speed.

After the whole process, there will be only one root bridge – with each non-root switch having only one root port.

To see the status of spanning tree, do a show spanning-tree vlan vlan-id.

To view sent/received BPDU information for a switch, do a show spanning-tree interface interface detail.

Broadcast Storms

Broadcasts storms can occur due to Spanning Tree misconfigurations and/or rogue switches being added which closes a loop.  Regardless, a broadcast storm will be obvious when the switch slows way down, becoming unresponsive, and all the links light up solid green.

The CLI may be very slow to respond if you still have remote access to it, so often times to fastest way to fix the problem is to physically begin pulling redundant links.

Troubleshooting EtherChannels

EtherChannel issues usually fall into one of three categories:

1. Every port participating in an EtherChannel must have identical speed, duplex, access or trunk settings.  If an EtherChannel isn’t forming, check each port configuration.

2. Both sides of the EtherChannel must be configured as a bundle directly or be using a link aggregation protocol (LACP or PAgP).  If one side is configured as an EtherChannel and the other side is not, look for error-disabled EtherChannel ports on the EtherChannel-enabled switch.

3. If traffic is only flowing over a single link in a bundle, it is likely that the hash algorithm should be adjusted to use different seed values.  Also note that link bundles should be used in even numbered pairs like 2, 4, 8, etc.

VLANs

When troubleshooting issues that you suspect are related to VLAN logic, you should first make sure you have tested for physical layer issues like bad cabling, a power failure, or bad switch ports.  Also, check that you are not dealing with an issue with the switch itself – things like software bugs, loops, or ARP problems.

VLAN issues usually come in the form of misconfigured VLANs, improper VTP mode, trunk issues, and native VLAN mismatches. 

Switch Tables

It is important that you understand what show commands display information on what switch tables.  These will come in handy when you are isolating a switching issue.

Troubleshooting Inter-VLAN Routing

Routing between VLANs can be done on either a router, or a layer 3 switch – but the data plane is different depending on the platform you are using.

Either way, show ip cef displays the CEF forwarding table and show adjacency will show you the layer 2 headers used in forwarding.

Keep in mind that routers always use layer 3 information to pass traffic between ports.  Switches can either use MAC address forwarding (for layer 2 forwarding), SVIs for inter-VLAN routing, or layer 3 routed ports.  The last category, routed ports do not run layer 2 protocols like Spanning Tree – very important.

Last thing to remember – SVIs will only go into down state when all interfaces within that particular VLAN are down.

HSRP, VRRP, & GLBP

First hop redundancy protocols allow a layer 2 segment to have two gateway routers for redundancy, while still only showing a single gateway IP and MAC address.

The three FHRPs Cisco supports are HSRP, VRRP, and GLBP.

HSRP is one of the original FHRPs that was developed by Cisco and is proprietary.  One router is active and another is a backup (using HSRP keepalives to maintain connectivity).  HSRP is extremely popular and you should make sure to understand how it works for the TSHOOT exam.  Check out the High-Availability page to learn more.

VRRP is another gateway redundancy protocol that is an open standard and very similar to HSRP.

GLBP is an open standard; its primary advantage is its ability to automatically load balance between gateway routers.

HSRP

HSRP is the primary FHRP covered on the TSHOOT exam, so let’s go through the basics one more time.

HSRP is configured using the standby command under interface configuration mode.  Routers in the same HSRP group share a common MAC and virtual IP address.  The standby configuration statements define the HSRP group as well as the virtual IP in use.

Each HSRP-enabled router has a default HSRP priority of 100 (remember, highest wins).  If another router joins the group with a higher priority it will still not become the active router unless the preempt command is applied.

An example HSRP configuration could look something like:

Router(config)# interface gig1/1
Router(config-if)# ip address 192.168.1.2
Router(config-if)# standby 4 ip 192.168.1.1
Router(config-if)# standby 4 priority 200
Router(config-if)# standby 4 preempt

To show the current HSRP status, issue either show standby or show standby brief depending on the level of detail you require.

There are a number of methods to tackle the same problem. To be honest, Cisco doesn’t promote a specific approach for the CCNP TSHOOT exam. The important part is that you are consistent and your troubleshooting methodology follows a structured approach.

Structured Troubleshooting

What Cisco calls structured troubleshooting simply means you use a system to solve a problem by collecting information about the problem, forming a hypothesis, and then test it. The structured approach also is helpful when the hypothesis you create fails. It may rule out many more scenarios and likely leads to the next hypothesis to test. The recovery time for a structured troubleshooting approach is usually much less than randomly changing configurations or settings in a hurry to try and get things working.
There are several common structured troubleshooting approaches, with these being the most common:

Bottom-Up

Start with the OSI application layer and work your way down.

Top-Down

Start with the OSI physical layer and work your way up.

Follow-the-Path

Consider the path a packet would take from source to destination, checking each node/device/configuration along the way.

Spot-the-Difference

This is where configurations are compared between what is currently running and what the expected configurations should be.

Move-the-Problem

Move a device to see if the problem moves with it.

Use the Scientific Method

The first step whenever you encounter a technical problem is to define the problem.  This will involve collecting input from those experiencing the issue directly – things like “the Internet is down…” or “my email is slow…” or “I can’t get to my Facebook account when I should be processing TPS reports”…  You get the idea.  Keep in mind that you will need to understand that they are explaining the symptoms – it’s your job to determine the problem behind the symptoms.

After you have identifies the problem, it’s time to trim it down.  What’s the scope?  How many users are affected?  What changed?  When did it happen?  Is it a constant problem or intermittent?

Now this is where your tool bag of structured troubleshooting methodologies should come out.  Try one that you think best matches your hypothesis of the root issue and work your way through it.  Did your test work?  If not, continue through the layers, the path, or whatever approach you are using.

When you find a test that is successful and determine that it in fact is the root cause, make sure to communicate the problem and recovery to all stakeholders and update any necessary documentation.  These are small, simple tasks – but they are rarely done consistently.

If a configuration change was the culprit, think about your current change control policy and ask if it needs to be updated.

Good troubleshooting reduces the time an outage lasts, good maintenance minimizes outages themselves.

Maintenance Methodologies

Several well known maintenance models have been defined by a number of organizations.  Many organizations use parts of several instead of adopting one method completely, but it is important as a network engineer to understand what models exist and how they translate into improving your organization.  A documented maintenance strategy is worth its weight in gold.

IT Infrastructure Library (ITIL)

ITIL focuses on creating a technology service framework within an organization and aligning it closely with the organization’s requirements and processes.  Note that ITIL is a large and comprehensive approach that was developed specifically for IT professionals.

FCAPS

FCAPS is an IT maintenance model created by ISO that categorizes network management into five parts.  FCAPS is an acronym using the first letters of the five categories it includes.

Fault management

■ Preventive maintenance

■ Minimizing network downtime

Configuration management

■ Both hardware and software installation and configuration

■ Change control

■ Inventory management

Accounting management

■ Capacity planning

■ Cost efficiency

Performance management

■ Maximize performance on existing network investments

Security management

■ Confidentiality, integrity, availability (CIA)

■ Authentication, authorization, accounting (AAA)

■ Encryption

■ Intrusion detection/prevention

Cisco Lifecycle Services

Cisco has come up with their own maintenance model, sometimes also referred to as PPDIOO, or Prepare, Plan, Design, Implement, Operate, and Optimize.  This model is specifically focused on deploying and operating Cisco’s product families.

Telecommunications Management Network (TMN)

TMN was developed by ITU-T and is a tailored version of FCAPS specific to the telecommunications industry.

Once the model has been selected, its parts should inform an IT organization’s processes and standard procedures.  After all, a model is meaningless unless it affects how a business operates.

After the maintenance model components have defined an organizational processes (ex. automated config backups, manual security audits, etc.), tools should be selected to carry out those processes.  FTP could be used for configuration backups for example.

Network Maintenance Core Tasks

Whatever model an IT organization chooses, there a some functions that should be included every time.  These include:

■ Managing adds, moves, and changes

■ Installing and configuring new network devices

■ Replacing failed hardware

■ Software backup

■ Configuration backup

■ Troubleshooting failure scenarios

■ Software upgrades

■ Network performance monitoring

■ Capacity planning

■ Creating/updating network documentation

Documentation

Up-to-date, clear, and complete infrastructure documentation is crucial to reduce recovery times and maintain a robust networked environment.  Different levels of detail are appropriate for different audiences, but some common details that should be documented include:

■ Production configurations

■ Inventory (including serial numbers, support info, etc.)

■ Circuit information

■ Network drawings

■ IP address assignments

Another important component to network documentation is a performance baseline, or snapshot.  It captures the expected performance of your network systems like link bandwidth, WAN jitter and delay, and port status.  This is a tremendous help during troubleshooting efforts because without knowing what normal levels are, detecting abnormal traffic behavior becomes very subjective.

IOS Tools

Configuration

Configurations should be backed up periodically or after changes are made.  One of the simplest methods is to save the configuration as a text file on a remote TFTP or FTP server.  TFTP and FTP servers are available on all modern operating systems and free, open source offerings are widely available.

Adding the date to the saved configuration can make rolling back changes easier in the future.  Here’s an example of a router saving it’s configuration to a local TFTP server:

RouterA# copy run tftp
Address of name of remote host []? 10.10.1.35
Destination filename [routera-config]?routera

Syslog

Syslog is a tool that collects alerts from network devices and stores them on a common log.  Obviously, this can be very handy when you need to troubleshoot an issue across many devices.

Know that every syslog message contains two parts, a severity level and a facility.  The severity level goes from 0 to 7 with 0 being the most severe to 7 being simply informational.
Syslog Priority (highest to lowest):
0.  Emergency (highest)
1.  Alert
2.  Critical
3.  Error
4.  Warning
5.  Notice
6.  Informational
7.  Debug (lowest)

NTP

Alerting is important, but if the timestamps that are included are off then the alerts are unreliable (and next to useless).  NTP stands for Network Time Protocol and is used to keep accurate and consistent time on all network devices.  NTP works by using pulling the current time from a time server, each of which are assigned by stratum.  Stratum 1 clocks are synchronized directly with an atomic clock, stratum 2 clocks get their time from stratum 1 clocks, etc.

Configuring NTP is easy – just point the device to the proper time server:

Switch(config)# ntp server ip_address_of_ntp_server

To verify:

Switch# show ntp status

One last note for NTP, it is important to consider the time zone that each device is set to.  Make sure you have it consistent (ex. local time zones, GMT, HQ time zones, etc)

Archive

Cisco has developed a built-in configuration backup and restore feature, called archive.  The archive function maintains a copy of the current configuration as well as a set of past configurations.  If a configuration change is made with unpleasant results, the switch or router can roll back to a previous configuration relatively easily.

There are several keywords available inside archive configuration mode.  Here is a list of some of the most common:

path
Specifies where you want the backup configuration stored (ex. flash, tftp server, etc.)

Example:
archive
path flash://routerc

OR

archive
path tftp://192.168.1.22/routerc.txt

write-memory
When the write-memory keyword is configured, a backup of the configuration will be automatically saved every time the configuration is manually saved.

time-period
Sets the maximum time allowed before another backup is automatically saved

When the archive function backs up a configuration, it appends a -1, -2, -3, etc. to the end of the file name depending on how many have already been saved.  It will count up to 14 (represented as filename-14) and then cycle back to 1.  If your time-period is set too frequently, then you’re backups may be written over too often.

VPN tunnels and IPSec are two topics covered on the exam, but not in great detail.  You’ll need to know enough to verify a sample configuration and answer straightforward questions on both technologies.

Let’s start with IPSec.

IPSec Basics

IPSec allows the establishment of a secure connection between two hosts.  The IPSec protocol sets up a unidirectional SA (security association between the two endpoints).  Because the association is unidirectional, an SA is created on both ends, resulting in two SAs per IPSec tunnel.

IPSec tunnels are often used as a backup to a WAN link failure.  If a point-to-point WAN circuit drops, an IPSec tunnel can be configured to automatically be established over the internet to the remote site.  When the primary WAN circuit comes back up, the IPSec tunnel is disconnected.

Floating Static Routes

Configuring an IPSec tunnel to activate when a primary link drops is commonly inplemented as a floating static route.  The idea is to configure to IPSec VPN as a static route, but with an administrative distance higher than that of the WAN routing protocol’s. 

If the primary route is active, the backup link is not placed into the routing table because its AD is higher.  If the primary route goes down, the static route becomes active.

To configure a floating static route, make sure you define a higher AD value at the end:

R1(conf)# ip route prefix mask address|interface distance_value

VPN Tunnels

One major problem with standard IPSec sessions is that they do not support broadcast or multicast traffic.  If you want to use an IPSec VPN in an “always on” fashion, then the tunnel needs to allow routing information to pass through.  Of course dynamic routing protocols use broadcast or multicast to send hellos and updates, so in lies the dilemma.

To get around this issue, a “tunnel within a tunnel” approach can be used.  A generic tunnel can be configured within the IPSec tunnel to allow routing protocol information (along with all the other traffic).

There are generally four ways to do this paired with IPSec:

DMVPN and GET VPN
Both allow the creation of secure, “on-demand”, multipoint tunnels.

Virtual Tunnel Interface (VTI)
A secure, “always-on” tunnel that supports multicast traffic.  This allows routing protocols to operate within it.

Generic Routing Encapsulation (GRE)
GRE tunnels may be the most common of the bunch – they are also the default tunnel mode on Cisco routers.  GRE tunnels support many layer 3 protocols but perhaps most importantly allow multicast traffic accross the tunnel – granting dynamic routing protocol traffic. 

Be aware that GRE tunnels add an additional 20 byte IP header as well as a 4 byte GRE tunnel header. 

Branch Office Connectivity

The CCNP ROUTE exam covers several unusual topics related to managing and configuring the connectivity between an HQ site and a branch office.  You need to be familiar with some of the underlying technologies used.

Cisco ISR routers are often a good choice for branch sites as they support a wide variety of incoming services.  In smaller offices, a single ISR may be used for a both remote connectivity and inter-VLAN routing.  In that case, know that an Ethernet Switch Module would be required for the ISR router.

DSL

DSL, or Digital Subscriber Line, can be used as a backup WAN connection to a branch office.  DSL uses frequencies not used by TDM phone systems on a phone line – allowing the extra bandwidth to be used for data connectivity.

Asymetrical DSL has higher downstream bandwidth than upstream, while with symetric DSL they are both the same rate.

There are two primary methods for pushing L2 data across a DSL line:

PPoE
Point-to-Point Protocol over Ethernet is the most common method and encapsulates PPP traffic into Ethernet frames.

PPoA
Point-to-Point Protocol over ATM is less common and routes PPP traffic over an ATM network between the customer and the DSL service provider.

Both options can be configured on a Cisco router to terminate the DSL connectivity.  PPoE is especially helpful because it this frees the user computers from running PPoE

Cable

Broadband cable providers also provide internet connectivity which can be used for WAN backup or Internet connectivity for telecommuters.  The internet signal is carried on the same line that the television is carried, but a cable modem allows the data traffic to be seperated.

The international standard for sending data over a cable system is Data Over Cable Service Interface Specification (or DOCSIS).  Many different versions of the standard are used throughout the world.

Cable system connections are typicall not terminated directly into a Cisco router.  Instead, a cable modem demodulates the incoming signal and converts the traffic to Ethernet frames, which a router can process.

Basics

IPv4 addresses are 32 bits long and are represented in dotted-decimal format.  IPv6 addresses are 128 bits and are in hexadecimal format.

The first 64 bits of an IPv6 address are reserved for the network portion and the last 64 bits are used for the host portion.

IPv6 Shorthand

The ability to shorten IPv6 addresses is very important to understand because it makes reading and writing them much easier. 

There are two ways to condense an IPv6 address. 

1.  Leading zeros can be removed in any section.

For example, 
0021:0001:0000:030A:0000:0000:0000:0987E

Can be abbreviated as:
21:1:0:30A:0:0:0:987E

2.  Sequential sections of all zeros can be shortened to a single double colon. 

This can only be used once per address though!  Using the same example address above, it can be further shortened to:

21:1:0:30A::987E

Unicast, Multicast, & Anycast

Unicast
Unicast is for sending traffic to a single interface.  In IPv6 there are actually two different unicasts types, global unicast andlink-local unicast.

Multicast
Unlike IPv4, IPv6 addressing does not support broadcasts.  Instead, it has replaced it with multicast (which is a more efficient variation).  This is used for sending traffic to a group of devices.

Anycast
IPv6 supports another, new packet type – anycast.  Anycast allows the same address to be used on multiple devices for load balancing and redundancy.  Technically, it is used for sending traffic to the nearest interface in a group.  While multiple devices may be running the same anycast address, only one will be used per packet sent.

Be aware that with IPv6, an interface can be assigned multiple addresses.  Here is the list:

- Unicast address

- Link-local address

- loopback (::1/128)

- All nodes multicast (FF00::1)

- Site-local multicast (FF02::2)

- Solicited-nodes multicast

- Default Route (::/0)

Address Assignment

In IPv6, there are three different ways devices are assigned an IP address: manual configuration, using stateless autoconfiguration, or by using DHCPv6.

Manual Address Configuration

The first thing to know and manual IPv6 address configuration is that addresses assigned to a router interface use the address/prefix-length notation instead of the address mask notation.  This is so much easier than typing 25.255… after every ip address!

Also, make sure you first enable IPv6 routing with the ipv6 unicast-routing global configuration command.

Use the ipv6 address ipv6-address/prefix-length command to assign an address.

An example of an interface configured with an IPv6 address:

R1# conf t
R1(config)# ipv6 unicast-routing
R1(config)# int gig 1/1
R1(config-if)# ipv6 address 21:1:0:30A::987E/64

Manual Network Assignment

Another way to manually configure an IPv6 address is to configure the network and allow the host portion to be autopopulated based on the device’s MAC address.  This can work well because MAC addresses are 64 bits long – the exactsame length as the host portion of an IPv6 address!

An example with the network portion defined:

R1(config)# int gig 1/1
R1(config-if)# ipv6 address 21:1:0:30A::/64

Note:  Some systems have a 48 bit MAC address.  In this case, it flips the 7th bit and inserts 0xFFEE into the middle of the MAC address.  This modified version is called an EUI-64 address.  To do this, add the keyword eui-64 to the end of the ipv6 address statement.

Stateless Autoconfiguration

Stateless autoconfiguration allows a device to self-assign an IP address for use locally without any outside information.  Remember that interfaces using IPv6 will often have more than one IPv6 address assigned, and in this case stateless autoconfiguraitonwill generate a link-local address in addition to any other manually assigned addresses.  Link-local addresses are created by starting with the prefix FE80:: and appending the device’s MAC address. Since every MAC address should be unique, it works well for auto-generated local IP addresses.

Link-local addresses are not routable within packets and are used for administrative purposes within the local segment.  For example, most IGPs use link-local addresses to for neighbor relationships and the link-local address is listed as the next-hop address in the routing table.

Once a router has created an IPv6 link-local address using stateless autoconfiguration, it used NDP to make sure it is actually unique within the local network.  NDP stands for Neighbor Discovery Protocol.  NDP uses ICMP packets as part of the neighbor discovery process.

To configure stateless autoconfiguration, use the ipv6 address autoconfig command.

Example:

R1(config)# int gig 1/1
R1(config-if)# ipv6 address autoconfig

IPv6 Routing

Static Routes

The configuration for IPv6 static routes is identical to IPv4, except for the ipv6 route keywords instead of ip route and the addresses will obviously look different.  Other than that, it is exactly the same!

An example of a static IPv6 default route:

R1(config)# ipv6 route ::/0 serial1/1

An example of an IPv6 static route with a next-hop address:

R1(config)# ipv6 route 2003:2:1:A::/64 2003:2:1:F::1

To view the IPv6 routes in the routing table, use the command show ipv6 route.

IPv6 EIGRP

There are many differences in the way EIGRP is configured and withIPv6.  It still sends hellos out every 5 seconds to its neighbors, but when running EIGRP with IPv6 addresses, it uses the multicast address FF02::A.

EIGRP messages are exchanged using the link-local address as the source address and perhaps the biggest difference is that there is no network command!  Instead, EIGRP routing is enabled on each participating interface.

Also, EIGRP running IPv6 requires a router ID be configured.  The format is that of an IPv4 address - 32 digits and it can be a private address (non-routable) with no issues.

The last major change is that the EIGRP process starts in the shutdown state.  You have to issue a no shut to bring it up on the router.

 
To configure IPv6 EIGRP:

R1(config)# ipv6 unicast-routing
!
R1(config)# ipv6 router eigrp AS
R1(config-rtr)# router-id ipv4-address
R1(config-rtr)# no shut
R1(config-rtr)# exit
!
R1(config)# interface type number
R1(config-if)# ipv6 eigrp AS

OSPFv3

OSPFv3 is an updated version of OSPF designed to accommodate IPv6 natively.  Most of the configuration and function is identical to its predeciessor, but a few changes were made – starting with messaging.

OSPFv3 uses the multicast address FF02::5 and FF02::6, but like EIGRP, it now uses its link-local address as the source address in advertisements.  Also, it’s possible to run multiple instances of OSPFv3 on each link.

Like the IPv6 implementation of EIGRP, a 32 bit router ID must be manually created.  It will not automatically create one based on highest loopback or interface address.  The RID that is assigned will then be used to determine the DR and BDR on a segment (highest wins).

OSPFv3 has dropped it’s native authentication options.  Instead, it relies on the underlying authentications built into IPv6, like IPSec.

Configuration

The configuration is now done on each individual interface.  The following is an example configuration:

R2(config)# ipv6 unicast-routing
!
R2(config)# ipv6 router ospf 100
R2(config-rtr)# router-id 10.10.10.1
R2(config-rtr)# area 1 stub no-summary
R2(config-rtr)# exit
!
R2(config)# interface gig1/1
R2(config-if)# ipv6 address 2003:2:1:2::1/64
R2(config-if)# ipv6 ospf 100 area 0
!
R2(config)# interface gig1/2
R2(config-if)# ipv6 address 2003:2:1:A::1/64
R2(config-if)# ipv6 ospf 100 area 1
R2(config-if)# ipv6 ospf priority 30

MP-BGP

MP-BGP, or multiple protocol BGP, was outlined in RFC 2858 and includes extensions to the original BGP standard that allows support for other protocols – one of which is IPv6!  The command address-family was added to specify which new protocol functionality is being configured and is used when applying IPv6 addressing.

Like EIGRP and OSPFv3, an IPv4 address must be configured as a router ID.  The BGP configuration is not done at the interface level, it still is done in router configuration mode.  The major difference is that neighbors must be first defined under router BGP configuration mode and then “activated” under IPv6 address-family mode submode.  Networks and other parameters are also configured under IPv6 address-family mode submode.

Configuration

Like this…

R3(config)# ipv6 unicast-routing
!
R3(config)# router bgp 600
R3(config-rtr)# router-id 10.10.10.10
R3(config-rtr)# neighbor 2003:76:1:1::10 remote-as 700
R3(config-rtr)# address-family ipv6 unicast
R3(config-rtr-af)# neighbor 2003:76:1:1::10 activate
R3(config-rtr-af)# network 2003:2:2::/48
R3(config-rtr-af)# exit
R3(config-rtr)# exit

Migrating to IPv6 

Three options exist for transitioning from IPv4 to IPv6: dual stack, tunneling, or NAT.

Dual Stack
This involves running IPv4 alongside IPv6 on the same system. 

Tunneling
This option allows you to encapsulate IPv6 traffic within an IPv4 header. 

NAT
A new network translation extension, NAT-PT allows IPv6-to4 translation.

Dual Stack

Using a dual-stack transition allows servers, clients, and applications to be slowly moved to IPv6.  Both protocols can run concurrently, neither communicating with the other.  If both IPv4 and IPv6 are running on a server for example, IPv6 will be used.

Configuration Example

R1# config t
R1(config)# ipv6 unicast-routing
R1(config)# ipv6 cef
!
R1(config)# interface serial1/0/1
R1(config-if)# ip address 192.168.1.1
R1(config-if)# ipv6 address 2001:1:3:1::1/64

IPv6 Tunneling

Dual-stacking IPv4 alongside IPv6 on systems works well, but it requires most of your infrastructure to support IPv6.  In many cases, the network core does not support IPv6 or it has not been implemented.  IPv6 tunnels solve this problem by allowing IPv6 islands to exist and bridging them over IPv4 systems.

Because IPv6 tunnels provide virtual IPv6 connectivity through an IPv4 transport, it does not matter what specific IPv4 transport is used.  The only requirement is that there is end-to-end IPv4 connectivity between both ends.

Manual Tunnels

The tunnels discussed here are from one router to another.  The source router (RouterA) encapsulates the IPv6 traffic in IPv4 headers, then forwards it to the other end of the tunnel (Router B).  Router B then decapsulates the packets and forwards them on to their destination using native IPv6.

 Manual IPv6 tunnels are easy to configure using the tunnel mode ipv6ip command.  Using the  Router A/B example above, the configuration on Router A would look something like this:

RouterA(config)# interface tunnel0
RouterA(config-if)# ipv6 address 2001:2:0:7::/64
RouterA(config-if)# tunnel source 10.1.1.1
RouterA(config-if)# tunnel destination 10.3.3.1
RouterA(config-if)# tunnel mode ipv6ip
RouterA(config-if)# exit

GRE Tunnels

First, GRE tunnels are the default tunnel method on Cisco routers.  GGRE tunnels are very flexible and work over most protocols.

The configuration is exactly the same as the manual configuration example above, but you do not have to specify the tunnel mode.  Also, routing protocols can be enabled on GRE tunnel interfaces just as if they were physical interfaces.

6to4 Tunnels

6to4 tunnels are similar to the manual tunnel, but set up the tunnel dynamically.

6to4 tunnels use 2002::/16 IPv6 addresses in front of the 32 bit IPv4 address of the edge router – creating a 48 bit prefix.  Each router on both sides of the tunnel needs a route to its peer.  They only support static and BGP routes, so be careful.

Configure the tunnel as if it was a manual tunnel, using the IPv4 address as the source, but don’t enter a destination.The tunnel requires an IPv6 address using the method just described.  Finally, use the command tunnel mode ipv6ip 6to4.

NAT

Translation is a unique solution because it allows IPv4 devices to communicate with IPv6 devices without the dual stack requirement.  NAT-PT allows bidirectional translation services.

1.  To enable NAT-PT IPv4 to IPv6 translation on a router, the first step is to use the ipv6 nat command on each interface participating in the translation.

2.  The second step is to define at least on NAT-PT prefix.  Only traffic matching the prefix will be translated.  To apply it globally on the router, enter ipv6 nat prefix/prefix_length in global configuration mode.  To apply it to traffic on a specific interface, enter ipv6 nat prefix/prefix_length in interface configuration submode.

3. Define the address mappings (either static or dynamic) using the options discussed below.

Static NAT-PT

For an IPv6 to IPv4 static mapping:

R1(config)# ipv6 nat v6v4 source ipv6_address ipv4_address

For an IPv4 to IPv6 static mapping:

R1(config)# ipv6 nat v4v6 source ipv4_address ipv6_address

Dynamic NAT-PT

There are many ways to implement dynamic NAT using IPv6, but at its most basic level a pool of addresses is created and the router temporarily assigns them to hosts as they need them.

For an IPv4 to IPv6 static mapping:

R1(config)# ipv6 nat v4v6 pool name beginning_ipv6 ending_ipv6 prefix-length prefix-length
R1(config)# ipv6 nat v4v6 source list (access-list_number | name) pool name

For an IPv6 to IPv4 static mapping:

R1(config)# ipv6 nat v6v4 pool name beginning_ipv4 ending_ipv4 prefix-length prefix-length
R1(config)# ipv6 nat v6v4 source list (access-list_number | name) pool name

BGP is recommended whenever multihoming is a requirement (dual ISP connections to different carriers), when route path manipulation is needed, and in transit Autonomous Systems.

A Quick Overview

Routers running BGP are called BGP speakers.

BGP uses autonomous system numbers to keep track of different administrative domains.  1-64511 are public, 64512-65535 are private.

BGP is used to connect IGPs, interior gateway protocols like OSPF and EIGRP.  Routing between Autonomous Systems is referred to as interdomain routing.

The administrative distance for eBGP routes is 20, iBGP is 200.

BGP neighbors are called “peers” and must be statically assigned.

Peers receive incremental, triggered updates as well as keepalives using TCP port 179.

BGP is sometimes referred to as a “path-vector” protocol because its route to a network uses AS numbers on the path
to the destination.

BGP uses it’s path-vector attributes to help in loop prevention.  When an update leaves an AS, the AS number is prepended to update along with all the other AS numbers that have spread the update.  When a BGP router receives an update, it first scans through the list of AS numbers.  If it sees it own AS number, the update is discarded.

BGP Databases

Like most modern routing protocols, BGP has two separate databases – a neighbor database and a BGP-specific database.

Neighbor Database
Lists all of the configured BGP neighbors (to view – #show ip bgp summary).

BGP Database
Lists all networks known by BGP along with their attributes. (to view – #show ip bgp).

BGP Message Types

There are four different BGP message types.

Open
After a BGP neighbor is configured, the router sends an open message to establish peering with the neighbor.

Update
The type of message used to transfer routing information between peers.

Keepalive
BGP peers sends keepalive messages every 60 seconds by default to maintain active neighbor status.

Notification
If a problem occurs and a BGP peer connection must be dropped, a notification message is sent and the session is closed.

Internal vs. External

iBGP, or internal BGP is a peering relationship between BGP routers within the same autonomous system. eBGP, or external BGP describes a peering relationship between BGP routers in different autonomous systems.  It is an important distinction to make.

In the diagram below, R1 and R2 are eBGP peers.  R2 and R3 and iBGP peers.

BGP Next-Hop Self

When you have BGP neighbors peering between autonomous systems like R1 and R2 above, BGP uses the the IP address of the router the update was received from as its “next hop”.  Routers that receive an update from an eBGP neighbor, it must pass the update to its iBGP neighbors with-out modifying the next hop attribute.

The next-hop IP address is the IP address of the edge router belonging to the next-hop autonomous system.

For example, let’s say R1 sends an update to R2 from its 10.1.1.1 serial interface.  R2 must use keep the next-hop IP set as 10.1.1.1 when it passes the update along to R3, its iBGP peer.  The problem is that R2 does not know about 10.1.1.1 and so it cannot use it as its next hop address.

The neighbor [IP address] next-hop-self command solves the problem by advertising itself as the next-hop address.  In this example, it would be applied to R2 so any updates passed along to R3 would use an R2 address as the next-hop.

R2(config)# router bgp 65300
R2(config-router)# neighbor 10.2.2.2 next-hop-self
R2(config)# exit

BGPs Synchronization Rule

The BGP synchronization rule states that a BGP router cannot use or forward new route updates it learns from iBGP peers unless it knows about the network from another source, like an IGP or static route.

The idea is to prevent using or forwarding on information that is unreliable and cannot be verified.  Remember, BGP prefers reliability and stability over using the newest, fastest route.

This means that iBGP peers will not update each other unless and IGP is running under the hood.  To remove the limitation, use the no synchronization command under BGP configuration mode.  recent versions of IOS have it disabled by default, but it is important topic to understand.

Resetting BGP Sessions

Internet routers running BGP have enormous routing tables.  When a filter is applied, like a route map, changes to BGP attributes occur.  Those changes could affect many of the routes already in the routing table from BGP.  Because BGP’s network list is usually very long, applying a route map or prefix list after BGP has converged can be disastrous.  The router would have to check the filter against every possible route and attribute combination. 

To make matters worse, if it were to apply the filters and pull routes back from neighbors, those changes could then cause another reconvergence – and on and on.  In an effort to avoid that scenario (BGP loves stability), BGP will only apply attribute and network changes to routes AFTER the filter has been applied.  All existing routes stay unchanged.

If the network administrator decides that the filter needs to be applied to all routes, then the BGP instance must be reset – forcing the entire BGP table to pass through the filter.  There are three ways to do this:

• Hard reset
• Soft reset
• Route refresh

The hard and soft reset options aren’t discussed here because they are not directly relevant to the exam.  You should know though, that both options are extremely memory-taxing on the router as all the routes must be recomputed.  Route refresh was developed to solve the high memory problems, while still forcing a reset.

The clear ip bgp [ * | neighbor-address] command performs the BGP route refresh.

BGP Configuration

Enabling BGP

Like other routing protocols, BGP must be enabled with the router command.  Make sure to include the AS number.

R1(config)# router bgp autonomous-system-number

BGP Peering

Each neighbor must be statically assigned using the neighbor command.  If the AS number matches the local router’s, it is an iBGP connection.  If the AS number is different, it is an eBGP connection.

R1(config-router)# neighbor ip-address remote-as autonomous-system-number

If a router has a long list of directly connected neighbors, the BGP configuration can start to get long and difficult to follow – especially as neighbor policies are applied.  Peer groups solve that.

Peer groups are groups of peer neighbors that share a common update policy.  Updating an entire group of neighbor statements can then be done with one command.  Much easier for large BGP networks.  Think of a peer group as a logical grouping of routers that are grouped under a single name to make changes faster and configurations shorter.  Like OUs in Active Directory.

Peer groups not only reduce the number of lines of configuration, but they reduce the ease the overhead of the router. A BGP update process normally runs for each neighbor.  If a peer group is configured, a single update process runs for all routers in the group.  Notice that this means that all of the router inside a peer group must be either all iBGP or eBGP neighbors.

Basic neighbor configuration example:

R1(config)# router bgp 65300
R1(config-router)# neighbor 10.1.1.1 remote-as 65300
R1(config-router)# neighbor 10.1.2.1 remote-as 65300
R1(config-router)# neighbor 10.1.3.1 remote-as 65300

Peer group configuration example:

R1(config)# router bgp 65300
R1(config-router)# neighbor MINE peer-group
R1(config-router)# neighbor MINE remote-as 65300
R1(config-router)# neighbor 10.1.1.1 peer-group MINE
R1(config-router)# neighbor 10.1.2.1 peer-group MINE
R1(config-router)# neighbor 10.1.3.1 peer-group MINE

BGP Source Address

R1 in the diagram below has two different options when it comes to peering to R2.  It can peer to the physical interface IP address, 10.1.1.2 or it can peer to R2′s loopback interface, 192.168.2.2.

If a peer relationship is made using the physical interface as the source address, problems can occur if the interface goes down.  In this scenario, even if R2′s 10.1.1.2 interface drops, it still has connectivity to R2′s networks via R3 and R2′s other physical interface.  Even though an IGP would still show R2′s network as accessible, the BGP peer relationship would drop because R1 cannot reach its peering address with R2.

Most implementations recommend using a loopback address as the BGP source address for this reason.  Remember that the loopback address must be added to the IGP running for this to work. This way, if R2′s 10.1.1.2 interface fails, R2 will still be reachable.

The update-source command accomplishes this.  Here’s an example:

R1(config)# router bgp 65400
R1(config-router)# neighbor 192.168.2.2 remote-as 65400
R1(config-router)# neighbor 192.168.2.2 update-source loopback0

R2(config)# router bgp 65400
R2(config-router)# neighbor 192.168.1.1 remote-as 65400
R2(config-router)# neighbor 192.168.1.1 update-source loopback0

Defining Networks

Network statements in BGP are used differently than in other routing protocols like EIGRP or OSPF.  EIGRP and OSPF use the network statements to define which interfaces you want to participate in the routing protocol process.

BGP uses network statements to define which networks the local router should advertise.  Each network doesn’t have to be originating from the local router, but the network must exist in the routing table.  The optional mask keyword is often recommended as BGP supports subnetting and supernetting.

Example:

R1(config)# router bgp 65300
R1(config-router)# neighbor 10.1.1.1 remote-as 65300
R1(config-router)# network 10.1.1.0 255.255.255.0
R1(config-router)# neighbor 10.1.2.1 remote-as 65300
R1(config-router)# network 10.1.2.0 255.255.255.0

Understand that by default a BGP router will not advertise a network learned from one iBGP peer to another.  This is why iBGP is not a good replacement for an IGP like EIGRP and OSPF.

BGP Path Selection

Unlike most other routing protocols, BGP is not hell-bent on using the fastest path to a given destination.  Instead, BGP assigns a long list of attributes to each path.  Each of these attributes can be administratively tuned for extremely granular control of route selections.

BGP also does not load balance across links by default.  To select the best route, BGP uses the criteria in the following order:

1.  Highest weight

2.  Highest local preference

3.  Choose routes originated locally

4.  Path with the shortest AS path

5.  Lowest origin code ( i < e < ? )

6.  Lowest MED

7.  eBGP route over iBGP route

8.  Route with nearest IGP neighbor (lowest IGP metric)

9.  Oldest route

10.  Neighbor with the lowest router ID

11.  Neighbor with the lowest IP address

Controlling Path Selection

The most common method of controlling the attributes listed above is to use route maps.  This allows specific attributes to be changed on specific routes.

Before we get into route maps, let’s first discuss the three prominent attributes, weight, local preference, and MED.

Weight

On Cisco routers, weight is the most influential BGP attribute.  The weight attribute is proprietary to Cisco and is normally used to select an exit interface when multiple paths lead to the same destination.  Weight is local and is not sent to other routers.  It can be a value between 0-65,535.  0 is the default.

In the example below, if you want R2 to prefer to use R1 when sending traffic to 192.168.20.0 then the weight attribute could raised on R2 for R1.

R2(config)# router bgp 65100
R2(config-router)# neighbor 10.1.1.1 remote-as 65100
R2(config-router)# neighbor 10.2.2.1 remote-as 65100
R2(config-router)# neighbor 10.1.1.1 weight 100

Local Preference

Local preference is not proprietary to Cisco and can be used in a similar fashion to weight.  It can be set for the entire router or for a specific prefix.

Local preferences can range from 0-4,294,967,295, with 100 being the default value.  Unlike weight, local preference is propagated to iBGP neighbors.

Using the diagram above, if an administrator wanted R2 to use R1 when sending traffic to 192.168.20.0, the configuration would look something like this:

R1(config)# router bgp 65100
R1(config-router)# bgp default local-preference 500

After the local preference is raised on R1, it will be shared with R2 and R2 will begin using it as its best path to the distant network (assuming the weight is the same of course).

If you want to set the local preference on specif prefixes, route maps are usually the best option.  Below is an example of the local preference being set using a route map:

R7(config)# router bgp 200
R7(config-router)# neighbor 10.10.10.1 remote-as 100
R7(config-router)# neighbor 10.10.10.1 route-map lp_example in
R2(config-router)# exit

R7(config)# access-list 7 permit 10.30.30.0 0.0.0.255
R7(config)# route-map lp_example permit 10
R7(config-rmap)# match ip address 7
R7(config-rmap)# set local-preference 300
R7(config-rmap)# exit

R7(config)# route-map lp_example permit 20
R7(config-rmap)# set local-preference 100

MED

The MED attribute, or multi-exit discriminator is used to influence which path external neighbors use to enter an AS.  MED is also much farther down on the attribute list, so attributes like weight, local preference, AS path length, and origin.  The default MED value is 0 and a lower value is preferred.

A common scenario for MED is when a company has two connections to the same ISP for internet.  Weight or local preference could be used to send outgoing traffic on the higher bandwidth link, but local preference is not shared with routers outside an AS.  MED could be set on one router so ISP routers prefer that path in.

To set the MED on all routes:

R1(config-router)# default-metric value

Here’s an example using a route map to influence incoming paths to 10.30.30.0/24 using MED:

R7(config)# router bgp 200
R7(config-router)# neighbor 10.10.10.1 remote-as 200
R7(config-router)# neighbor 10.10.10.1 route-map med_example out
R2(config-router)# exit

R7(config)# access-list 7 permit 10.30.30.0 0.0.0.255
R7(config)# route-map med_example permit 10
R7(config-rmap)# match ip address 7
R7(config-rmap)# set metric 50
R7(config-rmap)# exit

R7(config)# route-map med_example permit 20
R7(config-rmap)# set metric 150

Verification

It’s important that you understand and are able to interpret to results of the show ip bgp command output.  It displays the contents of the local BGP topology database- including the attributes assigned to each network.  It is perhaps the most important BGP verification and troubleshooting tool!

Because BGP uses many attributes and sources routes in a number of ways, the output of the show ip bgp command can be a nit overwhelming if you don’t know what you are looking for. 

R1# show ip bgp
BGP table version is 21, local router ID is 10.0.22.24
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal
Origin codes: i – IGP, e – EGP, ? – incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.0.0          0.0.0.0                  0         32768 ?
*  10.2.0.0          10.0.22.25              10             0 25 ?
*>                   0.0.0.0                  0         32768 ?
*  10.0.0.0         10.0.22.25               10             0 25 ?
*>                   0.0.0.0                  0         32768 ?
*> 192.168.0.0/16   10.0.22.25               10             0 25 ?

Attributes

Here’s a breakdown of some important fields you should consider remembering:

* - An asterisk in the first column means that the route has a valid next hop.

s (suppressed) – BGP is not advertising the network, usually because it is part of a summarized route.

> - Indicates the best route for a particular destination.  These will end up in the routing table.

i (internal) - If the third column has an i in it, it means the network was learned from an iBGP neighbor.  If it is blank, it means the network was learned from an external source.

0.0.0.0 - The fifth column shows the next hop address for each route.  A 0.0.0.0 indicates the local router originated the route (examples include a network command entered locally or a network an IGP redistributed into BGP on the router)

Metric (MED value) – The column titled Metric represents the configured MED values.  Recall that 0 is the default and if another value exists, lower is preferred.

i/?- The last column displays information on how BGP originally learned the route.  In the example above, ? is used for each route meaning they were all redistributed routes into BGP from an IGP.  The other option is a question mark, which indicates that network commands were used to configure the route.

Redistribution is necessary when routing protocols connect and must pass routes between the two.  This can happen in a number of situations, but some examples include:

• Organizations transitioning routing protocols
• Businesses merge, and so must their networks
• OSPF or EIGRP is used at the access and distribution layer of an enterprise and BGP is used in the core

 The challenge to redistributing routing protocols is that each routing protocol uses it own metric and they are not compatible with each other.  Furthermore, there is no magic algorithm than can automatically translate metrics between, say RP and BGP.

To deal with this dilemma, a new seed metric is used as a staring point when redistribution is configured.

Configuring Redistribution

To configure redistribution between routing protocols, the redistribute protocol command is used under the routing protocol that recieves the routes.

R1(config-router)# redistribute protocol [AS] [metric metric-vlaue]

The process-id field above is the AS number for RIP, EIGRP, BGP.  For OSPF, use the process ID.

Also, both RIP and EIGRP require the use the metric keyword! 

EIGRP Redistribution Example:

R1(config)# router eigrp 10
R1(config-router)# redistribute ospf 20 metric 1000 100 255 1 1500

The example above shows OSPF being redistruted into EIGRP with a metric of 1000 100 255 1 1500.  That is a lot of different numbers for an EIGRP cost!  That’s because EIGRP redistribution metric requires you to input all of the metric calculation manually:

• bandwidth
• delay
• reliability
• loading
• mtu

 You can perform a show interface on the outgoing router interface prior to see what values the router is currently using.

OSPF Redistribution Example:

R1(config)# router ospf 100
R1(config-router)# redistribute eigrp 10 subnets

The example above redistributes EIGRP routes into OSPF.  The subnets keyword at the end of the redistribute command is extremely important!  Without this keyword, OSPF will redistribute networks at their classful boundaries – not something most administrators want. 

If you don’t use it the IOS will even give you a warning.  Make sure to include it. 

Distribute Lists

Distribute lists are access lists applied to the routing process, determining which networks are allowed into the routing table or included in updates.  They essentially act as a filter.

Think:  access list applied to routing = distribute lists

When creating a distribute list, use the following steps:

Step 1.
Identify the network addresses to be filtered and create an ACL – permitting the networks you want to be advertised.

Step 2. 
Determine if you want to filter updates coming into the router or leaving the router.

Step 3.
Assign the ACL using the distribute-list command.

Incoming Distribute Lists:

R1(config-router)# distribute-list {acl-number | name} in [interface-type number] 

Outgoing Distrubute Lists:

R1(config-router)# distribute-list {acl-number | name} out [interface-name | routing-process | AS-number] 

Route Maps

When a routing update arrives at an interface, a series of steps occur to process it correctly.  The diagram below outlines those steps and serves as a foundation for the rest of this route redistribution and filtering section.

Route maps  are extremely flexible and are used in a number routing scenarios including:

• Controlling redistribution based on permit/deny statements
• Defining policies in policy-based routing (PBR)
• Add more mature decision making to NAT decisions than simply using static translations
• When implementing BGP PBR

Route maps allow an administrator to define specific traffic and then take automated actions against it to control how routing information is processed and forwarded.  Route maps uses logic similar to if/then statements in simple scripting.

In route map terms, it matches traffic against conditions and sets options for that traffic. 

NOTE:  If you have downloaded the Switch Exam Guide, you will notice the similarity between the syntax structure of route maps and VACLs.

Each statement in a route map has a sequence number, which are read from lowest to highest.  The router stops reading statements when it reaches its first matching statement. 

Understand that there is an implicit deny included in all route maps.  If traffic does not match any statement, it is denied.

 
Basic Route Map Configuration

 R1(config)# route-map {tag} permit | deny [sequence_number]

That is how all route maps begin.  Permit means that any traffic matching the match statement that follows is processed by the route map.  Deny means that any traffic matching the match statement that follows is NOT processed by the route map.  Know the difference.

Match & Set Conditions

If no match condition exists, the statement matches anything (similar to a ‘permit any’).

If no set condition exists, the statement is simply permitted or denied with no additional changes made.

If multiple match conditions are used on the same line, it is interpreted as a logical OR. In other words, if one condition is true, a match is made.  For example, the router would interpret ‘match a b c’ as ‘a or b or c’.

If multiple match conditions are used on consecutive lines, it is interpreted as a logical AND.  In other words, all conditions must be true before a match is made. For example, the router would interpret the following example as match a and b and c:

route-map EXAMPLE permit 5
match a
match b
match c

Important route redistribution match conditions

ip address
Refers to an access list that permits or denies networks

ip address prefix-list
Refers to a prefix list that permits or denies prefixes

ip next-hop
Refers to an access list that permits or denies ip next hops IP addresses

ip route-source
Refers to an access list that permits or denies advertising router IP addresses

length
Permits or denies packets based on length (in bytes)

metric
Permits or denies routes with specific metrics from being redistributed

route-type
Permits or denies redistribution based on the route type listed

tag
Routes can be labeled with a number that identifies it

Important route redistribution set conditions

metric
Sets the metric for redistributed routes

tag
Tags a route with a numbered identifier

Route Map Verification

Use the show route-map command to verify route maps and PBR entries are filtering as expected.