PATH MANIPULATION AND CONTROL

Route Manipulation and Control

Route Tags

To create a route tag list, use the global configuration mode command: route-tag list list_name

route-tag list TO_CAT2 seq 10 permit 0.0.0.2 0.0.0.0


A route-tag can be referenced inside of a route map using the keyword match.

route-map ADV_TO_R4 permit 10
match tag list TO_CAT2

To filter advertisements:

router eigrp 10 distribute-list route-map ADV_TO_R4 out eth0/0

Note: that distribute-lists have an impact on high-availability and fail-over.

Distribute List

Allow the filtering of network prefixes on a neighbor-by-neighbor basis using standard or extended access control lists.

Prefix List

Allow the filtering of network prefixes on a neighbor-by-neighbor basis using a prefix list.

Filter-List

Used in OSPF and BGP. In OSPF filter lists can be used to filter prefixes between OSPF areas.

Preventing Loops with Tags

Split Horizon

Split horizon is a method of preventing routing loops in distance-vector routing protocols such as RIP and EIGRP by prohibiting a router from advertising a route back onto the interface from which it was learned. Split horizon follows the principle that; Never advertise a route out of the interface through which you learned it.

Split horizon prevents the advertisement of reverse routes. EIGRP and BGP enable split horizon by default. DMVPN is one of the technologies that will require the disabling of split horizon on the hub.

To disable split-horizon on an interface, use the interface configuration command: no ip split-horizon {eigrp }

TODO:

1. View split horizon status of an interface.
2. Disable split horizon on interface
3. Disable split horizon for EIGRP. Note: EIGRP resyncs after split horizon change.

Route Poisoning

Advertises a prefix with an infinity metric; in RIP, this is metric of 16., OSPF sets the LSA age to 3600

Maximum Hops

The maximum hops in EIGRP can be modified using the EIGRP router configuration command: metric maximum-hops number where number is the maximum number of hops beyond which a route will be considered unreachable. The modification of the maximum-hops results in a new adjacency being created with existing neighbors.

Note: Modification of the maximum-hops results in the deletion of all EIGRP sourced routes in the RIB.

The maximum-hops can be configured using the command: show ip protocols

In EIGRP named mode, the maximum-hops can be configured under the topology base address-family configuration mode.

Filtering

EIGRP

Configuration of a distribution-list results in a resynchronization. Modification of the referenced access lists also results in a resynchronization.

Access-lists additionally affect the high-availability when interfaces do down.

Offset Lists

When configuring offset-lists, configuring an non-existent ACL or configuring zero (0) results in all network prefixes being included in their offset-lists metric modification.

Offset-lists provide some form of route poisoning.

UNDERSTANDING ROUTE-MAPS

Overview

Route-maps provide If/Then/Else logic like in programming languages. Route-maps are very flexible in matching prefixes. A single route-map consists of a series of route-map statements with the same name but uniquely identified using its sequence number. When a route is matched by a route-map statement, either as a permit or deny, processing stops of the route-map.

A route-map statement references an ACL or prefix-list to match against a route with the action to take i.e.,permit or deny.

A single route-map contains one or more route-map commands (entries). Each route-map entry has underlying matching parameters, configured with the match command.

The flexibility of route maps means that they can be utilized in many routing scenarios such as the following:

• Filtering networks during advertisements
• BGP Path Attribute Manipulation: such as the next hop, AS PATH, local preference, weight etc. on a neighbor-by-neighbor basis
• Route tagging in routing protocols such as OSPF
• Policy based routing(PBR)
• Modifying network attributes particularly during advertisement.

Like an access-list, an implicit deny any appears at the end of a route-map. The consequences of this deny depend on how the route-map is being used.

Matching Prefixes Using Route-maps

When configuring a route-map, the first action should be a match statement. Route-maps use the following features to match routes:

• Access control lists
• Prefix-lists
• Route-type
• Metric, metric type
• Next hop
• BGP attributes

Actions consist of permit or deny. If a route-map references an ACL or prefix-list, the ACL and prefix-list permit statement means match this prefix. The deny statement means do not match the prefix. Route-maps have an implicity deny all statement at the end. Route-maps support modifying prefix attributes. This is heavily utilized in BGP.

Processing of route-maps starts with the lowest sequence number and proceeds sequentially, until a match statement; processing then stops. However, if a route-map statement has the "continue" keyword, processing continues in spite of the match statement. The code continue keyword is used in route-map statements when logical "AND" processing is needed.

When configuring filtering using prefix lists, only one prefix list can be used for filtering per direction(ingress or egress). However, when filtering using route maps, a route map can be configured with many statements each using different prefix lists.

Configuration

Route maps consist of the following set of actions:

1. Sequence number: determines the order of processing.
2. Conditional matching: prefix characteristics
3. Processing action: permit or deny statements
4. Addition, modification of route characteristics

When deleting a specific route map statement, include the sequence number to prevent deleting the entire route map.

If no other entry is already defined with the supplied route-map name, an entry is created with the sequence number 10. If only one entry is already defined with the supplied route-map tag, that entry is the default entry for the route-map command, and the sequence number of the sentry is unchanged. If more than one entry is already defined with the supplied route-map tag, an error message is displayed, indicating that the sequence number is required. The match condition route-map configuration commands are used to define the conditions to be checked. The set condition route-map configuration commands are used to define the actions to be followed if there is a match and the action to be taken is permit. A route-map statement without any match statements will be considered matched.

1. Define the route map: The route map is defined by specifying the route map name, processing action and sequence number. The command used is route-map <route-map-name> [permit | deny] <sequence-number> where:
   • permit | deny (Optional): specifies the action to be taken if the route map match conditions are met. The meaning of permit or deny is dependent on how the route-map is used. The default action of a route-map command is permit with a sequence number of 10 (if not included in the configuration).
   • sequence-number (Optional): number that indicates the position that a new route-map statement will have in the list of route-map statements already configured with the same name. The first route map statement a sequence number of 10 by default. Route-maps do not automatically increment the sequence number like ACLs. If no sequence number is entered, subsequent statements overwrite the first statement.
2. Matching

   Route mps use ACLs or prefix-lists match the prefixes. The route-map tells what to do with the matched routes using permit or deny. A permit action in the ACL or prefix list means match the prefix and a deny action means do not match the prefix. All ACLs types are supported i.e., named or numbered standard and extended ACLs. It is important to note that when matching prefixes, IPv4 and IPv6 prefixes cannot be matched in the same route map. Different separate route maps are required to match each protocol separately.

   Matching is done using the following commands:

   Command	Action
   match ip address [1-199 | 1300 - 1699 | acl-name]	Matches based on a referenced named or numbered access control list.
   match ip address prefix-list <prefix-list-name>	Matches based on a referenced prefix list.
   match as-path <ASN-acl-number>	Matches prefixes based on a regular expression query to isolate the Autonomous System Number (ASN) in the BGP path attribute AS path. The AS path ACLs are numbered 1 - 500. This command allows for multiple match variables.
   match length <min> <max>	matches based on a packet's Layer 3 length
   match interface <interface-id>	matches any routes that have the next hop out of one of the interfaces specified.
   match ip next-hop <acl-1 acl-2 acl3>	matches any routes that have a next-hop router address permitted by one of the access-lists specified
   match ip route-source <acl-1 acl-2 acl-3>	matches routes that have been advertised by routers and acccess servers that have an address permitted by one of the access lists specified.
   match metric [<1-4294967295> | external <1-4294967295>] [+-deviation]	matches routes have the metric specified, a range, or within acceptable deviation.
   match route-tpe [external | internal | level-1 | level-2 | local]	matches routes of the specified type.
   match community <list-name | list-num>	matches a BGP community
   match tag <0-4294967295>	matches based on the tag of a route that was set by another router. This command allows for multiple match variables.
   match local-preference <local-preference>	Matches prefixes based on the BGP attribute local preference. This command allows for multiple match variables.

   A route-map without the match statement is equivalent to match any.

   When processing a route-map, the processing starts at the top with the lowest sequence number and progress sequentially. The first successful match ends the execution of the prefix-list except if the continue statement is used. A deny statement in the ACL/Prefix list that is referenced by a permit statement in the RM results in no match and execution of the RM moves to the next RM sequence number.

   When matching prefixes, it is possible to chain ACLs or prefixes using the match ip address <acl-1> <acl-2> <acl-2> command. This represents and OR function where matching is done successfully if any of the ACLs is matched.

   A deny statement in an ACL, prefix list or AS-Path ACL excludes the route from being matched. When matching using an ACL or prefix list, take note of the following:

   ACL/Prefix-list Action	Route-map Action	Result
   deny	permit

3. Specify the action to be carried out on matched routes (Optional): This is implemented using the set command. Supported features include the following:

   Command	Action
   set metric [+value | -value | <value>]	sets the metric value for a route or modifies the existing metric. Allowable values are in the range 0 - 4294967295.
   set metric-type [type-1 | type-2 | internal | external]	sets the metric type for the destination routing protocol.
   set default interface <interface-id>	indicates where to send output packets that pass a match clause of a route map for policy routing.
   set interface <interface-id>	indicates where to sent output packets that pass a match clause of a route map for policy routing.
   set ip default next-hop <ip-address>	indicates where to send output packets that pass a match clause of a route map for policy routing and for which the Cisco IOS software has no explicit route to the destination.
   set ip default next-hop verify-availability	Forces the router to check the CDP database to determine if an entry is available for the next hop that is specified by the set ip default next-hop command. This command is used to prevent traffic from being "blackholed" if the configured next hop becomes unavailable.
   set ip next-hop <ip-address-1 ip-address-2 ip-address-3 | peer-address | self>	indicates where to send output packets that pass a match clause of a route map for policy routing. BGP dynamic manipulation uses the peer-address or self keywords.
   set ip next-hop verify-availability	Forces the router to check the CDP database or use object tracking to determine if the next hop that is specified for policy-based routing is available.
   set ip vrf	Indicates where to forward packets that pass a match clause of a route map for policy routing when the next hop must be under a specified VRF name.
   set next-hop	Specifies the address of the next-hop
   set level [level-1 | level-2 | stub-area | backbone]	Indicates at what level or type of area to import routes into (for IS-IS and OSPF routes).
   set as-path [tag | prepend <as-path-string | last-as 1-10>]	Modifies an autonomous system path for BGP routes.
   set automatic-tag	Automatically computes the BGP tag value.
   set community [<community-number> | additive | <well-known-community> | none]	Sets the BGP community attribute.
   set local-preference <bgp-path-attribute>	Specifies a local preference value for the BGP autonomous system path.
   set weight <0-65535>	Specifies the BGP weight value.
   set origin [igp | incomplete]	Specifies the BGP origin code.
   set tag	Specifies the tag value for the destination routing protocol.

Interpretation

route-map DEMO permt 10
match X Y Z
match A
set B
set C
route-map DEMO permit 20
match Q
set R
route-map DEMO permit 30

The route map DMEO is interpreted as follows: If ((X or Y or Z) and (A) match) then (set B and C)
Else
If Q matches then set R
Else
Set nothing

A route map without a match or set command such as route-map DEMO permit 40, matches all prefixes and permits all other prefixes. If this is the last sequence in a route map, it disables the implicit deny all command at the end of the route map.

Application of Route Maps

Where route maps are applied depends on what they will be used for:

Filtering

Redistribution

Uses the command redistribute route-map <route-map-name>.

Prefix Advertisement: Filtering of prefixes when during advertisement using a routing protocol uses the command distribute-list route-map <route-map-name>

Attribute Manipulation

use the command neighbor <ip-address> route-map <route-map-name>

Path Control

use the ip policy route-map <route-map-name> command under the interface. Details of how route maps are used for path control are explained here: HERE

Redistribution Caveats

Redistribution of routing information adds to the complexity of a network and increases the potential for routing confusion, so you should use it only when necessary. The key issues that arise when you are using redistribution are as follows:

• Routing loops
• Incompatible routing information
• Inconsistent convergence time

Verification

show route-map <route-map-name>

Verify what was configured. This displays all route maps configured. The specific route map name can be added show route-map <-route-map-name>

Route Maps

Route maps are complex access lists that allow some conditions to be tested against the packet or route using match commands. If the conditions match, actions can be taken to modify attributes of the packet or route. These actions are specified by the route-map's set commands. A collection of route map statements that have the same route map name is considered one route map. Within a route map, each route-map statement is numbered and therefore can be edited individually. The statements in a route-map correspond to the lines of an access list.

Route map actions can be either permit or deny. Route map statements are processed sequencially from top to bottom with a first-match processing just like an access list; the first statement that is matched in the route map ends the processing of the route map. This default behaviour can be modified by using the keyword continue. Route-maps have an implicit deny statement at the end.

Access-lists and prefix lists can only match on IP addresses or routes. To match against other attributes sch as external or internal routes, BGP attributes route-maps can be used.

Route map Applications

• Route filtering
• Route filtering during Redistribution: Route maps offer the benefit of manipulating route metrics through the set commands. The route maps applied using the redistribute command.
• Policy-based routing (BR): Route maps can be used to match source and destination addresses, protocol types, and end-user applications. When a match occurs, a set command can be used t determine the interface or next-hop address t which the packet should be sent. The route-map is applied t an interface using the command: policy route-map interface configuration command.
• BGP: in addition to filtering, route-maps provide sophisticated manipulation of BGP path attributes. The route-map is applied using the BGP neghbir router configuration command.

Components of a Route Map

The four components of a route map include the following:

1. sequence number: much like an ACL wth sequence numbers. The default sequence number is 10.
2. processing action: agan like an ACL wth permit and deny statements
3. Match criteria: what is ths sequence n the route map lkng for? f match statement is not configured, the default debavr is t match all addresses.
4. action (tnal): what d we d wth these matches?

Configuration of Route Maps

Step 1: define the route map using the route-map global configuration command: route-map name [permit | deny] sequence

When defnng a route-map, f the permit / deny statement is not configured, and the sequence number is not configured, then the default wll be permit wth a seeqence number f 10.

Step 2: define the matching conditions using the match command and tnally the action t be taken when each condition is matched using the set command.

Step 3: apply the route map.

Route Map Rules

route-map sequence numbers d not automatically increment. When the sequence-number parameter f the route-map is not used, the following ccrs:

• If no other entry is already defined wth the sled route-map tag, that entry is the default entry for the route-map command and the sequence number f the entry is nchanged.
• If only one entry is already defined wth the sled route-map tag, that entry is the default entry for the route-map command, and the sequence number f the entry is nchanged.
• If more than one entry is already defined wth the sled route-map tag, an error message is displayed, indicating that the sequence number is required.
• If the n route-map name command is specified (without the sequence number parameter), the whle route-map is deleted.
• like an access-list, an implicit deny any aears at the end f a route-map. The cnseqences f ths deny deend n hw the route-map beng used.
• The match conditions route-map configuration cmmands are used t define the conditions t be checked. The set condition route-map configuration cmmands are used t define the actions t be followed f there is a match and the action t be taken is permit.
• A route-map statement without any match statements wll be cnsdered matched.
• If more than one condition is configured nder the same match statement, then t acts as an or logic.
• If more than one match statement aears nder the same sequence number, then t acts as an AND logic statement.
• If more than one sequence number is used n a route-map, then each sequence number acts as sme from f Else-f statement blck f the route-map.
• To match all packets, the route-map clase mts the match command.
• If a sequence number is mssed, the default sequence number frst sequence number is set t 10. Sccessve route-map statements without sequence numbers verwroute the exstng frst route-map statement (10).
• When a route is matched by a route-map entry ether as a permit or deny, the is sts processing the route-map for that route, even when there are more entres n the route-map.

Matching Conditions

Route maps provide more flexibility when matching various characteristics of the traffic. Route maps map against IP addresses by referencing access-lists or prefix-lists. Additionally, the provide the ability to match against route-type, metric, metric-type, next-hop, BGP attributes etc.

Command	Description
match address access-list | name | ...access_lst_number|name|prefix-list ... list-name | ... prefix-list prefix-list-name	Matches any routes that have a netwrk number that is ermted by a standard or extended access list or prefix list. Mltle access-lists or prefix lists can be specified matching any one reslts n a match.
match length min max	Matches based on a packet's Layer 3 length.
match interface type-number	Matches any routes that have a next-hop router address ermtted by one f the access lists
match next-hop access-list-number | access-list-name | .... access-list-number | ... access-list-name	Matches any routes that have a next-hop router address ermtted by one f the access-lists specified.
match route-srce access-list-number | access-list-name | .. access-list-number | ...access-list-name	Matches routes that have been advertsed by routers and access servers that have an address ermtted by one f the access lists specified.
match metric metric value	Matches routes that have the metric specified.
match route-type [external | internal | level-1 | level-2 | local]	Matches routes f the specified type.
match community list-number | list-name	Matches a BGP community
match tag tag-value	Matches based n the tag f a route.

Route Map Set Actions

Command	Description
set metric metric-value	Sets the metric value for a routing protocol
set metric-type [type-1 | type-2 | internal | external]	Sets the metric type for the destination routing protocol
set default-interface type number | .. type number	Indicates where to send output packets that pass a match clause of a route-map for policy routing and for which the Cisco IOS Software has no explicit
set interface type number | ... type number	indicates where t send tt packets that ass a match clase f a route-map for policy routing.
set default next-hop	indicates where t send tt packets that ass a match clase f a route-map for policy tng and and for which the Csc is sftware has n exlct route t the destination.
set default next-hop verify-availability	Frces the router t check the CD database t determine f an entry is avalable for the next h that is specified by the set default next-hop command. Ths command is used t revent traffc from beng "black-hled" f the configured next h becomes navalable.
set next-hop -address | ... address	indicates where t send tt packets that ass a match clase f a route-map for policy routing.
set next-hop verify-availability	Frces the router t check the CD database or se bject tracking t determine f the next-hop that is specified for policy-based routing is avalable.
set vrf	indicates where t forward packets that ass a match clase f a route map for policy routing when the next h must be nder a specified vrtal routing and vrwardng (VRF) name.
set next-hop	specifies the address f the next-hop
set level | level-1 | level-2 | stb-area | backbone|	indicates at what level or type f area t mrt routes not (for is-is and SF routes.)
set as-path | tag | reend< as-path-strng	modifies an autonomous system path for BGP routes.
set automatic tag	automatically computes the BGP tag value.
set community community-number | additive | well-known-community | none	Sets the BGP community attribute.
set local-reference BGP-path-attributes	specifies a local reference value for the BGP autonomous system path.
set weight BGP-weight	specifies the BGP weight value
set rgn	specifies the BGP rgn code
set tag	specifies the tag value for destination routing protocol.

continue command

processing f a route-map starts from the t t bottom. f a matching statement is found, after processing the matching set statement f the matching statement, the processing f the route-map ends. however, wth the continue command, f a matching statement is processed, the continue command cases the processing t continue and not break t but t continue processing subsequent statements f the route-map.

Application of the route-map

To utilise the route map, t has t be applied t an interface (policy based routing) or a routing protocol.

When Applying a route-map, t should be applied n the inbound interface. Applying a route-map n the t gng interface has n effect. T asscate the route-map, sse the command: policy route-map rt-map-name

When filtering wth the route-map, the "permit" or "deny" within the ACL or prefix-list des not mean that route wll be fltered or not. t jst means f that is or sn't matched. A permit n an ACL/prefix-list means take action n the route-map. A deny means mve t next route-map sequence number. Dfferent ACLs or prefix-lists can be called by the same route-map.

Gven the following access-lists: access-list 50 permit 172.16.0.0 0.0.255.255
access-list 60 permit 192.168.0.0 0.0.255.255
access-list 60 deny 192.168.10.0 0.0.0.255
access-list 60 permit any

route-map TEST deny 10
match address 50
route-map TEST permit 20
match address 60


The route-map sequence number 10 means the route-map is ermted t deny traffc from 172.16.0.0 0.0.255.255

ROUTE REDISTRIBUTION

Overview

Redistribution is the process of taking routes from the routing table and injecting them into a routing protocol. The source of the injected routes could be any of: connected routes, static routes or routes from another routing protocol that are in the routing table (RIB). Sourcing routes from the RIB implies that;

1. the best routes are redistributed.
2. Loop-free routes are redistributed.

The routing device performing the redistribution participates in the routing domain of the source and destination of the redistributed routes; for instance, if redistributing routes from OSPF into BGP, the redistributing device participates in the OSPF routing domain as well as the BGP routing domain.

Reasons for Redistribution

An enterprise may implement redistribution for one or more of the following reasons:

1. A company merger where the networks of both companies run different routing protocols.
2. Different organizational department networks are under different network administrative control perhaps based on geography.
3. An organization inter-connecting with partner networks
4. Hardware constraints such routing devices with low memory, CPU.
5. During conversion or migration from one routing protocol to another.
6. Mixed vendor environment.
7. Support for legacy equipment in the network.
8. Application-specific protocols support.
9. IGP routes may need to be advertised into BGP.
10. Some BGP routes may need to be advertised into an IGP.
11. Political boundaries.

Types of Redistribution

Redistribution can be implemented in two ways:

• Unidirectional Redistribution (one-way redistribution): routes are redistributed from the source to the destination protocol on a single routing device in one direction. Conceptually, this type of redistribution is similar to multipoint one-way redistribution where redistribution is implemented on more than one routing device but in the same direction i.e. from source X to destination Y.

  Creation of routing loops in one-way redistribution is not possible. Usually one way redistribution occurs when redistributing from a source that is not a routing protocol such as default routes or static routes. Rarely is one-way redistribution implemented with the source being a routing protocol.

• Mutual Redistribution (two-way redistribution): Mutual redistribution occurs when routes from routing protocol X are injected into routing protocol Y and routes sourced from routing protocol Y are injected into routing protocol X on the same routing device. Mutual redistribution can be thought of as a form of route connversion. Mutual redistribution can be implemented on a single routing device in the network (single-point two-way redistribution) or on two or more routing devices (multipoint two-way redistribution).

  Multipoint mutual redistribution has a high-potential for introducing routing loops. These routing loops can be prevented from occuring using: access-lists or prefix-lists referenced by route-maps. One of the most scalable solutions for preventing routing loops introduced by route redistribution is through the use of route-tags.

Mutual multipoint redistribution provides the benefit of fault-tolerence where the failure of a redistributing device at one point does not affect traffic across both routing domains.

Sources of Routes

Route Source	Description
Connected	Any interface in an "Up" state that is not associated with the destination protocol. Secondary IP addresses are also redistributed.
Static	Any static route that is present in the RIB. Static routes can only be a source i.e. mutual redistribution can not be implemented with static routes.
OSPF	Any routes in the RIB sourced from OSPF. If redistributing from OSPF to BGP, by default, OSPF external routes are not redistributed into BGP unless the match external option is used.
EIGRP	Any routes in the RIB sourced from EIGRP including connected interfaces. Any route that is in the topology table will be redistributed.
BGP	Any routes in the RIB sourced from BGP. By default, routes learned from iBGP peers are not redistributed into IGP protocols unless the command redistribute internal is configured.
IS-IS	Any routes in the RIB sourced from IS-IS. Only routes from the L2 link-state database are selected. Directly connected networks are not included during redistribution.

Redistribution Rules

1. Redistribution is not transitive: Routes that have been redistributed into a routing protocol can not be further redistributed into a third routing protocol on the same routing device. To resolve this, mutual redistribution should be configured between routing protocol A and B, B and C and A with C.
2. Sequential redistribution is allowed when it is spread across multiple routers: Redistributed routes from protocol A into Protocol B on Router R1. These routes can be redistributed into protocol C on router R2.
3. Routes to be redistributed must be in the routing table.

Seed Metric

During redistribution, metric information of the redistributed routes is lost because the different routing protocols calculate route metrics using different methods. Route metrics are only maintained when redistribution occurs from one routing process or autonomous system to another with the same routing protocol.

Seed metric is assigned, by default, to redistributed routes, when no metric is manually configured. The redistribution metric of redistributed routes can be configured in the following ways:

• Using the metric keyword of the redistribution command.
• Configuration of a default metric where all redistributed routes into the destination routing protocol receive the configured default seed metric. This can be implemented using the command default-metric.
• Using a route-map with the metric command.

The recommended best practice from Cisco is to set a default metric when redistributing routes.

The following table shows the seed metric of routes when redistributing from one routing protocol to another.

	DESTINATION
SOURCE	RIP	EIGRP	OSPF	IS-IS	BGP
RIP	Metric maintained	Infinity	20	0	RIP Metric*
EIGRP	Infinity	Metric maintained	20	0	EIGRP Metric*
OSPF	Infinity	Infinity	Metric maintained	0	OSPF Metric*
BGP	Infinity	Infinity	1	0	Path attributes maintained

* The IGP metric becomes the MED path attribute of the prefix.

Routes with the default redistribution metric of infinity are installed into the Link-state database (OSPF), BGP table (BGP) or similar data structures of the destination routing protocol. These routes are not inserted into the routing table because they are considered unreachable due to their metric of infinity. EIGRP does not add routes with infinity metric to its topology table.

When redistributing between two same routing protocols but different processes or autonomous systems, the metric remains unchanged because the destination protocol understands the metric of the source protocol. For example OSPF process 1 to OSPF process 2, the metric of the redistributed routes remains the same.

When redistributing connected networks (on local interfaces),

Configuration of Redistribution

When redistributing routes into a routing protocol from another routing domain, there are many controls that can be implemented that the redistribution point such as tagging, metric configuration, filtering of redistributed routes.

When configuring redistribution, redistribution commmands are entered into the router configuration mode of the destination routing protocol. In a way, the redistribution configuration command says: "Redistribute routes from the specified routing source into this routing source."

EIGRP

Any route that is in the EIGRP topology table is a candidate for redistribution. Routes redistributed into EIGRP are given a default seed metric of infinity. This prevents the routes from being installed into the EIGRP topology table. The exception to this is when redistributing routes from one EIGRP autonomous system to another. In such a scenario, the path metric is maintained.

In IOS, routes redistributed into EIGRP have an administrative distance of 170. This administrative distance is the same regardless of the source routing protocol i.e. even if the source of the prefixes was another EIGRP autonomous system.

Redistribution is configured under the EIGRP router command:

redistribute <source> <metric> <bandwidth> <delay> <reliability> <load> <mtu> route-map <route-map_name>

where <source> is the source of the redistributed routes.

In EIGRP named mode, redistribution is configured under topology base configuration mode as shown below:

R2(config)#router eigrp EIGRP_NAMED
R2(config-router)#address-family ipv4 unicast autonomous-system 1
R2(config-router-af-topology)#redistribute ospf 1


In EIGRP classic mode, redistribution is configured under EIGRP router configuration mode as shown below:

R2(config)#router eigrp 1
R2(config-router)#redistribute ospf 1


When configuring the EIGRP redistribution seed metric, delay value is in tens of microseconds.

When redistributing BGP routes into EIGRP, the administrative tag is set to the autonomous system number of the BGP device that sent the prefixes.

EIGRP requires the configuration of a seed metric during redistribution. If the seed metric is not included in the redistribution, EIGRP will give the route a metric of infinity.

In IPv4, by default, connected routes that are associated with EIGRP will have their configured network addresses included in a redistribution. However, with IPv6, by default, they are not included redistributed. Some connected interfaces may not necessarily be destination networks for network traffic such as transit networks. However, during redistribution, it may be a good idea to redistribute these networks as well as it may sometimes result in traffic blackholing. This is especially likely when utilising some tunneling techniques such as MPLS tunneling.

Redistribution of routers into EIGRP can be implemented using the following EIGRP routing device command: redistribute <source> metric <bandwidth delay reliability load mtu>

Command	Description
BGP	redistribute bgp <ASN> where <ASN> is the BGP autonomous system number.

OSPF

In OSPF, the routing device that redistributes external routes into OSPF is referred to as an autonomous system boundary router (ASBR).

When redistributing routes into OSPF, redistributed routes are given an administrative distance of 110 and are flagged as OSPF external routes. The AD is similar to the administrative distance of intra-area and inter-area routes. When making forwarding decisions for routes from multiple sources, OSPF's prefix selection process gives preference in the following order:

1. intra-area routes
2. inter-area routes
3. external routes
1. external type 1 routes
2. external type 2 routes

The metric for OSPF external type 1 routes equals the redistribution metric plus the total path metric to the autonomous system boundary router. The metric for OSPF external type 2 metric equals only the redistribution metric. If two type 2 routes have the same metric, then the one with the lower forwarding cost is preferred. This is the default external metric type used by OSPF.

When configuring redistribution into OSPF, the OSPF router mode command redistribute is used.

redistribute <source> subnets metric <metric> metric-type (<1 | 2>) tag <0 - 4294967295> route-map <route-map-name>

Where:

• source: the source of routes
• metric: seed metric of the redistributed routes
• route-map: filtering can be applied using the route-map or route path information

In older IOS versions, if the optional subnets command is excluded, only classful routes are advertised. In newer IOS versions, the subnets keyword is automatically added by the IOS into the running configuration.

Redistributing routes between OSPF processes will preserve the path metric during redistribution regardless of the metric type.

To inject EIGRP sourced routes into OSPF:

R2(config)#router ospf 1
R2(config-router)#redistribute eigrp 1 subnets

OSPF Forwarding Address

By default, packets destined for external destinations are routed through the advertising autonomous system boundary router (ASBR). Scenarios like this are not optimal in certain circumstances. By default, OSPF sets the forwarding address value to 0.0.0.0. The forward address can be viewed using the command show ip ospf database external.

OSPF will change the forwarding address from 0.0.0.0 to the next-hop IP address in the source routing protocol when:

• OSPF is enabled on the ASBR's interface that points to the next-hop IP address of the redistributed routes.
• The interface is not set to passive.
• The OSPF interface type is set to a broadcast or non-broadcast type.

Enabling OSPF on R2's interface facing towards R1 (10.123.1.1) changes the forwarding address from 0.0.0.0 to the interface pointed towards R1. The forwarding-address changes on R3 irrespective of whether redistribution is configured on R3.

When redistributing OSPF prefixes into another routing protocol, IOS provides the option to match internal, external or NSSA-external routes. This can be useful in preventing the redistribution of external OSPF routes into another routing protocol.

When redistributing into OSPF, the optional subnets keyword results in subnets being included in the redistribution. In newer IOS versions the subnets keyword is automatically included by default if the keyword was not configured.

OSPF External Route Types

OSPF classifies redistributed routes as external type 1 and external type 2 routes. By default, OSPF classifies routes as external type 2 routes.

OSPF issues redistributed routes with a default metric of 20. OSPF external type 1 routes are redistributed with the default metric of 20 and maintain this same metric throughout the OSPF autonomous system. OSPF external type 2 routes have a default metric of 20 or configured redistribution metric. However, as the routes are distributed within the OSPF domain, the metric does not increase.

Command	Description
BGP	redistribute bgp <ASN> where <ASN> is the BGP autonomous system number. When redistributing BGP into OSPF, the subnets keyword is automatically added to the redistribution command.
EIGRP	redistribute eigrp

BGP

Redistributing routes into BGP does not require a seed metric because it is a path vector protocol. Redistributed routes have the following BGP attributes set:

• Origin is set to incomplete
• Next-hop address is set to the next-hop IP address identified in the source protocol.
• The weight is set to 32,768.
• The MED is set to the path metric of the source protocol.

Redistributing routes from OSPF to BGP does not include OSPF external routes by default. The optional match external (1 | 2) keyword is required to redistribute OSPF external routes. The type of OSPF external routes can be configured using 1 or 2 to redistribute type-1 or type-2 routes only.

Protocol	Command
OSPF	redistribute ospf <process> where <process> is the OSPF process ID. When redistributing OSPF routes into BGP, by default, only internal OSPF routes are redistributed into BGP. To redistribute external and nssa-external OSPF routes into BGP, list route type after the redistribute match keyword. With the match keyword external type 1 and/or type 2 routes can be matched. Additionally, the route match can be configured in a route-map.

Formation of Loops

If redistribution happens at one point (one routing device) or two points in one direction, the possibility of a routing loop does not exist. If mutual redistribution at more than one point occurs, then the possibility of loop formation exists.

Route feedback occurs when a redistributed route is advertised back into the original source routing protocol. Route feedback is likely to occur in networks where mutual redistribution is implemented in more than one device i.e. multipoint mutual redistribution. Route feedback causes:

• Sub-optimal routing
• Routing loops
• Invalid routing tables

Types of Loops

Loops exist in two categories:

• Control-plane: exist when routing information is looping. Control-plane loops are detected using the debug ip routing command. This command is largely silent. However, it will display when a route is added or removed from the routing table. If this happens repeatedly, then we can be certain that we are dealing with a loop. Redistribution should be done after observing the debug ip routing output for a while.
• Data-plane: occur when data packets are looping. The best way to detect data-plane loops is to use the ping and traceroute commands. If traffic is being dropped, then a black hole exists. Looped packets may include packets for known networks (in RIB) or unknown networks (default route). With mutual multipoint redistribution, it is also likely that the default route may be looped.

Troubleshooting Loops

Mutual multipoint route redistribution usually forms routing loops. The following techniques can be used to prevent the formation of routing loops during redistribution:

1. Filtering of network prefixes during redistribution.
2. Filtering by route tag during redistribution
3. Increasing the seed metric
4. Modifying the administrative distance.
5. Route summarization

When troubleshooting routing loops:

• Multiple techniques can be combined.
• Document the physical and logical topology to include the routing protocols and desired traffic flows.
• Focus on keeping the source routing domain loop-free.

The underlying principle in preventing the formation of loops in a multipoint mutual redistribution network, at each redistribution point, routes from a source protocol need to be allowed into the destination protocol and these routes prevented from returning from the destination routing protocol back to the source protocol.

Prefix Filtering

Prefixe filtering can be implemented during the redistribution with some prefixes filtered (preventing from being redistributed) on one redistribution device and permitted to be redistributed on another device. This can be used for controlled path manipulation.

Route filtering can be implemented during redistribution through the configuration of a route-map. The prefixes to be filtered are identified through the use of a prefix-list or access control list (ACL).

Filtering Connected Networks

Explicit configuration always overrides implicit configuration. When redistributing the networks assigned to connected interfaces, the use of the network command advertises the networks of the connected interfaces. However, when filtering, if a filter excludes these networks, the networks configured on these interfaces will not be advertised. This affects all IGP protocols that use interfaces to form neighborships such as OSPF, EIGRP. BGP behaves a little different as it is enabled on a per neighbor- basis and not per interface basis. If a route-map references an access list or prefix-list to identify interfaces to be filtered (not redistributed), these interfaces should be identified using the permit ACL keyword.

Route Tagging

A route tag is associated with routes during redistribution. A route-tag is a numeric value associated with a route. Use of the AD of the source protocol for the route-tag is a good technique.

The use of route-tags is a more scalable solution. In the case of prefix-lists and ACLs, everytime a new prefix is added, the prefix-list or ACL needs to be updated to reflect this new addition. When creating route-tags, a recommended best practice is to tag routes using the administrative distance of the routing protocol. This way, it is easier to tell the origin of the route.

Increase Seed Metric

Increase the seed metric to a value higher and less preferred to locally originated routes.This can be done through any of the seed metric configuration methods.

Configuring different seed metric values for different prefixes helps with preventing sub-optimal routing through traffic shaping. The redistribution metric on one redistributing device can be made lower so that to reach these prefixes, traffic transits through a specific path.

The seed metric can be modified through a route-map using the set metric command.

R1#traceroute 10.0.35.1
Type escape sequence to abort.
Tracing the route to 10.0.35.1
VRF info: (vrf in name/id, vrf out name/id)
  1 10.0.12.2 12 msec 16 msec 20 msec
  2 10.0.24.2 28 msec 64 msec 44 msec
  3 10.0.49.2 52 msec 16 msec 72 msec
  4 10.0.59.1 48 msec 68 msec 60 msec
  5 10.0.35.1 88 msec 28 msec 36 msec

R3(config)#ip access-list standard ACL_10.3
R3(config-std-nacl)#permit 10.0.35.0 0.0.0.3
R3(config-std-nacl)#20 permit 10.3.0.0 0.0.255.255
R3(config-std-nacl)#30 permit 10.0.59.0 0.0.0.3
R3(config-std-nacl)#40 permit 10.5.0.0 0.0.255.255
R3(config-std-nacl)#exit
R3(config)#route-map O2E permit 10
R3(config-route-map)#match ip address ACL_10.3
R3(config-route-map)#set metric 1000000 1 255 1 1500
R3(config-route-map)#set tag 110
R3(config)#router eigrp 1
R3(config-router)#redistribute ospf 1 route-map O2E

R1#show ip eigrp topology 10.0.35.0/30
EIGRP-IPv4 VR(EIGRP_NAMED) Topology Entry for AS(1)/ID(10.1.13.1) for 10.0.35.0/30
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1966080, RIB is 15360
  Descriptor Blocks:
  10.0.13.2 (GigabitEthernet1/0), from 10.0.13.2, Send flag is 0x0
      Composite metric is (1966080/1310720), route is External
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 20000000 picoseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Originating router is 3.3.3.3
      External data:
        AS number of route is 1
        External protocol is OSPF, external metric is 0
        Administrator tag is 110 (0x0000006E)
  10.0.12.2 (GigabitEthernet0/0), from 10.0.12.2, Send flag is 0x0
      Composite metric is (7864320/7208960), route is External
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 110000000 picoseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Originating router is 10.2.13.1
      External data:
        AS number of route is 1
        External protocol is OSPF, external metric is 4
        Administrator tag is 0 (0x00000000)
R1#

R1#traceroute 10.0.35.1
Type escape sequence to abort.
Tracing the route to 10.0.35.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.13.2 8 msec 44 msec 16 msec
R1#


Administrative Distance

Increase the administrative distance for external routes on routing protocols that support it. Alternatively, the AD can be modified for preferred routes.

External Route Summarization

Summarizing routes as they are redistributed into the second domain if they are re-inserted back to primary routing domain. They are less specific and not taken.

Route-Maps

Route-maps can be used to prevent the formation of routing loops. Tools to match the traffic include: access-lists, prefix-lists, route-tags, communities (BGP), administrative distance, distribute-lists(ACLs, prefix-lists), offset-lists(ACLs, prefix-lists).

In redistribution of EIGRP to OSPF, using route-tags, the tag for EIGRP is permitted on one mutually redistributing routing device and denied on another redistributing routing device.

For two protocols mutual redistribution at two points: R1 BLUE:
route-map o2E deny 10
match tag 90
route-map O2E permit 20
set tag 110
R1 RED
riyte-map E2O deny 10
match tag 110
route-map E2O permit 20
set tag 90
R2 RED
route-map O2E deny 10
match tag 90
route-map O2E permit 20
set tag 110

R2 BLUE
route-map E2O deny 10
match tag 110
route-map E2O permit 20
set tag 90


Redistribution Scenarios

Two-point Mutual Redistribution

Three-point Mutual Redistribution

If three protocols are involved in mutual redistribution at three points. The generic method to prevent the formation of routing loops when redistributing mutually between three or more protocols inside a route map:

1. deny destination protocol
2. match protocol 2
3. match protocol 3
4. match protocol 4
5. match protocol n

The challenge with this redistribution is if the tag will be maintained when redistributing from protocol 1 to protocol 2 and then to protocol 3. For example when redistributing from OSPF into EIGRP and subsequently into RIP. The tag is maintained when copying the routes from:

This may be IOS specific

Source	Destination	Tag Maintained
RIP	OSPF	Yes
RIP	OSPF	YES
EIGRP	RIP	NO
OSPF	RIP	NO
EIGRP	OSPF	YES
OSPF	EIGRP	YES

A solution would be for the following:

route-map O2E deny 10
match tag 90
route-map O2E permit 20
match tag 120
set tag 120
route-map O2E permit 30
set tag 110


The above route-maps will only operate if configured as a system on all the mutually redistributing routers. The route-maps will operate as a system and potentially prevent loops in 99.999% of the cases.

However, some situations exist where the above route-map will not succeed in preventing a routing loop.

When configuring redistribution, the configuration commands should be entered inside the destination routing protocol.

IPv6

By default, IPv6 does not include connected networks when doing redistribution. IPv6 does not include the subnets keyword in OSPFv3. This is because IPv6 does not necessarily use the concept of classful networks. To redistribute connected networks, use the keyaword include-connected.

IOS XE no longer redistributes the connected subnets on the interfaces over which the protocol is enabled. IOS XE routers will only redistribute route entries that exactly match the source protocol in the route table.

The keyword included-connected can be used with the redistribution command to include the locally connected prefixes in the dynamic routing protocol redistribution. The include-connected keyword only injects prefixes for interfaces that have a dynamic routing protocol enabled. To inkect networks for interfaces without a dynamic protocol the redistribute connected command is still required.

TODO : Redistribute some local interfaces and not others. This results in the IP address of the excluded connected interfaces being removed from the routing table. The solution is to include a match statement for that interface in the route map. Redistribution lABS ----------------------------------- -Configure RIP, redistribute OSPF -Configure EIGRP. redistribute to/from RIP, redistribute to/from OSPF -Configure OSPF: redistribute where possible for full connectivity.

Understanding Prefix-Lists

Overview

Like access control lists (ACLs), prefix lists are used as a filtering tool. However, unlike ACLs, which are used for a wide variety of tasks, prefix lists are predominantly used by routing protocols for route/prefix filtering. Prefix lists provide granular control over matching prefixes for route filtering; matching the prefix and prefix-length; ACLs match only the prefix. Like an ACL, prefix-lists use permit or deny clauses to match prefixes and prefix lengths. Internal processing of IP prefix-lists uses an internal tree structure that results in faster matching of routes compared to ACLs. In recent developments, improvements have been made with the processing of prefix-lists and ACLs in hardware.

Naming and Structure

The naming and structure of prefix lists is similar to named ACLs. The prefix list naming recommendations include the following:

• Name cannot contain spaces or punctuation marks.
• Prefix list name cannot begin with a number
• Prefix list name must be unique; prefix lists of different types cannot have the same name
• Prefix list name can have a mixture alpahnumeric characters
• Recommended that the prefix list name be written in capital letters
• Prefix list names are locally significant. Multiple routers on the network can be configured to have the same name
• Choose names that identify the function of the prefix list

Prefix-lists use the concept of a unique name for a single prefix-list with multiple entries. Each entry has a unique sequence number. The use of sequence numbers allow for subsequent modification of the prefix list through the addition or deletion of individual entries from the prefix list.

Prefix-lists do not use wildcard masks or bits; they use the prefix length for matching against the network address and subnet mask. A prefix-list is used to match routes particularly for route filtering and not for packet filtering:

• Permit: the route is matched, the route should not be filtered.
• Deny: route is not matched and should be filtered.

Prefix-list have a default implicit deny all statement at the end. The command to configure a prefix-list is: ip prefix-list <name> [seq <num>] {deny | permit} <prefix/prefix-length> [ge <prefix-length>] [le <prefix-length>] where:

• Prefix/prefix-length: is the prefix and prefix-length that is being matched.
• ge ( greater than or equal): value is used to match against the subnet mask. The prefix-length to be matched by ge is in the range: ge value and 32. The ge value sets the lower limit of the prefix length range to be matched. The prefix-length MUST be less than the ge value; otherwise IOS will report this error message % Invalid prefix range for 10.1.1.0/24, make sure: len < ge.value <= le.value.

• le (less than or equal to): when matching the route's prefix length, the le value sets the upper limit of the prefix length comparison range. The range of prefix lengths to be matched is between route prefix length to the le value. The prefix-length must be less than the le value; otherwise IOS will report this error message: % Invalid prefix range for 10.1.1.0/24, make sure: len < ge.value <= le.value
• le and ge: if both are configured, on the same prefix list statement, the value of le must be greater than or equal to the value of ge:
  • Prefix lengths to be matched are in the range ge value to le value.
  • If le is equal to ge, then the prefix length is matched against the specific le/ge value rather than a range.

Prefix Matching

The logic of a prefix-list is as follows:

• The route's prefix must be within the range of addresses implied by the prefix-list command's prefix/length parameters.
• The route's prefix-length must match the range of prefixes implied by the prefix-list command's prefix-length, ge and le parameters.

Every matching done by a prefix list checks the network address and the subnet mask. Up to four types of matching can be performed using prefix lists:

1. Exact match: only the prefix and prefix length are specified by the prefix list. The ge and le keywords are not used in prefix and prefix length matching.
   • ip prefix-list PL permit 10.1.1.0/24
     • Matches the network address 10.1.1.x.
     • Matches the subnet mask 255.255.255.0.
2. From minimum prefix length: implemented using the ge keyword.
   • ip prefix-list PL permit 10.1.1.0/24 ge 26
     • Matches the network address 10.1.1.x
     • Matches the subnet mask 255.255.255.192 - 255.255.255.255
   • ip prefix-list PL permit 10.1.1.0/8 ge 9
     • Matches the network address of 10.x.x.x
     • Matches the subnet mask 255.128.0.0 - 255.255.255.255.
3. Up to a maximum prefix length: implemented using the le keyword prefix length in the range prefix length to le value.
   • ip prefix-list PL permit 10.1.1.0/16 le 26
     • Matches the network address 10.1.x.x
     • Matches the subnet 255.255.0.0 - 255.255.255.192
   • ip prefix-list PL permit 10.1.1.0/19 le 27
     • Matches for the network address of 10.1.x.x/19
     • Matches the subnet mask 255.255.224 - 255.255.255.224.
4. Range of prefix lengths: implemented by the configuration of both ge and le keywords:
   • ip prefix-list PL permit 10.1.1.0/16 ge 22 le 30
     • Matches the network address 10.1.x.x
     • Matches the subnet 255.255.252.0 - 255.255.255.252
   • ip prefix-list PL permit 10.1.1.0/24 ge 26 le 29
     • Matches the network address of 10.1.1.x
     • Matches the subnet mask 255.255.255.192 - 255.255.255.248.
   • ip prefix-list PL permit 10.1.1.0/24 ge 26 le 26
     • Matches the network address 10.1.1.x
     • Matches the subnet 255.255.255.192

Matching the Default Route

IPv4

ip prefix-list PL permit 0.0.0.0/0

• Match any address
• The subnet mask MUST match zero(0). Only the default route has a subnet mask of zero.

IPv6

ipv6 prefix-list PL permit ::/0

Match all prefixes

IPv4

ip prefix-list PL permit 0.0.0.0/0 le 32

• le 32 implies that the subnet mask will match from 0.0.0.0 - 255.255.255.255. Even the broadcast address is matched.

IPv6

ipv6 prefix-list PL permit ::/0 le 128

Exercise

Objective: Deny all routes which have the first 24-bits of 10.10.10.x AND subnet mask is GE 24 but LE 30.

Understanding and Configuration of VRF-Lite in Cisco IOS

Introduction

Virtual Routing and Forwarding Instances (VRFs) are used to segregate traffic at Layer 3. They are similar in concept to VLANs that are used to segregate traffic at Layer 2. VRFs create virtual routers with separate instances of the routing table (RIB) and forwarding table (FIB) independent from the global routing table. VRFs segment traffic in the data-plane and the control-plane based on the logical or physical interface that you assign to the VRF. The concept of VRFs is similar to that of virtual machines (VMs). It is important to note that the concept of VRF is locally significant to the device on which it is configured. VRFs improve network functionality because network paths can be segmented without requiring multiple physical routers. VRF-Lite is a feature of VRF that provides VRF without MPLS configuration.

If VRFs are configured on more than one router to ensure end to end connectivity, the links interconnecting the routers will need to be configured as a trunk (for layer 2 switches) or sub-interfaces (for routers) if a single link is to be shared with traffic from other separate VRFs or the default routing table. VRFs leverage trunk links with 802.1Q encapsulation to maintain connectivity with same VRFs on remote devices.

By default, all routers have single running VRF instance referred to as the global VRF instance. All interfaces, the global routing table, the forwarding table are assigned to this global VRF instance. One or more VRF instances can be configured on a single router that are separate from the global routing VRF instance. The configured VRF instances can then be identified by their configured VRF names. Interfaces or sub-interfaces are then assigned to the configured VRFs. IP addresses configured on these VRF instances can overlap if the interfaces are assigned to different VRFs. These IP addreses are not included in the global routing table. If routing protocols are configured for each VRF instance, then separate SFP (OSPF) or DUAL (EIGRP) calculation instances take place for each VRF instance.

VRFs generically segment traffic at Layer 3. However, it is possible to leak traffic between VRFs if such connectivity is required. This can be done through:

• Through importing or exporting routes between the multiple routing tables.
• Static routing.
• Physical cable to leak traffic.

Minimum configuration of VRF is called VRF Lite; VRFs without any MPLS configuration. The main reason for VRF Lite is separation of the control-plane.

The number of VRFs on a single device should be limited to a small number as each VRF instance consumes local resources.

Business Use Cases of VRF

• ISPs use VRFs to keep IP routing tables of customers logically separate to create separate VPNs for each customer when layer 3 end-to-end connectivity is provided; thus the technology is also referred to as VPN routing and forwarding.
• Network segmentation for different applications, departments
• Security concerns
• Corporate mergers
• Data Centre access

VRF-Aware Routing

To support dynamic routing in VRFs, the routing protocols in use should be VRF aware. Static routes support VRF. VRF-aware dynamic routing protocols include: RIP, EIGRP, OSPF, IS-IS, MP-BGP. Policy routing is also VRF-aware.

Configuration

Step 1: Specify Locally Significant VRF Name

VRFs can be configured in one of two ways:

• ip vrf <vrf-name>: This global configuration command supports only IPv4 VRFs.

  R2(config)#ip vrf RESEARCH
R2(config)#ip vrf FINANCE
R2(config-vrf)#description Finance VRF


• vrf definition <name>: This global configuration command supports IPv4 and IPv6 VRFs. It is generally recommended to configure VRFs using this format. The address family should be additionally configured using the VRF mode command address-family ipv4. The address family needs to be explicitly configured after defining the VRF name.

  R3(config)#vrf definition RESEARCH
R3(config-vrf)#description Research and Development Department VRF
R3(config-vrf)#address-family ipv4
R3(config-vrf-af)#exit
R3(config-vrf)#exit
R3(config)#vrf definition FINANCE
R3(config-vrf)#description Finance Department VRF
R3(config-vrf)#address-family ipv4


Cisco IOS has additional commands that enable VRFs created using the command ip vrf <vrf-name> to support IPv6. To enable support for IPv6 VRFs, in global configuration mode issue the command vrf upgrade-cli multi-af-mode common-policies vrf <vrf-name> . By default all VRFs will be configured to support IPv4 and IPv6. If the optional VRF name is configured, only the specified VRF will support IPv4 and IPv6. The keyword common-policies copies the pre-configured parameters such as route-target, route distinguisher to be applied to IPv6 as previously configured under IPv4. Any IPv6 addresses configured on the interfaces assigned to any VRF will be removed. When you view the running configuration file, the syntax will be changed to vrf definition <vrf-name> which is the new format.

The VRF description can be added to provide helpful information on the purpose of the VRF. It can be added using the VRF mode command description <description>.

CAUTION:

• If deleting a VRF using the command no ip vrf <vrf-name> the IPv4 addresses configured on the interfaces assigned to that VRF will be removed.
• VRF names are case sensitive. It is recommended to use all upper case letters for VRF names.

In VRF-lite, there is no need to specify the import and export route target (RT). and route distinguisher (RD).

Step 2: Apply VRF to the Interface

Interfaces, physical or logical, can belong to only one VRF at a time. Interfaces assigned to the VRF belong to that VRF's routing table instance. Interfaces not in a VRF are in the global or default VRF. Interfaces are assigned to VRFs depending on the way the VRF was created using one of the following interface mode commands:

• ip vrf forwarding <vrf-name>: This command is used when the VRF was created using the global configuration command ip vrf <name>.
  R1(config)#interface gigabitethernet1/0
R1(config-if)#ip vrf forwarding FINANCE


• vrf forwarding <vrf-name>: This command is used when the VRF was created using the global configuration command vrf definition <vrf-name>.
  R3(config)#interface gigabitethernet3/0
R3(config-if)#vrf forwarding FINANCE


Caution: If an IP address was configured on the interface, it gets removed. Always view the interface configuration for IP address before assigning any interface to a VRF.

Step 3: Routing with the VRF

VRF-aware Static Route

To configure a static route for a VRF, run the global configuration command: ip route vrf <vrf-name> <network> <mask> <next-hop>

R1(config)#ip route vrf FINANCE 172.17.1.0 255.255.255.0 10.20.13.2

VRF-Aware Dynamic Routing

The following routing protocols are VRF-aware: EIGRP, IS-IS, OSPF, BGP, RIP.

EIGRP

EIGRP is VRF-aware in both classic and named mode. The configuration of VRF routing for classic and named mode is similar.

EIGRP Named Mode

router eigrp EIGRP_NAMED
address-family ipv4 vrf <vrf-name> autonomous-system <id>

R2(config)#router eigrp EIGRP_NAMED
R2(config-router)#address-family ipv4 unicast vrf FINANCE autonomous-system 1


EIGRP Classic Mode

R2(config)#router eigrp 1 vrf FINANCE


OSPF

router ospf <process-id> vrf <vrf-name>

R2(config)#router ospf 1 vrf RESEARCH
R2(config-router)#capability vrf-lite

The command R2(config-router)#capability vrf-lite causes OSPF to not perform PE specific checks.

BGP

Service providers use BGP VRFs extensively to segregate customer traffic. To utilize VRFs in BGP, the route distinguisher needs to be configured to uniquely identify traffic. Configuration of the route target is done using the VRF configuration mode command rd <ASN:nn> or rd <ip-address:nn> The RD is used to keep the routes from various clients unique regardless of whether the IP addresses used are overlapping; how we distinguish one route in one VRF from a route in another VRF particularly when the IP addresses are overlapping in prefix and prefix-length. In some versions of IOS, the RD needs to be configured otherwise the following error message is displayed when configuring VRF support in BGP.

R2(config)#router bgp 65000
R2(config-router)#bgp router-id 2.2.2.2
R2(config-router)#address-family ipv4 unicast vrf FINANCE
% VRF FINANCE does not have an RD configured.

In the newer versions, you can skip over this step.

If two VRF instances X and Y have overlapping IP addresses, such as 10.0.0.0/24. and VRF X has a configured RD of 1:1 and Y 2:2, the addresses will be differentiated such that X's addresses will be 1:1:10.0.0.0/24 and Y 2:2:10.0.0./24. In the case of MP-BGP, these count as two separate routes.

R2(config)#ip vrf FINANCE
R2(config-vrf)#rd 65000:100
R2(config)#router bgp 65000
R2(config-router)#address-family ipv4 unicast vrf FINANCE
R2(config-router-af)#neighbor 10.20.13.2 ebgp-multihop 2
R2(config-router-af)#address-family vpnv4 unicast


On remote router:

R3(config-router)#vrf definition FINANCE
R3(config-vrf)#rd 65001:200
R3(config-if)#router bgp 65001
R3(config-router)#address-family ipv4 unicast vrf FINANCE
R3(config-router-af)#neighbor 10.20.12.2 remote-as 65000
R3(config-router-af)#neighbor 10.20.12.2 ebgp-multihop 2
R3(config-router-af)#network 10.3.10.0 mask 255.255.255.0
R3(config-router)#address-family vpnv4 unicast


Verification

All testing or verification commands have to include the specific VRF whose features you would like to view.

show ip route vrf <vrf-name>

To view the IP routing table of a specific VRF.

R2#show ip route vrf RESEARCH

Routing Table: RESEARCH
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 10 subnets, 3 masks
C        10.2.14.0/24 is directly connected, Loopback14
L        10.2.14.1/32 is directly connected, Loopback14
C        10.2.15.0/24 is directly connected, Loopback15
L        10.2.15.1/32 is directly connected, Loopback15
B        10.3.14.0/24 [20/0] via 10.10.13.2, 00:43:49
B        10.3.15.0/24 [20/0] via 10.10.13.2, 00:44:17
B        10.3.16.0/24 [20/0] via 10.10.13.2, 00:44:09
C        10.10.12.0/30 is directly connected, GigabitEthernet0/0.10
L        10.10.12.2/32 is directly connected, GigabitEthernet0/0.10
O        10.10.13.0/30 [110/2] via 10.10.12.1, 01:17:12, GigabitEthernet0/0.10
      172.30.0.0/24 is subnetted, 1 subnets
O        172.30.0.0 [110/3] via 10.10.12.1, 01:17:12, GigabitEthernet0/0.10
      172.31.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.31.1.0/24 is directly connected, GigabitEthernet1/0
L        172.31.1.1/32 is directly connected, GigabitEthernet1/0
R2#


ping vrf <vrf-name>

Check reachability of remote networks.

R2#ping vrf RESEARCH 10.2.14.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.14.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/12 ms
R2#


show run vrf <vrf-name>

To view VRF configurations for a specific vrf.

R2#show run vrf FINANCE
Building configuration...

Current configuration : 715 bytes
ip vrf FINANCE
 description Finance VRF
 rd 65000:100
!
!
interface GigabitEthernet0/0
 no ip address
 duplex auto
 speed auto
 media-type gbic
 negotiation auto
!
interface GigabitEthernet0/0.20
 encapsulation dot1Q 20
 ip vrf forwarding FINANCE
 ip address 10.20.12.2 255.255.255.252
!
interface FastEthernet4/0
 ip vrf forwarding FINANCE
 ip address 172.16.1.10 255.255.255.0
 duplex auto
 speed auto
!
router eigrp 1
!
address-family ipv4 vrf FINANCE autonomous-system 1
  network 10.20.12.0 0.0.0.3
 exit-address-family
!
router bgp 65000
 !
 address-family ipv4 vrf FINANCE
  neighbor 10.20.13.2 remote-as 65001
  neighbor 10.20.13.2 ebgp-multihop 2
  neighbor 10.20.13.2 activate
 exit-address-family
!
end


show ip vrf

To view configured VRFs.

R2#show ip vrf
  Name                             Default RD          Interfaces
  FINANCE                          65000:100           Gi0/0.20
                                                       Fa4/0
  RESEARCH                         65000:200           Gi0/0.10
                                                     Gi1/0
                                                     Lo14
                                                     Lo15


show ip route vrf *

To view the IP routing table for all VRFs at once.

R2#show ip route vrf *
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set


Routing Table: FINANCE
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 7 subnets, 3 masks
B        10.3.10.0/24 [20/0] via 10.20.13.2, 04:25:16
B        10.3.11.0/24 [20/0] via 10.20.13.2, 02:22:08
B        10.3.12.0/24 [20/0] via 10.20.13.2, 02:21:21
B        10.3.13.0/24 [20/0] via 10.20.13.2, 01:45:26
C        10.20.12.0/30 is directly connected, GigabitEthernet0/0.20
L        10.20.12.2/32 is directly connected, GigabitEthernet0/0.20
D        10.20.13.0/30
           [90/3072] via 10.20.12.1, 05:28:49, GigabitEthernet0/0.20
      172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C        172.16.1.0/24 is directly connected, FastEthernet4/0
L        172.16.1.10/32 is directly connected, FastEthernet4/0
D        172.16.2.0/24
           [90/28672] via 10.20.12.1, 05:28:49, GigabitEthernet0/0.20

Routing Table: RESEARCH
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 10 subnets, 3 masks
C        10.2.14.0/24 is directly connected, Loopback14
L        10.2.14.1/32 is directly connected, Loopback14
C        10.2.15.0/24 is directly connected, Loopback15
L        10.2.15.1/32 is directly connected, Loopback15
B        10.3.14.0/24 [20/0] via 10.10.13.2, 01:24:15
B        10.3.15.0/24 [20/0] via 10.10.13.2, 01:24:43
B        10.3.16.0/24 [20/0] via 10.10.13.2, 01:24:35
C        10.10.12.0/30 is directly connected, GigabitEthernet0/0.10
L        10.10.12.2/32 is directly connected, GigabitEthernet0/0.10
O        10.10.13.0/30 [110/2] via 10.10.12.1, 01:57:38, GigabitEthernet0/0.10
      172.30.0.0/24 is subnetted, 1 subnets
O        172.30.0.0 [110/3] via 10.10.12.1, 01:57:38, GigabitEthernet0/0.10
      172.31.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.31.1.0/24 is directly connected, GigabitEthernet1/0
L        172.31.1.1/32 is directly connected, GigabitEthernet1/0
R2#


show ip interfaces vrf <vrf-name>

Display interfaces in specified VRF.

show ip protocols vrf <vrf-name>

View dynamic protocols running in a VRF.

R2#show ip protocols vrf FINANCE
*** IP Routing is NSF aware ***

Routing Protocol is "eigrp 1"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP-IPv4 Protocol for AS(1) VRF(FINANCE)
    Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
    NSF-aware route hold timer is 240
    Router-ID: 172.16.1.10
    Topology : 0 (base)
      Active Timer: 3 min
      Distance: internal 90 external 170
      Maximum path: 4
      Maximum hopcount 100
      Maximum metric variance 1
      Total Prefix Count: 3
      Total Redist Count: 0

  Automatic Summarization: disabled        
  Maximum path: 4                          
  Routing for Networks:                    
    10.20.12.0/30                          
  Routing Information Sources:            
    Gateway         Distance      Last Update
    10.20.12.1            90      04:45:54
  Distance: internal 90 external 170      
                                          
Routing Protocol is "bgp 65000"            
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  IGP synchronization is disabled          
  Automatic route summarization is disabled
  Neighbor(s):                            
    Address          FiltIn FiltOut DistIn DistOut Weight RouteMap
    10.20.13.2                            
  Maximum path: 1                          
  Routing Information Sources:            
    Gateway         Distance      Last Update
    10.20.13.2            20      01:02:31
  Distance: external 20 internal 200 local 200

R2#


EIGRP

show ip eigrp vrf <vrf-name> topology

R2#show ip eigrp vrf FINANCE topology
EIGRP-IPv4 Topology Table for AS(1)/ID(172.16.1.10) VRF(FINANCE)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
              
P 10.20.12.0/30, 1 successors, FD is 2816
        via Connected, GigabitEthernet0/0.20
P 172.16.2.0/24, 1 successors, FD is 28672
        via 10.20.12.1 (28672/28416), GigabitEthernet0/0.20
P 10.20.13.0/30, 1 successors, FD is 3072
        via 10.20.12.1 (3072/2816), GigabitEthernet0/0.20


show ip eigrp vrf <vrf-name> neighbors

R2#show ip eigrp vrf FINANCE neighbors detail
EIGRP-IPv4 Neighbors for AS(1) VRF(FINANCE)                                      
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
0   10.20.12.1              Gi0/0.20                 12 04:34:57   17   102  0  7
   Version 10.0/2.0, Retrans: 0, Retries: 0, Prefixes: 2                          
   Topology-ids from peer - 0                                                    


show ip eigrp vrf <vrf-name> interfaces

Alternative command show eigrp address-family ipv4 vrf <vrf-name> interfaces

R2#show ip eigrp vrf FINANCE interface detail
EIGRP-IPv4 Interfaces for AS(1) VRF(FINANCE)
                              Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending
Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Gi0/0.20                 1        0/0       0/0          17       0/0           64           0  
  Hello-interval is 5, Hold-time is 15
  Split-horizon is enabled
  Next xmit serial
  Packetized sent/expedited: 1/0
  Hello's sent/expedited: 3579/2                  
  Un/reliable mcasts: 0/1  Un/reliable ucasts: 1/1
  Mcast exceptions: 0  CR packets: 0  ACKs suppressed: 0
  Retransmissions sent: 0  Out-of-sequence rcvd: 1
  Topology-ids on interface - 0
  Authentication mode is not set
R2#


BGP

show bgp vpnv4 unicast all

To view all the shared prefixes in all VRFs

R2(config-if)#do show bgp vpnv4 unicast all
BGP table version is 10, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path  
Route Distinguisher: 65000:100 (default for vrf FINANCE)              
 *>  10.3.10.0/24     10.20.13.2               0             0 65001 i
 *>  10.3.11.0/24     10.20.13.2               0             0 65001 i
 *>  10.3.12.0/24     10.20.13.2               0             0 65001 i
 *>  10.3.13.0/24     10.20.13.2               0             0 65001 i
Route Distinguisher: 65000:200 (default for vrf RESEARCH)            
 *>  10.2.14.0/24     0.0.0.0                  0         32768 i      
 *>  10.2.15.0/24     0.0.0.0                  0         32768 i      
 *>  10.3.14.0/24     10.10.13.2               0             0 65001 i
 *>  10.3.15.0/24     10.10.13.2               0             0 65001 i
 *>  10.3.16.0/24     10.10.13.2               0             0 65001 i
R2(config-if)#

show bgp vpnv4 unicast vrf <vrf-name> summary

To view routes in the BGP table in a specific VRF

R2(config-if)#do show bgp vpnv4 unicast vrf RESEARCH
BGP table version is 10, local router ID is 2.2.2.2                    
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,    
Origin codes: i - IGP, e - EGP, ? - incomplete                          
RPKI validation codes: V valid, I invalid, N Not found                  
                                                                        
     Network          Next Hop            Metric LocPrf Weight Path    
Route Distinguisher: 65000:200 (default for vrf RESEARCH)              
 *>  10.2.14.0/24     0.0.0.0                  0         32768 i        
 *>  10.2.15.0/24     0.0.0.0                  0         32768 i        
 *>  10.3.14.0/24     10.10.13.2               0             0 65001 i  
 *>  10.3.15.0/24     10.10.13.2               0             0 65001 i  
 *>  10.3.16.0/24     10.10.13.2               0             0 65001 i  


show bgp vpnv4 unicast vrf <vrf-name> neighbor

To view BGP neighbors formed in a specific VRF

R2#show bgp vpnv4 unicast vrf RESEARCH neighbor
BGP neighbor is 10.10.13.2, vrf RESEARCH, remote AS 65001, external link
  BGP version 4, remote router ID 3.3.3.3                          
  BGP state = Established, up for 00:36:27                        
  Last read 00:00:42, last write 00:00:27, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:                                              
    1 active, is not multisession capable (disabled)              
  Neighbor capabilities:                                          
    Route refresh: advertised and received(new)                    
    Four-octets ASN Capability: advertised and received            
    Address family IPv4 Unicast: advertised and received          
    Enhanced Refresh Capability: advertised and received          
    Multisession Capability:                                      
    Stateful switchover support enabled: NO for session 1          
  Message statistics:                                              
    InQ depth is 0                                                
    OutQ depth is 0                                                
                                                                  
                         Sent       Rcvd                          
    Opens:                  1          1                          
    Notifications:          0          0                          
    Updates:                3          4                          
    Keepalives:            40         41                          
    Route Refresh:          0          0                          
    Total:                 44         46                          
  Default minimum time between advertisement runs is 0 seconds    
                                                                  
For address family: VPNv4 Unicast                                
  Translates address family IPv4 Unicast for VRF RESEARCH          
  Session: 10.10.13.2                                              
  BGP table version 10, neighbor version 10/0                      
  Output queue size : 0                                            
  Index 2, Advertise bit 0                                        
  2 update-group member                                            
  Slow-peer detection is disabled                                  
  Slow-peer split-update-group dynamic is disabled                
                                 Sent       Rcvd                  
  Prefix activity:               ----       ----                  
    Prefixes Current:               2          3 (Consumes 192 bytes)
    Prefixes Total:                 2          3                  
    Implicit Withdraw:              0          0                  
    Explicit Withdraw:              0          0                  
    Used as bestpath:             n/a          3                  
    Used as multipath:            n/a          0                  
                                                                  
                                   Outbound    Inbound            
  Local Policy Denied Prefixes:    --------    -------            
    Bestpath from this peer:              3        n/a            
    Total:                                3          0            
  Number of NLRIs in the update sent: max 1, min 0                
  Last detected as dynamic slow peer: never                        
  Dynamic slow peer recovered: never                              
  Refresh Epoch: 1                                                
  Last Sent Refresh Start-of-rib: never                            
  Last Sent Refresh End-of-rib: never                              
  Last Received Refresh Start-of-rib: never                        
  Last Received Refresh End-of-rib: never                          
                                       Sent       Rcvd            
        Refresh activity:              ----       ----            
          Refresh Start-of-RIB          0          0              
          Refresh End-of-RIB            0          0              
                                                                  
  Address tracking is enabled, the RIB does have a route to 10.10.13.2
  Connections established 1; dropped 0                            
  Last reset never                                                
  External BGP neighbor may be up to 2 hops away.                  
  Transport(tcp) path-mtu-discovery is enabled                    
  Graceful-Restart is disabled                                    
Connection state is ESTAB, I/O status: 1, unread input bytes: 0    
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 2
Local host: 10.10.12.2, Local port: 179
Foreign host: 10.10.13.2, Foreign port: 17911
Connection tableid (VRF): 2
Maximum output segment queue size: 50

Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x124CFC4):      
Timer          Starts    Wakeups            Next
Retrans            43          0             0x0
TimeWait            0          0             0x0
AckHold            45         41             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger            0          0             0x0
DeadWait            0          0             0x0
Linger              0          0             0x0
ProcessQ            0          0             0x0

iss: 3387542972  snduna: 3387543921  sndnxt: 3387543921
irs: 2815833713  rcvnxt: 2815834735                
                                                  
sndwnd:  15436  scale:      0  maxrcvwnd:  16384  
rcvwnd:  15363  scale:      0  delrcvwnd:   1021  
                                                  
SRTT: 997 ms, RTTO: 1025 ms, RTV: 28 ms, KRTT: 0 ms
minRTT: 16 ms, maxRTT: 1000 ms, ACK hold: 200 ms  
Status Flags: passive open, gen tcbs              
Option Flags: VRF id set, nagle, path mtu capable  
IP Precedence value : 6

Datagrams (max data segment is 1460 bytes):
Rcvd: 90 (out of order: 0), with data: 46, total data bytes: 1021
Sent: 88 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 44, total data bytes: 948

 Packets received in fast path: 0, fast processed: 0, slow path: 0
 fast lock acquisition failures: 0, slow path: 0
TCP Semaphore      0x6AAD22B4  FREE

R2#


OSPF

OSPF commands do not require the inclusion of the VRF keyword and VRF name within the command.

show ip ospf

Displays the VRF operational state of OSPF.

R2#show ip ospf
 Routing Process "ospf 1" with ID 172.31.1.1
   Domain ID type 0x0005, value 0.0.0.1
 Start time: 00:00:55.892, Time elapsed: 06:21:24.020
 Supports only single TOS(TOS0) routes
 Supports opaque LSA
 Supports Link-local Signaling (LLS)
 Supports area transit capability
 Supports NSSA (compatible with RFC 3101)
 Connected to MPLS VPN Superbackbone, VRF RESEARCH
 Event-log disabled
 It is an area border router
 Router is not originating router-LSAs with maximum metric
 Initial SPF schedule delay 5000 msecs
 Minimum hold time between two consecutive SPFs 10000 msecs
 Maximum wait time between two consecutive SPFs 10000 msecs
 Incremental-SPF disabled
 Minimum LSA interval 5 secs
 Minimum LSA arrival 1000 msecs
 LSA group pacing timer 240 secs
 Interface flood pacing timer 33 msecs
 Retransmission pacing timer 66 msecs
 Number of external LSA 0. Checksum Sum 0x000000
 Number of opaque AS LSA 0. Checksum Sum 0x000000
 Number of DCbitless external and opaque AS LSA 0
 Number of DoNotAge external and opaque AS LSA 0
 Number of areas in this router is 1. 1 normal 0 stub 0 nssa
 Number of areas transit capable is 0
 External flood list length 0
 IETF NSF helper support enabled
 Cisco NSF helper support enabled
 Reference bandwidth unit is 100 mbps
    Area BACKBONE(0)
        Number of interfaces in this area is 2
        Area has no authentication
        SPF algorithm last executed 01:59:51.104 ago
        SPF algorithm executed 12 times
        Area ranges are
        Number of LSA 5. Checksum Sum 0x01F6CD
        Number of opaque link LSA 0. Checksum Sum 0x000000
        Number of DCbitless LSA 0
        Number of indication LSA 0
        Number of DoNotAge LSA 0
        Flood list length 0