Home > Articles > Cisco Network Technology > IP Routing on Cisco IOS, IOS XE, and IOS XR: How a Router Works

IP Routing on Cisco IOS, IOS XE, and IOS XR: How a Router Works

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Jan 2, 2015.

This chapter covers the following topics:

  • IP routing
  • IP packet switching
  • Planes of operation

The previous chapters described that a router is necessary to transmit packets between network segments. This chapter explains the process a router uses to accomplish this task. By the end of this chapter, you should have a good understanding of how a router performs IP routing and IP packet forwarding between different network segments.

IP Routing

A router’s primary function is to move an IP packet from one network to a different network. A router learns about nonattached networks through static configuration or through dynamic IP routing protocols.

Dynamic IP routing protocols distribute network topology information between routers and provide updates without intervention when a topology change in the network occurs. Design requirements or hardware limitations may restrict IP routing to static routes, which do not accommodate topology changes very well, and can burden network engineers depending on the size of the network. Routers try to select the best loop-free path in a network that forwards a packet to its destination IP address.

A network of interconnected routers and related systems managed under a common network administration is known as an autonomous system. The Internet is composed of thousands of autonomous systems spanning the globe.

The common dynamic routing protocols found in networks today are as follows:

  • RIPv2 (Routing Information Protocol Version 2)
  • EIGRP (Enhanced Interior Gateway Routing)
  • OSPF (Open Shortest Path First) Protocol
  • IS-IS (Intermediate System-to-Intermediate System) Protocol
  • BGP (Border Gateway Protocol)

With the exception of BGP, the protocols in the preceding list are designed and optimized for routing within an autonomous system and are known as internal gateway protocols (IGPs). External gateway protocols (EGPs) route between autonomous systems. BGP is an EGP protocol but can also be used within an autonomous system. If BGP exchanges routes within an autonomous system, it is known as an internal BGP (iBGP) session. If it exchanges routes between different autonomous systems, it is known as an external BGP (eBGP) session.

Figure 3-1 shows an illustration of how one or many IGPs as well as iBGP can be running within an autonomous system and how eBGP sessions interconnect the various autonomous systems together.

Figure 3-1

Figure 3-1 Autonomous Systems and How They Interconnect

EGPs and IGPs use different algorithms for path selection and are discussed in the following sections.

Distance Vector Algorithms

Distance vector routing protocols, such as RIP, advertise routes as vectors (distance, vector), where distance is a metric (or cost) such as hop count and vector is the next-hop router’s IP used to reach the destination:

  • Distance: The distance is the route metric to reach the network.
  • Vector: The vector is the interface or direction to reach the network.

When a router receives routing information from a neighbor, it stores it in a local routing database as it is received and the distance vector algorithm (also known as Bellman-Ford and Ford-Fulkerson algorithms) is used to determine which paths are the best loop-free paths to each reachable destination. Once the best paths are determined, they are installed into the routing table and are advertised to each neighbor router.

Routers running distance vector protocols advertise the routing information to their neighbors from their own perspective, modified from the original route that it received. For this reason, distance vector protocols do not have a complete map of the whole network; instead, their database reflects that a neighbor router knows how to reach the destination network and how far the neighbor router is from the destination network. They do not know how many other routers are in the path toward any of those networks. The advantage of distance vector protocols is that they require less CPU and memory and can run on low-end routers.

An analogy commonly used to describe distance vector protocols is that of a road sign at an intersection that indicates the destination is 20 miles to the west; this information is trusted and blindly followed, without really knowing whether there is a shorter or better way to the destination or if the sign is even correct. Figure 3-2 illustrates how a router using a distance vector protocol views the network and the direction that R3 needs to go to reach the 192.168.1.0/24 subnet.

Figure 3-2

Figure 3-2 Distance Vector Protocol View of the Network

Enhanced Distance Vector Algorithm

The Diffused Update Algorithm (DUAL) is an enhanced distance vector algorithm that EIGRP uses to calculate the shortest path to a destination within a network. EIGRP advertises network information to its neighbors as other distance vector protocols do, but it has some enhancements as its name suggests. Some of the enhancements introduced into this algorithm compared to other distance vector algorithms are the following:

  • Rapid convergence time for changes in the network topology.
  • Only sends updates when there is a change in the network. It does not send full routing table updates in a periodic fashion like distance vector protocols.
  • It uses hellos and forms neighbor relationships just like link-state protocols.
  • It uses bandwidth, delay, reliability, load, and maximum transmission unit (MTU) size instead of hop count for path calculations.
  • It has the option to load balance traffic across equal or unequal metric cost paths.

EIGRP is sometimes referred to as a hybrid routing protocol because it has characteristics of both distance vector and link-state protocols, as shown in the preceding list (for example, forming adjacencies with neighbor routers and relying on more advanced metrics such as bandwidth other than hop count for its best path calculations).

Link-State Algorithms

Link-state dynamic IP routing protocols advertise the link state and link metric for each of their connected links and directly connected routers to every router in the network. OSPF and IS-IS are two common link-state routing protocols found in enterprise and service provider networks. OSPF advertisements are called link-state advertisements (LSAs), and IS-IS uses link-state packets (LSPs) for its advertisements.

As a router receives an advertisement from a neighbor, it stores the information in a local database called the link-state database (LSDB), and advertises the link-state information on to each of its neighbor routers exactly as it was received. The link-state information is essentially flooded throughout the network from router to router unchanged, just as the originating router advertised it. This allows all the routers in the network to have a synchronized and identical map of the network.

Using the complete map of the network, every router in the network then runs the Dijskstra shortest path first (SPF) algorithm (developed by Edsger W. Dijkstra) to calculate the best shortest loop-free paths. The link-state algorithm then populates the routing table with this information.

Due to having the complete map of the network, link-state protocols usually require more CPU and memory than distance vector protocols, but they are less prone to routing loops and make better path decisions. In addition, link-state protocols are equipped with extended capabilities such as opaque LSAs for OSPF and TLVs (type/length/value) for IS-IS that allows them to support features commonly used by service providers such as MPLS traffic engineering.

An analogy for link-state protocols is a GPS navigation system. The GPS navigation system has a complete map and can make the best decision as to which way is the shortest and best path to reach the destination. Figure 3-3 illustrates how R3 would view the network to reach the 192.168.1.0/24 subnet.

Figure 3-3

Figure 3-3 Link-State Protocol View of the Network

Path Vector Algorithm

A path vector protocol such as BGP is similar to a distance vector protocol; the difference is that instead of looking at the distance to determine the best loop-free path, it looks at various BGP path attributes. BGP path attributes include autonomous system path (AS_Path), Multi-Exit Discriminator (MED), origin, next hop, local preference, atomic aggregate, and aggregator. BGP path attributes are covered in Chapter 10, “BGP,” and Chapter 14, “Advanced BGP.”

A path vector protocol guarantees loop-free paths by keeping a record of each autonomous system that the routing advertisement traverses. Any time a router receives an advertisement in which it is already part of the autonomous system path, the advertisement is rejected because accepting the autonomous system path would effectively result in a routing loop.

Figure 3-4 illustrates this concept where autonomous system 1 advertises the 10.1.1.0/24 network to autonomous system 2. Autonomous system 2 receives this information and adds itself to the autonomous system path and advertises it to autonomous system 4. Autonomous system 4 adds itself to the path and advertises it to autonomous system 3. Autonomous system 3 receives the route advertisement and adds itself to the path as well. However, when autonomous system 3 advertises that it can reach 10.1.1.0/24 to autonomous system 1, autonomous system 1 discards the advertisement because the autonomous system path (path vector) contained in the advertisement includes its autonomous system number (autonomous system 1). When autonomous system 3 attempts to advertise reachability for 10.1.1.0/24 to autonomous system 2, autonomous system 2 also discards it because the advertisement includes autonomous system 2 in the autonomous system path, too.

Figure 3-4

Figure 3-4 Path Vector Loop Avoidance

All BGP path attributes and how to manipulate them to influence the best path selection process are covered in Chapter 15, “BGP Best Path Selection.”

Routing Table

A router identifies the path a packet should take by evaluating the following components on a router:

  • Prefix length: The prefix length represents the number of leading binary bits in the subnet mask that are in the on position.
  • Administrative distance: Administrative distance (AD) is a rating of the trustworthiness of a routing information source. If a router learns about a route to a destination from more than one routing protocol and they all have the same prefix length, AD is compared. The preference is given to the route with the lower AD.
  • Metrics: A unit of measure used by a routing protocol in the best path calculation.

Prefix Length

Let’s look at a scenario of a router selecting a route when the packet destination is within the network range for multiple routes. Assume that a router has the following routes with various prefix lengths in the routing table:

  • 10.0.3.0/28
  • 10.0.3.0/26
  • 10.0.3.0/24

Because each of these routes, also known as prefix routes or simply prefixes, has a different prefix length (subnet mask), they are considered to be different destinations, and they will all be installed into the routing table. This is represented in Table 3-1.

Table 3-1 Representation of Routing Table

Prefix

Subnet Range

Next Hop

Outgoing Interface

10.0.3.0/28

10.0.3.0 – 10.0.3.15

10.1.1.1

Gigabit Ethernet 1/1

10.0.3.0/26

10.0.3.0 – 10.0.3.63

10.2.2.2

Gigabit Ethernet 2/2

10.0.3.0/24

10.0.3.0 – 10.0.3.255

10.3.3.3

Gigabit Ethernet 3/3

If a packet needs to be forwarded, the route chosen depends on the prefix length, where the longest prefix length is always preferred. For example, /28 is preferred over /26, and /26 is preferred over /24. The following is an example using Table 3-1 as a reference:

  • If a packet needs to be forwarded to 10.0.3.14, it would match all three routes, but it would be sent to next hop 10.1.1.1 and outgoing interface Gigabit Ethernet 1/1 because 10.0.3.0/28 has the longest prefix match.
  • If a packet needs to be forwarded to 10.0.3.42, it would match 10.0.3.0/24 and 10.0.3.0/26, so the packet would be sent to 10.2.2.2 and outgoing interface Gigabit Ethernet 2/2 because 10.0.3.0/26 has the longest prefix match.
  • If a packet needs to be forwarded to 10.0.3.100, it matches only 10.0.3.0/24, so the packet is sent to 10.3.3.3 and outgoing interface Gigabit Ethernet 3/3.

Administrative Distance

As each routing protocol receives updates and other routing information, it chooses the best path to any given destination and attempts to install this path into the routing table. Table 3-2 provides the default AD for the routing protocols covered in this book.

Table 3-2 Routing Protocol Default Administrative Distances

Routing Protocol

Default Administrative Distance

Connected

0

Static

1

eBGP

20

EIGRP summary route

5

EIGRP (internal)

90

OSPF

110

IS-IS

115

RIP

120

EIGRP (external)

170

iBGP

200

For example, if OSPF learns of a best path toward 10.0.1.0/24, it first checks to see whether an entry exists in the routing table. If it does not exist, the route is installed into the Routing Information Base (RIB). If the route already exists in the RIB, the router decides whether to install the route presented by OSPF based on the AD of the route in OSPF and the AD of the existing route in the RIB. If this route has the lowest AD to the destination (when compared to the other route in the table), it is installed in the routing table. If this route is not the route with the best AD, the route is rejected.

Consider another example on this topic. A router has OSPF, IS-IS, and EIGRP running, and all three protocols have learned of the destination 10.3.3.0/24 network with a different best path and metric.

Each of these three protocols will then attempt to install the route to 10.0.3.0/24 into the routing table. Because the prefix length is the same, the next decision point is the AD, where the routing protocol with the lowest AD installs the route into the routing table.

Because the EIGRP internal route has the best AD, it is the one installed into the routing table:

10.0.3.0/24

EIGRP

90 <<< Lowest AD Installed in Route Table

10.0.3.0/24

OSPF

110

10.0.3.0/24

IS-IS

115

The routing protocol or protocols that failed to install their route into the table (in this example, that would be OSPF and IS-IS) will hang on to this route to use it as a backup route and will tell the routing table process to report to them if the best path fails so that they can then try to reinstall this route.

For example, if the EIGRP route 10.0.3.0/24 installed in the routing table fails for some reason, the routing table process calls OSPF and IS-IS, and requests them to reinstall the route in the routing table. Out of these two protocols, the preferred route is chosen based on AD, which would be OSPF because of its lower AD.

The default AD might not always be suitable for a network; for instance, there might be a requirement to adjust it so that OSPF routes are preferred over EIGRP routes. However, changing the AD on routing protocols can have severe consequences, such as routing loops and other odd behavior in a network. It is recommended that the AD be changed only with extreme caution, and only after what needs to be accomplished has been thoroughly thought out. A good backup plan is recommended in case things do not turn out as planned.

Metrics

As discussed in the previous section, routes are chosen and installed into the routing table based on the routing protocol’s AD. The routes learned from the routing protocol with the lowest AD are the ones installed into the routing table. If there are multiple paths to the same destination from a single routing protocol, these paths would have the same AD; for this case, the best path is selected within the routing protocol. Most protocols use the path with the best metric, but OSPF and IS-IS have additional logic that preempts the lowest metric.

If a routing protocol identifies multiple paths as a best path, and supports multiple path entries, the router installs the maximum number of paths allowed per destination. This is known as equal-cost multipath (ECMP) and provides load sharing across all links.

For example, Figure 3-5 illustrates a network running OSPF to reach the prefix 10.3.3.0/24. Router 1 (R1) has two equal-cost paths; therefore, it will install both in the routing table.

Figure 3-5

Figure 3-5 OSPF ECMP Technology

Example 3-1 confirms that both paths have been installed into the RIB, and because the metrics are identical, this confirms the router is using ECMP.

Example 3-1 R1’s Routing Table Showing the ECMP Paths to 10.3.3.0/24

R1#show ip route
! Output omitted for brevity
O     10.3.3.0/24 [110/30] via 10.4.4.4, 00:49:12, GigabitEthernet0/0
                  [110/30] via 10.2.2.2, 00:49:51, GigabitEthernet0/2

Virtual Routing and Forwarding

Virtual Routing and Forwarding (VRF) is a technology that allows multiple independent virtual routing table and forwarding table instances to exist concurrently in a router. This can be leveraged to create segmentation between networks, which allows for overlapping IP addressing to be used even on a single interface (that is, using subinterfaces), and because the traffic paths are isolated, network security is increased and can eliminate the need for encryption and authentication for network traffic.

Service Providers with Multiprotocol Label Switching (MPLS) backbones typically use VRFs to create separate virtual private networks (VPNs) for their customers, and when used in this manner, VRFs are known as VPN Routing and Forwarding.

When VRF is not used in conjunction with MPLS, it is known as VRF-Lite (also termed multi-VRF CE, or multi-VRF customer-edge device). Because MPLS is beyond the scope of this book, only VRF-Lite is covered in this section and is referred to it simply as VRF.

The configurations in Example 3-2 should help clarify the VRF concept. Example 3-2 shows how configuring different interfaces with overlapping IP addresses and subnets is not allowed within a routing table, not even if they are both on different interfaces because they would end up in the same routing table and cause a conflict.

Example 3-2 Overlapping IP Address Problems

IOS
R1(config)#interface GigabitEthernet0/1
R1(config-if)#ip address 10.0.3.1 255.255.255.0
R1(config-if)#interface GigabitEthernet0/3
R1(config-if)#ip address 10.0.3.2 255.255.255.0

% 10.0.3.0 overlaps with GigabitEthernet0/1
IOS XR
RP/0/0/CPU0:XR2(config)#interface gigabitEthernet 0/0/0/5
RP/0/0/CPU0:XR2(config-if)#ipv4 address 10.0.3.1/24
RP/0/0/CPU0:XR2(config-if)#commit
RP/0/0/CPU0:XR2(config-if)#
RP/0/0/CPU0:XR2(config)#interface gigabitEthernet 0/0/0/3
RP/0/0/CPU0:XR2(config-if)#ipv4 address 10.0.3.2/24
RP/0/0/CPU0:XR2(config-if)#commit

RP/0/0/CPU0:Jan 13 18:55:35.643 : ipv4_arm[189]: %IP-IP_ARM-3-CFLCT_FORCED_DOWN :
The IPv4 address 10.0.3.1/24 on GigabitEthernet0/0/0/5 conflicts with other IPv4
addresses and has been forced down

In older IOS releases, only single-protocol IPv4-only VRFs could be created. The command ip vrf vrf-name created a single-protocol VRF on the router and was activated on an interface with the command ip vrf forwarding vrf-name under the interface configuration mode.

In current IOS releases, a new configuration option allows the creation of multiprotocol VRFs that support both IPv4 and IPv6. Entering the command vrf definition vrf-name creates the multiprotocol VRF. Under VRF definition submode, the command address-family {ipv4 | ipv6} is required to specify the appropriate address family. The VRF is then associated to the interface with the command vrf forwarding vrf-name under the interface configuration submode.

In IOS, the following steps are required to create a VRF and assign it to an interface:

  • Step 1. Create a multiprotocol VRF.

    The multiprotocol VRF routing table is created with the command vrf definition vrf-name.

  • Step 2. Identify the address family.

    Initialize the appropriate address family with the command address-family {ipv4 | ipv6}. The address family can be IPv4, IPv6, or both.

  • Step 3. Specify the interface to be associated with the VRF.

    Enter interface configuration submode and specify the interface to be associated with the VRF with the command interface interface-type interface-number.

  • Step 4. Associate the VRF to the interface.

    The VRF is associated to the interface or subinterface by entering the command vrf forwarding vrf-name under interface configuration submode.

  • Step 5. Configure an IP address on the interface or subinterface.

    The IP address can be IPv4, IPv6, or both. It is configured by entering the following commands:

    IPv4
    ip address ip-address subnet-mask [secondary]
    
    IPv6
    ipv6 address {ipv6-address/prefix-length | prefix-name sub-bits/ prefix-length}

IOS XR supports only multiprotocol VRFs. The following steps are required to create a multiprotocol VRF and assign it to an interface on an IOS XR node:

  • Step 1. Create a multiprotocol VRF.

    The multiprotocol VRF routing table is created with the command vrf vrf-name. The VRF name is arbitrary.

  • Step 2. Identify the address family.

    Initialize the appropriate address family with the command address-family {ipv4 | ipv6} unicast. The address family can be IPv4, IPv6, or both.

  • Step 3. Specify the interface to be associated with the VRF.

    Enter interface configuration submode and specify the interface to be associated with the VRF with the command interface interface-type interface-number.

  • Step 4. Associate the VRF with an interface or subinterface.

    The VRF is associated with the interface or subinterface by entering the command vrf vrf-name under interface configuration submode.

  • Step 5. Configure an IP address on the interface or subinterface.

    The IP address can be IPv4, IPv6, or both. It is configured by entering the following commands:

    IPv4
    ipv4 address ipv4-address subnet-mask
    
    IPv6
    ipv6 address ipv6-address/prefix-length

Figure 3-6 Illustrates two routers to help visualize the VRF routing table concept. One of the routers has no VRFs configured, and the other one has a management VRF named MGMT. This figure can be used as a reference for the following examples.

Figure 3-6

Figure 3-6 Comparison of a Router with no VRFs and a Router with a VRF

Table 3-3 provides a set of interfaces and IP addresses that overlap between the global routing table and the VRF. This information is used in the following examples.

Table 3-3 Sample Interfaces and IP Addresses

IOS Interface

IOS XR Interface

IP Address

VRF

Global

Gigabit Ethernet 0/1

Gigabit Ethernet 0/0/0/1

10.0.3.1/24

Gigabit Ethernet 0/2

Gigabit Ethernet 0/0/0/2

10.0.4.1/24

Gigabit Ethernet 0/3

Gigabit Ethernet 0/0/0/3

10.0.3.1/24

MGMT

Gigabit Ethernet 0/4

Gigabit Ethernet 0/0/0/4

10.0.4.1/24

MGMT

Example 3-3 shows how the IP addresses are assigned to the interfaces in the global routing table shown in Table 3-3.

Example 3-3 IP Address Configuration in Global Routing Table

IOS
R1(config)#interface GigabitEthernet0/1
R1(config-if)#ip address 10.0.3.1 255.255.255.0
R1(config)#interface GigabitEthernet0/2
R1(config-if)#ip address 10.0.4.1 255.255.255.0
IOS XR
RP/0/0/CPU0:XR1(config)#interface gigabitEthernet 0/0/0/1
RP/0/0/CPU0:XR1(config-if)#ipv4 address 10.0.3.1/24
RP/0/0/CPU0:XR1(config)#interface gigabitEthernet 0/0/0/2
RP/0/0/CPU0:XR1(config-if)#ipv4 address 10.0.4.1/24
RP/0/0/CPU0:XR1(config-if)#commit

Example 3-4 displays the global routing table with the command show ip route for IOS and show route for IOS XR to show the IP addresses configured in Example 3-3.

Example 3-4 Output of Global Routing Table

IOS
R1#show ip route
! Output omitted for brevity
      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C        10.0.3.0/24 is directly connected, GigabitEthernet0/1
L        10.0.3.1/32 is directly connected, GigabitEthernet0/1
C        10.0.4.0/24 is directly connected, GigabitEthernet0/2
L        10.0.4.1/32 is directly connected, GigabitEthernet0/2
IOS XR
RP/0/0/CPU0:XR1#show route
! Output omitted for brevity

C    10.0.3.0/24 is directly connected, 00:00:25, GigabitEthernet0/0/0/1
L    10.0.3.1/32 is directly connected, 00:00:25, GigabitEthernet0/0/0/1
C    10.0.4.0/24 is directly connected, 00:00:02, GigabitEthernet0/0/0/2
L    10.0.4.1/32 is directly connected, 00:00:02, GigabitEthernet0/0/0/2

Example 3-5 shows how the VRF named MGMT is created, two interfaces are associated with it, and the IP addresses in Table 3-3 are configured on the interfaces. These IP addresses overlap with the ones configured in Example 3-3, but there is no conflict because they are in a different routing table.

Example 3-5 VRF Configuration Example

IOS
R1(config)#vrf definition MGMT
R1(config-vrf)# address-family ipv4
R1(config)#interface GigabitEthernet0/3
R1(config-if)#vrf forwarding MGMT
R1(config-if)#ip address 10.0.3.1 255.255.255.0
R1(config)#interface GigabitEthernet0/4
R1(config-if)#vrf forwarding MGMT
R1(config-if)#ip address 10.0.4.1 255.255.255.0
IOS XR
RP/0/0/CPU0:XR1(config)#vrf MGMT address-family ipv4 unicast
RP/0/0/CPU0:XR1(config-vrf-af)#root
RP/0/0/CPU0:XR1(config)#interface gigabitEthernet 0/0/0/3
RP/0/0/CPU0:XR1(config-if)#vrf MGMT
RP/0/0/CPU0:XR1(config-if)#ipv4 address 10.0.3.1/24
RP/0/0/CPU0:XR1(config)#interface gigabitEthernet 0/0/0/4
RP/0/0/CPU0:XR1(config-if)#vrf MGMT
RP/0/0/CPU0:XR1(config-if)#ipv4 address 10.0.4.1/24
RP/0/0/CPU0:XR1(config-if)#commit

Example 3-6 shows how the VRF IP addresses configured in Example 3-5 cannot be seen in the output of the show ip route command for IOS and the show route command for IOS XR; these commands display only the contents of the global routing table. To see a VRF routing table, the commands show ip route vrf vrf-name for IOS and show route vrf {all | vrf-name} for IOS XR should be used.

Example 3-6 Output of Global Routing Table and VRF Routing Table

R1#show ip route
! Output omitted for brevity
      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C        10.0.3.0/24 is directly connected, GigabitEthernet0/1
L        10.0.3.1/32 is directly connected, GigabitEthernet0/1
C        10.0.4.0/24 is directly connected, GigabitEthernet0/2
L        10.0.4.1/32 is directly connected, GigabitEthernet0/2

R1#show ip route vrf MGMT
! Output omitted for brevity
      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C        10.0.3.0/24 is directly connected, GigabitEthernet0/3
L        10.0.3.1/32 is directly connected, GigabitEthernet0/3
C        10.0.4.0/24 is directly connected, GigabitEthernet0/4
L        10.0.4.1/32 is directly connected, GigabitEthernet0/4
RP/0/0/CPU0:XR1#show route
! Output omitted for brevity
C    10.0.3.0/24 is directly connected, 00:12:44, GigabitEthernet0/0/0/1
L    10.0.3.1/32 is directly connected, 00:12:44, GigabitEthernet0/0/0/1
C    10.0.4.0/24 is directly connected, 00:12:21, GigabitEthernet0/0/0/2
L    10.0.4.1/32 is directly connected, 00:12:21, GigabitEthernet0/0/0/2

RP/0/0/CPU0:XR1#show route vrf MGMT
! Output omitted for brevity
C    10.0.3.0/24 is directly connected, 00:09:15, GigabitEthernet0/0/0/3
L    10.0.3.1/32 is directly connected, 00:09:15, GigabitEthernet0/0/0/3
C    10.0.4.0/24 is directly connected, 00:00:10, GigabitEthernet0/0/0/4
L    10.0.4.1/32 is directly connected, 00:00:10, GigabitEthernet0/0/0/4

In IOS, to display a quick summary of the usability status for each IP interface, in addition to all the IP addresses configured in the global routing table and all VRFs, the command show ip interface brief should be used. In IOS XR, the command show ipv4 interface brief only shows the IP addresses in the global routing table. To see the IP addresses in the global routing table and all VRFs, use the command show ipv4 vrf all interface brief. Example 3-7 provides sample output of these show commands.

Example 3-7 Verification of Interfaces Status and IP Addresses

R1#show ip interface brief

Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/1     10.0.3.1        YES NVRAM  up                    up
GigabitEthernet0/2     10.0.4.1        YES NVRAM  up                    up
GigabitEthernet0/3     10.0.3.1        YES NVRAM  up                    up
GigabitEthernet0/4     10.0.4.1        YES NVRAM  up                    up
RP/0/0/CPU0:XR2#show ipv4 interface brief

Interface                      IP-Address      Status                Protocol
GigabitEthernet0/0/0/0         unassigned      Shutdown              Down
GigabitEthernet0/0/0/1         10.0.3.1        Up                    Up
GigabitEthernet0/0/0/2         10.0.4.1        Up                    Up

RP/0/0/CPU0:XR2#show ipv4 vrf all interface brief

Interface                      IP-Address      Status          Protocol Vrf-Name
GigabitEthernet0/0/0/0       unassigned    Shutdown    Down     default
GigabitEthernet0/0/0/1       10.0.3.1      Up          Up       default
GigabitEthernet0/0/0/2       10.0.4.1      Up          Up       default
GigabitEthernet0/0/0/3       10.0.3.1      Up          Up       MGMT
GigabitEthernet0/0/0/4       10.0.4.1      Up          Up       MGMT

VRF-Lite can provide similar functionality to that of virtual local-area networks (VLANs); however, instead of relying on Layer 2 technologies such as spanning tree, Layer 3 dynamic routing protocols can be used. Using routing protocols over Layer 2 technologies has some advantages such as improved network convergence times, dynamic traffic load sharing, and troubleshooting tools such as ping and traceroute.

2. IP Packet Switching | Next Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.

Overview

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security

Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children

This site is not directed to children under the age of 13.

Marketing

Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out

Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020