> Routing
> This appendix provides information on configuring an enhanced, or extended, service. The product administration guides provide examples and procedures for configuring basic services on the system. You should select the configuration example that best meets your service model, and configure the required elements for that model before using the procedures in this appendix.
> This appendix includes the following sections:

> • | Routing Policies

> • | Static Routing

> • | OSPF Routing

> • | OSPFv3 Routing

> • | Viewing Routing Information

> • | Equal Cost Multiple Path (ECMP)

> • | BGP-4 Routing

> • | Bidirectional Forwarding Detection

> Routing Policies
> This section describes how to configure the elements needed to define routing policies. Routing policies modify and redirect routes to and from the system to satisfy specific network deployment requirements.
> Use the following building blocks to configure routing policies:

> • | Route Access Lists – The basic building block of a routing policy. Route access lists filter routes based on a range of IP addresses.

> • | IP Prefix Lists – A more advanced element of a routing policy. An IP Prefix list filters routes based on IP prefixes.

> • | AS Path Access Lists – A basic building block used for Border Gateway Protocol (BGP) routing. These lists filter Autonomous System (AS) paths.

> • | Route Maps – Route-maps provide detailed control over routes during route selection or route advertisement by a routing protocol, and in route redistribution between routing protocols. For this level of control you use IP Prefix Lists, Route Access Lists and AS Path Access Lists to specify IP addresses, address ranges, and Autonomous System paths.

> Creating IP Prefix Lists
> Use the following configuration example to create IP Prefix Lists:
> config
> context <context_name>
> ip prefix-list name <list_name> { deny | permit } <network_address/net_mask>
> Notes:

> • | Set the IP prefix list to deny, permit or match any prefix.

> • | IPv4 dotted-decimal and IPv6 colon-separated addresses are supported.

> • | Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

> Creating Route Access Lists
> Use the following procedure to create a Route Access List:
> config
> context <context_name>
> route-access-list { extended identifier } { deny | permit } [ ip address <ip_address> ]
> route-access-list named <list_name> { deny | permit } { <ip_address/mask> | any } [ exact-match ]
> route-access-list standard <identifier> { permit | deny ) { <ip_address> <wildcard_mask> | any |<network_address> }
> Notes:

> • | A maximum of 64 access lists are supported per context.

> • | Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

> Creating AS Path Access Lists
> Use the following procedure to create an AS Path Access List:
> config
> context <context_name>
> ip as-path access-list <list_name> [ { deny | permit } <reg_expr> ]
> Notes:

> • | Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

> Creating Route Maps
> Use the following configuration example to create a Route Map:
> config
> context <context_name>
> route-map <map_name> { deny | permit } <seq_number>
> Notes:

> • | Use the match and set commands in Route Map Configuration mode to configure the route map. Refer to the Command Line Interface Reference for more information on these commands.

> • | Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

> Sample Configuration
> The example below shows a configuration that creates two route access lists, applies them to a route map, and uses that route map for a BGP router neighbor.
> config
> context isp1
> route-access-list named RACLin1a permit 88.151.1.0/30
> route-access-list named RACLin1a permit 88.151.1.4/30
> route-access-list named RACLany permit any
> route-map RMnet1 deny 100
> match ip address route-access-list RACLin 1 a
> #exit
> route-map RMnet1 deny 200
> match ip address route-access-list RACLin 1 b
> #exit
> route-map RMnet1 permit 1000
> match ip address route-access-list RACLany
> #exit
> router bgp 1
> neighbor 152.20.1.99 as-path 101
> neighbor 152.20.1.99 route-map RMnet1
> Static Routing
> The system supports static network route configuration on a per context basis. Define network routes by specifying the:

> • | IP address and mask for the route

> • | Name of the interface in the current context that the route must use

> • | Next hop IP address

> Adding Static Routes to a Context
> To add static routes to a context configuration, you must know the names of the interfaces that are configured in the current context. Use the show ip interface command to list the interfaces in the current context (Exec mode).
> Information for all interfaces configured in the current context is displayed as shown in the following example.
> [local]<host_name># show ip interface
> Intf Name: Egress 1
> Description:
> IP State: Up (Bound to 24/1 untagged ifIndex 402718721)
> IP Address: 192.168.231.5
> Subnet Mask: 255.255.255.0
> Bcast Address: 192.168.231.255
> MTU: 1500
> Resoln Type: ARP ARP timeout: 3600 secs
> L3 monitor LC-port switchover: Disabled
> Number of Secondary Addresses: 0
> Total interface count: 1
> The first line of information for each interface lists the interface name for the current context as shown in the example output. In this example, there is one interface with the name Egress 1.
> config
> context <context_name>
> ip route { <ip_address> [ <ip_mask> ] | <ip_addr_mask_combo> } { next-hop <next_hop_address> | <egress_name> [ precedence <precedence> [ cost <cost> ]
> Notes:
> You can configure a maximum of 1,200 static routes per context. Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.
> Deleting Static Routes From a Context
> Use the following configuration example to remove static routes from a context’s configuration:
> config
> context context_name
> no ip route { <ip_address> <ip_mask> | <ip_addr_mask_combo> } <next_hop_address> <egress_name> [ precedence <precedence> ] [ cost <cost> ]
> Notes:

> • | Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

> OSPF Routing
> This section gives an overview of Open Shortest Path First (OPSF) routing and its implementation in the system. It also describes how to enable the base OSPF functionality and lists the commands that are available for more complex configurations.
> You must purchase and install a license key before you can use this feature. Contact your Cisco account representative for more information on licenses.
> Important: During system task recovery, it is possible for a dynamically-learned forwarding entry to incorrectly remain in the system forwarding table if that forwarding entry has been removed from the dynamic routing protocol during the recovery.
> OSPF Version 2 Overview
> OSPF is a link-state routing protocol that employs an interior gateway protocol (IGP) to route IP packets using the shortest path first based solely on the destination IP address in the IP packet header. OSPF routed IP packets are not encapsulated in any additional protocol headers as they transit the network.
> An Autonomous System (AS), or Domain, is defined as a group of networks within a common routing infrastructure.
> OSPF is a dynamic routing protocol that quickly detects topological changes in the AS (such as router interface failures) and calculates new loop-free routes after a period of convergence. This period of convergence is short and involves a minimum of routing traffic.
> In a link-state routing protocol, each router maintains a database, referred to as the link-state database, that describes the Autonomous System's topology. Each participating router has an identical database. Each entry in this database is a particular router's local state (for example, the router's usable interfaces and reachable neighbors). The router distributes its local state throughout the AS by flooding.
> All routers run the same algorithm in parallel. From the link-state database, each router constructs a tree of shortest paths with itself as root to each destination in the AS. Externally derived routing information appears on the tree as leaves. The cost of a route is described by a single dimensionless metric.
> OSPF allows sets of networks to be grouped together. Such a grouping is called an area. The topology of this area is hidden from the rest of the AS, which enables a significant reduction in routing traffic. Also, routing within the area is determined only by the area’s own topology, lending the area protection from bad routing data. An area is a generalization of an IP subnetted network.
> OSPF enables the flexible configuration of IP subnets so that each route distributed by OSPF has a destination and mask. Two different subnets of the same IP network number may have different sizes (that is, different masks). This is commonly referred to as variable-length subnetting. A packet is routed to the best (longest or most specific) match. Host routes are considered to be subnets whose masks are “all ones” (0xffffffff).
> OSPF traffic can be authenticated or non-authenticated, or can use no authentication, simple/clear text passwords, or MD5-based passwords. This means that only trusted routers can participate in the AS routing. You can specify a variety of authentication schemes and, in fact, you can configure separate authentication schemes for each IP subnet.
> Externally derived routing data (for example, routes learned from an exterior protocol such as BGP) is advertised throughout the AS. This externally derived data is kept separate from the OSPF ink state data.
> Each external route can also be tagged by the advertising router, enabling the passing of additional information between routers on the boundary of the AS.
> OSPF uses a link-state algorithm to build and calculate the shortest path to all known destinations.
> Basic OSPFv2 Configuration
> This section describes how to implement basic OSPF routing.
> Enabling OSPF Routing For a Specific Context
> Use the following configuration example to enable OSPF Routing for a specific context:
> config
> context <context_name>
> router ospf
> end
> Notes:

> • | Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.

> Enabling OSPF Over a Specific Interface
> After you enable OSPF, specify the networks on which it will run. Use the following command to enable OSPF:
> network network_ip_address/network_mask area { area_id | area_ip_address }
> Important: The default cost for OSPF on the system is 10. To change the cost, refer to the ip ospf cost command in the Ethernet Interface Configuration Commands section of the Command Line Interface Reference.
> Notes:

> • | Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

> Redistributing Routes Into OSPF (Optional)
> Redistributing routes into OSPF means any routes from another protocol that meet specified a specified criterion, such as route type, metric, or rule within a route-map, are redistributed using the OSPFv2 protocol to all OSPF areas. This is an optional configuration.
> config
> context <context_name>
> router ospf
> redistribute { connected | static }
> end
> Notes:

> • | Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

> Confirming OSPF Configuration Parameters
> To confirm the OSPF router configuration, use the following command and look for the section labeled router ospf in the screen output:
> show config context ctxt_name [ verbose ]
> OSPFv3 Routing
> This section gives an overview of Open Shortest Path First Version 3 (OPSFv3) routing and its implementation in the system. It also describes how to enable the base OSPFv3 functionality and lists the commands that are available for more complex configurations.
> OSPFv3 Overview
> Much of OSPF version 3 is the same as OSPF version 2. OSPFv3 expands on OSPF version 2 to provide support for IPv6 routing prefixes and the larger size of IPv6 addresses. OSPFv3 dynamically learns and advertises (redistributes) IPv6 routes within an OSPFv3 routing domain
> In OSPFv3, a routing process does not need to be explicitly created. Enabling OSPFv3 on an interface will cause a routing process and its associated configuration to be created.
> Basic OSPFv3 Configuration
> This section describes how to implement basic OSPF routing.
> Enabling OSPFv3 Routing For a Specific Context
> Use the following configuration example to enable OSPF Routing for a specific context:
> config
> context <context_name>
> router ospfv3
> end
> Notes:

> • | Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.

> Enabling OSPFv6 Over a Specific Interface
> After you enable OSPFv3 specify the area in which it will run. Use the following command to enable OSPFv3:
> area { area_id | area_ip_address } [ default-cost dflt-cost ] [ stub stub-area ] [ virtual-link vl-neighbor-ipv4address ]
> Important: The default cost for OSPFv3 on the system is 10. To change the cost, refer to the ipv6 ospf cost command in the Ethernet Interface Configuration Commands section of the Command Line Interface Reference.
> Notes:

> • | Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

> Redistributing Routes Into OSPFv3 (Optional)
> Redistributing routes into OSPFv3 means any routes from another protocol that meet specified a specified criterion, such as route type, metric, or rule within a route-map, are redistributed using the OSPFv3 protocol to all OSPF areas. This is an optional configuration.
> config
> context <context_name>
> router ospf3
> redistribute { connected | static }
> end
> Notes:

> • | Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

> Confirming OSPFv3 Configuration Parameters
> To confirm the OSPF router configuration, use the following command and look for the section labeled router ipv6 ospf in the screen output:
> show config context ctxt_name [ verbose ]
> Viewing Routing Information
> To view routing information for the current context, run one of the following Exec mode commands;

> • | show ip route: Displays information for all types of routes in the current contexts routing table.

> • | show ip static-route: Displays information only for static routes in the current contexts routing table.

> • | show ip ospf: Displays OSPF process summary information in the current context.

> • | show ipv6 ospf: Displays OSPFv3 process summary information in the current context.

> This example shows sample output of the command, show ip route.
> [local]host_name# show ip route
> "*" indicates the Best or Used route. Destination Nexthop Protocol Prec Cost Interface
> *44.44.44.0/24 208.230.231.50 static 1 0 local1
> *192.168.82.0/24 0.0.0.0 connected 0 0
> *192.168.83.0/24 0.0.0.0 connected 0 0
> 208.230.231.0/24 0.0.0.0 ospf 110 10 local1
> *208.230.231.0/24 0.0.0.0 connected 0 0 local1
> Total route count: 5
> Equal Cost Multiple Path (ECMP)
> The system supports ECMP for routing protocols. ECMP distributes traffic across multiple routes that have the same cost to lessen the burden on any one route.
> config
> context <context_name>
> ip routing maximum-paths [ max_num ]
> Notes:

> • | Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.

> BGP-4 Routing
> The Border Gateway Protocol 4 (BGP-4) routing protocol is supported through a BGP router process that is implemented at the context level.
> The Border Gateway Protocol (BGP) is an inter-AS routing protocol. An Autonomous System (AS) is a set of routers under a single technical administration that use an interior gateway protocol and common metrics to route packets within the AS. The set of routers uses an exterior gateway protocol to route packets to other autonomous systems.
> BGP runs over TCP. This eliminates the need for the BGP protocol to implement explicit update fragmentation, retransmission, acknowledgement, and sequencing information. Any authentication scheme used by TCP may be used in addition to BGP’s own authentication mechanisms.
> BGP routers exchange network reachability information with other BGP routers. This information builds a picture of AS connectivity from which routes are filtered and AS-level policy decisions are enforced.
> BGP-4 provides classless inter-domain routing. This includes support for advertising an IP prefix and eliminates the concept of network class within BGP. BGP-4 also allows the aggregation of routes, including the aggregation of AS paths.
> Overview of BGP Support
> Mobile devices communicate to the Internet through Home Agents (HAs). HAs assign IP addresses to the mobile node from a configured pool of addresses. These addresses are also advertised to Internet routers through an IP routing protocol to ensure dynamic routing. The BGP-4 protocol is used as a monitoring mechanism between an HA and Internet router with routing to support Interchassis Session Recovery (ICSR). (Refer to the Interchassis Session Recovery appendix in this guide for more information.)
> The objective of BGP-4 protocol support is to satisfy routing requirements and monitor communications with Internet routers. BGP-4 may trigger an active to standby switchover to keep subscriber services from being interrupted.
> The following BGP-4 features are supported:

> • | Exterior Border Gateway Protocol (EBGP) multi-hop

> • | Route Filtering for inbound and outbound routes

> • | Route redistribution and route-maps

> IP pool routes and loopback routes are advertised in the BGP domain in the following ways:

> • | Through BGP Configuration Mode redistribution commands, all or some of the connected routes are redistributed into the BGP domain. (IP pool and loopback routes are present in the IP routing table as connected routes.) The network routemap command provides the flexibility to change many BGP attributes.

> • | Through the BGP Configuration Mode network commands, connected routes are explicitly configured for advertisement into the BGP domain. The network routemap command provides the flexibility to change many BGP attributes. Refer to the Border Gateway Protocol Configuration Mode Commands section of the Command Line Interface Reference for details on these commands.

> Important: If a BGP task restarts because of a processing card failure, a migration, a crash, or the removal of a processing card, all peering session and route information is lost.
> Configuring BGP
> This section describes how to configure and enable basic BGP routing support in the system.
> config
> context <context_name>
> router bgp <AS_number>
> neighbor <ip_address> remote-as <AS_num>
> Notes:

> • | A maximum of 64 BGP peers are supported per context.

> • | Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

> Redistributing Routes Into BGP (Optional)
> Redistributing routes into BGP simply means that any routes from another protocol that meet a specified criterion, such as a route type, or a rule within a route-map, are redistributed through the BGP protocol to all BGP areas. This is an optional configuration.
> config
> context <context_name>
> router bgp <as_number>
> redistribute bgp { bgp | connected | static } [ metric <metric_value> ] [ metric-type { 1 | 2 } ] [ route-map <route_map_name> ]
> Notes:

> • | The redistribution options are connected, ospf, rip, or static. Refer to the Border Gateway Protocol Configuration Mode Commands section of the Command Line Interface Reference for details on the redistribute command.

> • | A maximum of 64 route-maps are supported per context.

> • | Save your configuration as described in Verifying and Saving Your Configuration chapter of this guide.

> Bidirectional Forwarding Detection
> Bidirectional Forwarding Detection (BFD) is a network protocol used to detect faults between two forwarding engines connected by a link. BFD establishes a session between two endpoints over a particular link. If more than one link exists between two systems, multiple BFD sessions may be established to monitor each one of them. The session is established with a three-way handshake, and is torn down the same way. Authentication may be enabled on the session. A choice of simple password, MD5 or SHA1 authentication is available.
> Overview of BFD Support
> BFD does not have a discovery mechanism; sessions must be explicitly configured between endpoints. BFD may be used on many different underlying transport mechanisms and layers, and operates independently of all of these. Therefore, it needs to be encapsulated by whatever transport it uses.
> In asynchronous mode, both endpoints periodically send Hello packets to each other. If a number of those packets are not received, the session is considered down.
> When Echo is active, a stream of Echo packets is sent to the other endpoint which then forwards these back to the sender. Echo can be globally enabled via the bfd-protocol command, and/or individually enabled/disabled per interface. This function is used to test the forwarding path on the remote system.
> The ASR 5000 supports BFD in asynchronous mode with optional Echo capability via static or BGP routing.
> Configuring BFD
> This section describes how to configure and enable basic BFD routing protocol support in the system.
> There are several factors affecting the configuration of BFD protocol:

> • | Configuring a BFD Context

> • | Configuring IPv4 BFD for Static Routes

> • | Configuring BFD for BGP Single Hop

> • | Configuring Multihop BFD for BGP

> • | Scaling of BFD

> Configuring a BFD Context
> config
> context <context_name>
> bfd-protocol
> [ [no] bfd echo ]
> exit
> Notes:

> • | Echo function can be optionally enabled for all interfaces in this context.

> • | 16 BFD sessions per context and 64 per chassis.

> Configuring IPv4 BFD for Static Routes
> Enable BFD on an interface.
> config
> context <bfd_context_name>
> interface <if_name>
> ip address <ipv4_address> <ipv4_mask>
> bfd interval <interval_value> min_rx <rx_value> multiplier <multiplier_value>
> [ [no] bfd echo ]
> exit
> Configure BFD static route.
> ip route static bfd <if_name> <ipv4_gw_address>
> Add static routes.
> ip route <ipv4_address> <ipv4_mask>
> ip route <ipv4_address> <ipv4_mask>
> Configuring BFD for BGP Single Hop
> Enable BFD on an interface.
> config
> context <bfd_context_name>
> interface <if_name>
> ip address <ipv4_address> <ipv4_mask>
> bfd interval <interval_value> min_rx <rx_value> multiplier <multiplier_value>
> [ [no] bfd echo ]
> exit
> Enable BFD on a BGP Neighbor. See Associate BGP Neighbors with the Context for additional information.
> router bgp <AS_number>
> neighbor <neighbor_ip-address> failover bfd
> Configuring Multihop BFD for BGP
> Enable BFD on an interface.
> config
> context <bfd_context_name>
> interface <if_name>
> ip address <ipv4_address> <ipv4_mask>
> bfd interval <interval_value> min_rx <rx_value> multiplier <multiplier_value>
> [ [no] bfd echo ]
> exit
> Configure a Multihop BFD session.
> bfd-protocol
> bfd multihop peer <destination-address> interval <interval-value> multiplier <multiplier-value>
> Enable BFD on a BGP Neighbor. See Associate BGP Neighbors with the Context for additional information.
> neighbor <neighbor_ip-address> failover bfd multihop
> Scaling of BFD
> Configure an active BFD session using one of the above methods and use same BFD neighbor while configuring the active interface. See Associate BFD Neighbor Groups with the BFD Protocol for additional information.
> bfd-protocol
> bfd nbr-group-name <grp_name> active-if-name <if_name> <nexthop_address>
> Apply the same BFD results to one or more passive interfaces.
> bfd nbr-group-name <grp_name> passive-if-name <if_name> <nexthop_address>
> bfd nbr-group-name <grp_name> passive-if-name <if_name> <nexthop_address>
> Associate BGP Neighbors with the Context
> config
> context <context_name>
> router bgp <AS_number>
> neighbor <neighbor_ip-address> remote-as <rem_AS_number>
> neighbor <neighbor_ip-address> ebgp-multihop max-hop <max_hops>
> neighbor <neighbor_ip-address> update-source <update-src_ip-address>
> neighbor <neighbor_ip-address> failover bfd [ multihop ]
> Notes:

> • | Repeat the sequence to add neighbors.

> Associate BFD Neighbor Groups with the BFD Protocol
> config
> context <context_name>
> bfd-protocol
> bfd nbr-group-name <grp_name> active-if-name <if_name> <nexthop_address>
> bfd nbr-group-name <grp_name> passive-if-name <if_name> <nexthop_address>
> Important: Save your configuration as described in the Verifying and Saving Your Configuration chapter of this guide.

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883