Route Redistribution Overview

Lessons Learned:

----------------------------------------------------

What routes are redistributed

How connected redistribution works

How IOS chooses routes to use

Why Routing loops can occur

How to identify routing loops

How to prevent routing loops

----------------------------------------------------

Route Redistribution –

Redistribution occurs from the routing table not the routing database.

When redistributing protocol X into Y, take.

-Routes in the routing table via protocol X

-Connected interfaces running protocol X

Route advertisement rules

-RIP vs EIGRP Vs OSPF VS BGP
 

Note the key point to understand is that the process of route redistribution occurs from the routing table and not the database.

Example – what’s installed in the EIGRP topology Vs what actually goes into the routing table.

When going between two protocols – taking source protocol X and putting it into Protocol Y, The router will first look at two things.

Ex: what are the routes actually installed in the routing table via that protocol and what are the connected interfaces, in the routing table that are running that protocol.

The first – in the case of EIGRP – what are the dynamic routes coming from our connected peers. Internal or external routes.

The connected interfaces – this will be based on the network statement that is running under the process.

So if we look at the “show IP protocols”, this will show us what are the connected links that care candidate to be redistributed between the processes.
 

Depending on the protocol – there are rules on what particular routes we can install in the table. And what routes we can advertise.

Connected Redistribution:

Implicitly occurs for connected links running the redistributed protocol

Additionally connected links can explicitly be include or excluded

-# redistribute connected (metric ) route-map.

-overrides implicit redistribution

When redistribution happens,. The router will be looking for two things, any dynamic routes in the routing table via that protocol. Then implicitly any interfaces that are running that process.

If we do not use the redistribute connected command, any interfaces in the source protocol that are directly connected will be redistributes into the destination protocol.

Note: there could be an issue – if we do explicitly list what links will be redistributed from the connected process – this will override what the implicit redistribution is.

We need to treat the dynamic routing process and the connected routing process as two different entities form the perspective of redistribution. As long as we do not manually issue the redistributed command – we should then assume that any interfaces running that protocol will be sent into the destination protocol.

 

How IOS chooses Paths:

Routing database choses one or more candidate paths.

-EIGRP via DUAL, OSPF via SPF, etc

-Load balancing via Maximum-paths.

If multiple equal matches between protocols…

-choose the lower administrative Distance

Install results in RIB and/or FIB.

Router will look through the database and find the actual paths that can go into the routing table. Then the router will look are there multiple matches for the exact prefixes from the different protocols.

|Ex: if we have a prefix 1.2.3.0 /24

And we’re learning it via both EIGRP and OSPF, then we will have to choose which one actually goes into the routing table. This will be based on the AD value. The lower AD will be candidate to go into the

RIB (routing table) and the FIB (the CEF table)

AD Values:

0 = Connected	115 = IS-IS
1 = Static	120 = RIP
5 – Eigrp Summary	160 = OD
90 = EIGRP internal	170 = Ext EIGRP
110 = OSPF	200 = Internal BGP
	255 Infinite

 

Ex: if we’re learning and External OSPF route and an External EIGRP route, and they’re equal longest matches for the same destination

We would prefer to install the OSPF route and not the External EIGRP route.

This could be an issue because the advertising rules for EIGRP and RIP are different than OSPF and BGP. The Distance vector protocols can only advertise routes that get installed into the routing table.

OSPF and BGP do not have this limitation because with OSPF, all routers in the flooding domain have to have the same copy of the database. BGP – the candidate routes are the ones that will the BGP best path selection process.

RIP Redistribution – V2

Doesn’t differentiate between internal and external routes.

-Administrative distance of 120 for all routes

No default seed metric

-#redistribute (protocol ) metric (hops)

-#default-metric (hops)

There’s cases where RIP does not choose the correct path because the router cannot distinguish between internal and external routes.

There’s no way to separate in the routing process an internal RIP distance between an External RIP distance.

When we redistribute into RIP, OSPF or EIGRP into RIP – there is NO default seed metric or see hop count.

This means that we need to either specify globally under the process with the default Metric command or specifically for that protocol.

Example: RIP

# redistribute OSPF 1 Metric 5

# redistribute EIGRP 1 Metric 3

Either globally or individual protocol – if we do not specify the metric the routes will not be populated into the RIP database

Can verify this with the

#sh RIP database – this will tell us locally on the router that is doing the redistribution whether the process is actually occurring properly.

So if we Redistributed EIGRP into RIP – and we do not see the EIGRP routes as redistributed, then we know there could be an issue with the Metric or the routes are being filtered.

EIGRP Redistribution –

AD of 170 for external EIGRP

-Helps to automatically prevent route feedback.

Used Router-ID for loop prevention

No default seed metric unless EIGRP to EIGRP

#redistribute (protocol) metric (bandwidth) (delay) (load) (reliability) (MTU)

-#default-metric (bandwidth) (delay) (load) (reliability) (MTU)  

EIGRP – does differentiate between internal or External routes.

90 = Internal

170 = External

The idea behind this is if we have an external EIGRP route -

And some other IGP learned route for the same match.

If we learn the route through external EIGRP- this will be the least preferred path.  Because of the AD.

Note: EIGRP uses the router-id value for loop prevention of external prefixes. If our EIGRP Router-ID is 1.2.3.4 – when we redistribute OSPF into EIGRP – the EIGRP External prefixes are going to be tagged with the router-ID of 1.2.3.4 

This then means if the routing update leaves locally and goes out to some of the peers, then comes back in from another EIGRP neighbor – we’re going to discard the route. Any time you learn an external EIGRP route that has your route-id as the originating router the process is automatically going to deny this.

Just like RIP – EIGRP does not have a default seed metric unless we’re going through two spate EIGRP processes. EIGRP AS 1 and EIGRP 2 on same router – the individual composite values will be exchanged on a prefix by prefix basis, Load delay, mtu, etc – will be exchange

However if were coming from another protocol like OSPF into EIGRP.

We do need to manually specify what the seed metric value is.

We can use the redistribution under the process with the Redist protocol or set the default-metric.

There is also cases where if there is only a single point of redistribution – the seed metric value is not going to matter. Because if we have only one physical path form the RIP to EIGRP – it really doesn’t matter what the seed metric is. The Seed metric is really only going to matter when there is multiple points of redistribution and we’re doing traffic engineering or route filtering.

OSPF Redistribution -

AD of 110 for all OSPF routes

Uses router-id for flooding loop prevention

Default seed metric 20 and metric-type E2 / N2

OSPF path selection preference

-E1 > E2 > N1 > N2

-E1 & N1 vs E2 & N2 metrics

Does distinguish between external and internal, all will be assigned an AD of 110. This means OSPF will prefer the AD of 110 over the External EIGRP or RIP AD’s.

Under the routing process on the command line we can manually specify the AD for the External vs internal routes if we want to.

By default OSPF will choose the intra-area routes over the Inter-area routes and over E1 > E2 > N1 > N2

So regardless of metric value, etc – if we have an E1 route VS and N1 (NSSA) route we will always have to choose the E1 route

In OSPF the only time the redist route is going to matter is if we have multiple external matches of the same type prefix – then we use the metric. Ex two E1 routes of two E2 routes.

Does have default see of 20 – and default metric of E2 into a normal area and N2 into an NSSArea. These can be manually changed.

OSPF will use the route-id to prevent routing loops. Although OSPF is not a distance vector protocol.

BGP Redistribution –

Uses ORIGIN code Incomplete.

Normal EBGP and iBGP have no loop prevention

IGP to BGP

-Denies OSPF external routes by default

--- redistribute ospf (Pid) match internal external

BGP to IGP

-EBGP routes allowed, iBGP routes denied by default

-#bgp redistribute – internal

-legacy sysnc rule

-can cause a routing loop

BGP does Distinguishes between internal and external routes in two ways.

First is going to be based on the origin code that is set to incomplete or ? when you look at the #sh ip bgp.

BDP best path selection will prefer routes internal to the network – the ones that are configured under the network statement in the BGP process over the redistributed routes. Origin code for internal is a lower case “i

If all routes being equal – we will look at the origin code – the lower will be preferred IGP over incomplete.

For loop prevention we will use the same rules for normal ibgp and ebgp -

EBGP – uses the AS Path information – ex: if my AS is 100 and I receive a route in that has 100 in the path, then discard the update.

iBGP routes – anytime I learn a prefix from an iBGP neighbor, we will simply not advertise that prefix to another iBGP neighbor – unless I am a route reflector.

iGP to BGP – this is the normal way to advertise our internal prefixes to the global BGP network.  Ex: if we have a bunch of OSPF routes that we want to advertise into BGP, we can either use the network statement under the process  or just redistribute OSPF into BGP

The only exception for this by default the BGP process is going to deny the external OSPF routes. The logic is that if the route is external OSPF – it means that it came from some other protocol to begin with.

This only applies to OSPF – if we’re redistributing EIGRP – it will allow both the Internal or External routes to go.

Now going from BGP to IGP – in order to prevent loops inside our own internal ibgp network, we’re only going to allow external routes from BGP to OSPF or BGP to EIGRP.