Tag Archives: 3.3h

3.3 Fundamental routing concepts

3.3.h Implement, optimize and troubleshoot redistribution between any routing protocol

screenshot

down arrow smaller

bgp_speed_challenge

nothing fancy here. simply provide complete connectivity and verification as quickly as possible. set a stop watch. you may or may not be surprised. the timer will let you know. good luck.

3.3.h Implement, optimize and troubleshoot redistribution between any routing protocol

The use of a routing protocol to advertise routes that are learned by some other means, such as by another routing protocol, static routes, or directly connected routes, is called redistribution. While running a single routing protocol throughout your entire IP internetwork is desirable, multi-protocol routing is common for a number of reasons, such as company mergers, multiple departments managed by multiple network administrators, and multi-vendor environments . Running different routing protocols is often part of a network design. In any case, having a multiple protocol environment makes redistribution a necessity.

Differences in routing protocol characteristics, such as metrics, administrative distance, classful and classless capabilities can affect redistribution. Consideration must be given to these differences for redistribution to succeed.

Distance Vector Protocols

When you redistribute one protocol into another, remember that the metrics of each protocol play an important role. Each protocol uses different metrics. For example, the Routing Information Protocol (RIP) metric is based on hop count, but Interior Gateway Routing Protocol (IGRP) and Enhanced Interior Gateway Routing Protocol (EIGRP) use a composite metric based on bandwidth, delay, reliability, load, and maximum transmission unit (MTU), where bandwidth and delay are the only parameters used by default. When routes are redistributed, you must define a metric that is understandable to the receiving protocol. There are two methods to define metrics when redistributing routes.

The redistribution of IGRP/ EIGRP into another IGRP/ EIGRP process does not require any metric conversion, so there is no need to define metrics or use the default-metric command during redistribution. A redistributed static route takes precedence over the summary route because the static route has an administrative distance of 1 whereas EIGRP summary route has an administrative distance of 5. This happens when a static route is redistributed with the use of redistribute static command under the EIGRP process and the EIGRP process has a default route.

This output below shows a RIP router redistributing static, IGRP, EIGRP, OSPF, and IS-IS routes.

router rip

network 132.110.0.0

redistribute static

redistribute igrp 10

redistribute eigrp 10

redistribute ospf 10

redistribute isis default-metric 10

The RIP metric is composed of hop count, and the maximum value is 15. Anything above 15 is considered infinite; as an example you can use 16 to describe an infinite metric in RIP. When redistributing a protocol into RIP, Cisco recommends that you use a low metric, such as 1. A high metric, such as 10, limits RIP even further. If you define a metric of 10 for redistributed routes, these routes can only be advertised to routers up to 5 hops away, at which point the metric (hop count) exceeds 15.

Link State Protocols

It is possible to run more than one OSPF process on the same router. However, running more than one process of the same protocol is rarely needed, and consumes router’s memory and CPU cycles. You do not need to define metric or use the default-metric command when redistributing one OSPF process into another.

This output shows an IS-IS router redistributing static, RIP, IGRP, EIGRP, and OSPF routes.
router isis

network 49.1234.1111.1111.1111.00

redistribute static

redistribute rip metric 20

redistribute igrp 1 metric 20

redistribute eigrp 1 metric 20

redistribute ospf 1 metric 20

The IS -IS metric must be between 1 and 63. There is no default-metric option in IS-IS— you should define a metric for each protocol, as shown in the example above. If no metric is specified for the routes being redistributed into IS-IS, a metric value of 0 is used by default.

Adam, Paul (2014-07-12). All-in-One CCIE V5 Written Exam Guide (Kindle Locations 2764-2766).  . Kindle Edition.

http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/8606-redist.html

 

3.3.h Implement, optimize and troubleshoot redistribution between any routing protocol

also

  • 3.3.a Implement and troubleshoot static routing
  • 3.3.b Implement and troubleshoot default routing

eigrp INTO ospf (note default-information originate always)

R6#sh run | sec router ospf
router ospf 1
log-adjacency-changes
redistribute eigrp 1 subnets
network 6.6.6.0 0.0.0.255 area 0
network 10.1.67.0 0.0.0.255 area 0
 default-information originate always

ospf INTO eigrp

router eigrp 1
 redistribute ospf 1 metric 1 1 255 255 1500
network 6.6.6.0 0.0.0.255
network 192.168.36.0
no auto-summary

R7#sh ip route ospf
1.0.0.0/24 is subnetted, 1 subnets
O E2    1.1.1.0 [110/20] via 10.1.67.6, 00:21:34, FastEthernet1/0
O E2 192.168.13.0/24 [110/20] via 10.1.67.6, 00:21:34, FastEthernet1/0
3.0.0.0/24 is subnetted, 1 subnets
O E2    3.3.3.0 [110/20] via 10.1.67.6, 00:21:34, FastEthernet1/0
O E2 192.168.15.0/24 [110/20] via 10.1.67.6, 00:21:34, FastEthernet1/0
4.0.0.0/24 is subnetted, 1 subnets
O E2    4.4.4.0 [110/20] via 10.1.67.6, 00:21:34, FastEthernet1/0
5.0.0.0/24 is subnetted, 1 subnets
O E2    5.5.5.0 [110/20] via 10.1.67.6, 00:21:34, FastEthernet1/0
6.0.0.0/32 is subnetted, 1 subnets
O       6.6.6.6 [110/2] via 10.1.67.6, 00:21:34, FastEthernet1/0
O E2 192.168.36.0/24 [110/20] via 10.1.67.6, 00:21:34, FastEthernet1/0
O E2 192.168.34.0/24 [110/20] via 10.1.67.6, 00:21:34, FastEthernet1/0
O E2 192.168.35.0/24 [110/20] via 10.1.67.6, 00:21:34, FastEthernet1/0
O*E2 0.0.0.0/0 [110/1] via 10.1.67.6, 00:06:33, FastEthernet1/0

v5_practice

R7#trace 200.1.1.2

Type escape sequence to abort.
Tracing the route to 200.1.1.2

1 10.1.67.6 64 msec 68 msec 16 msec
2 192.168.36.3 84 msec 72 msec 24 msec
3 192.168.34.4 48 msec 88 msec 72 msec
4 200.1.1.2 144 msec *  128 msec

R2#sh run | sec ip route
ip route 192.168.13.0 255.255.255.0 100.1.1.1
ip route 192.168.34.0 255.255.255.0 200.1.1.1

R1#sh run | sec ip route
ip route 0.0.0.0 0.0.0.0 100.1.1.2

R4#sh run | sec ip route
ip route 0.0.0.0 0.0.0.0 200.1.1.2

R1#sh ip route | i Gate
Gateway of last resort is 100.1.1.2 to network 0.0.0.0

3.3.h Implement, optimize and troubleshoot redistribution between any routing protocol

3.3.h Implement, optimize and troubleshoot redistribution between any routing
protocol
Route Redistribution

Internetworks may be comprised of a variety of routing protocols. As such, redistribution may be required for inter-communication between these disparate protocols. A requirement of redistribution is a seed metric which in the case of directly connected networks is ordinarily provided by the interface, as in EIGRP below:

dsw1#sh int f0/1

FastEthernet0/1 is up, line protocol is up (connected)

Hardware is Fast Ethernet, address is 0016.479e.4542 (bia 0016.479e.4542)

Internet address is 10.1.4.6/30

MTU 1536 bytes, BW 100000 Kbit, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

With redistribution, however, there is no directly connected interface to supply the metric. OSPF provides a default, whereas RIP and EIGRP are ambiguous:

Protocol Default Seed Metric

OSPF 20; except BGP, which is 1

IS-IS 0

RIP Infinity

IGRP/EIGRP Infinity

When redistributing into RIP or EIGRP a seed metric must be provided, unlike OSPF which provides a default. However, for effective redistribution into OSPF the subnets keyword is used to gather routes described by VLSM, or only classful networks will be included in the redistribution.

dsw1(config)#router ospf 1

dsw1(config-router)#redistribute eigrp 1

% Only classful networks will be redistributed

dsw1(config-router)#redistribute eigrp 1 subnets

Into RIP redistribution command options:

redistribute protocol [process-id] [match route-type]

[metric metric-value] [route-map map-tag]

Into EIGRP command options:

redistribute protocol [process-id] [match {internal | external 1 | external 2}]

[metric metric-value] [route-map map-tag]

Into OSPF and all non-protocol specific command options:

redistributeprotocol [process-id] {level-1 | level-1-2 | level-2} [autonomous-system-number] [metric {metric-value | transparent}] [metric-typetype-value] [match {internal | external1 | external2}] [tagtag-value] [route-mapmap-tag] [subnets] [nssa-only]

One way redistribution

Typically a default route is offered to the edge protocol whereas the core network has all edge routes redistributed into its core routing protocol.

Two way redistribution

As the name implies all routes are redistributed both ways. In a multi-area, multi-protocol topology this can present the unwanted side effect of routing loops and route feedback. A routing loop may occur if a packet becomes endlessly routed through the topology. Route feedback may occur if redistributed route information gets redistributed back to the originator.