Monday, November 7, 2011

Redistribution / Using multiple Routing protocols

Reason for redistribution?
  • Mergers when different internal gateway protocols (IGPs) are used.
  • Mergers when the same IGP is used. (Example: Two companies both use EIGRP, but different AS numbers.  Redistribution is a useful immediate fix, until all former company's routers are migrated to use the same ASN as the first company.)
  • Momentum (Enterprise has been using multiple routing protocols a long time.)
  • Connections between partners
How does it work?
Because the topology tables (map of the network) may vary between different routing protocols, the redistribution process uses the one table that both routing protocols understand: the IP routing table.  By performing the redistribution commands, you are essentially pulling routes from one routing protocol, and putting them into another.  Like EIGRP, OSPF treats the redistributed routes as external routes.  OSPF creates an LSA to represent each redistributed subnet - normally a Type 5 LSA (See my OSPF section for information of LSA types).  Also, aside from passing routes learned via the routing protocol, the redistribution command also passes information on connected routes on interfaces enabled with that routing protocol. 

Redistribution into EIGRP:
Syntax: redistribute <protocol> <process id / as-number> <metric> <match> <tag> <route-map (value)>
How do you put routing protocol X into EIGRP?  You would first go under the EIGRP routing protocol, via the router eigrp <process id> and then perform the above command.  A better command name might have been "take-routes-from," because the first parameter after the command tells IOS from where to get the routes. 
Things to remember:
EIGRP does not have a default setting for the metric components to use when redistributing into EIGRP from OSPF.  To successfully redistribute OSPF routes into EIGRP, you need to use the metric <bw delay reliability load mtu> in conjunction with the redistribute command to redistribute all routes by a single redistribute command.  You can use the same synax, but use default-metric <bw delay reliability load mtu> to set the default for all redistribute commands. 

Redistribution into OSPF:
Like redistributing into EIGRP, OSPF flags redistributed routes as external.  Unlike EIGRP, OSPF creates LSAs to represent each external route.  By default, the OSPF redistribute command creates Type 2 routes. 
Syntax: redistribute <protocol> <process id / as-number> <metric> <match> <tag> <route-map (value) <subnets>
The main difference one might notice about the syntax, is with regards to the <subnets> portion.  By default, when redistributing into OSPF, it only redistributes classful (class A, B, and C) networks, and not routes for subnets.  By omitting the subnets parameter, OSPF will only redistribute routes for entire classful subnets, and only if such a route is listed in the IP routing table.  For example, if no route exists for the EXACT class B network prefix of 172.30.0.0/16, OSPF will not redistribute any subnets inside that range.  By including the subnets prefix, it would redistribute the subnets. 
Dealing with the external routes...
When the external route is created, the ASBR floods the Type 5 LSA throughout the area.  Then, if any ABRs exist, the ABRs flood the Type 5 LSA into any normal (nonstubby) areas.  Because the Type 5 LSA is defaulted to a Type 2 route (E2), the route's metric is simply the metric listed in the Type 5 LSA.  While this makes cost calculations easy, it makes it difficult to calculate the best path.  For example, if you have 2 possible routes, with one being the obvious winner and one requiring multiple hops, the cost for both routes would be the same, as they are both external.  When a router finds multiple routes for the same E2 destination subnet, it chooses the best route based on the lowest cost to reach any ASBR(s) that advertised the lowest E2 metric.  The method for choosing the best route is as follows:
1. Find the advertising ASBR(s) as listed in the type 5 LSA(s) for Type 5 LSA(s).
2. Calculate the lowest cost route to reach any of the ASBR(s) based on the intra-area LSDB topology.
3 Use the outgoing interface and net hop based on the best route to reach the ASBR.
4. The route's metric is unchanged--it is still simply the value listed in the Type 5 LSA. 

Now what if the router exists in a different area than the ASBR?  If a router finds multiple routes to reach a single E2 subnet, some or all may tie based on metric, because the metric is based solely on the external cost as defined by the ASBR.  A router then chooses the best route based on the least-cost route to reach an ASBR that has advertised the lowest E2 cost for the subnet.   
The steps are as follows:
1. Calculate the cost to reach the ABR, based on the local area's topology database.
2. Add the cost from the ABR to the ASBR, as listed in a Type 4 LSA.
ABRs create this new type of LSA -- The Type 4 LSA -- to support the logic mentioned in step 2.  The Type 4 LSA lists the RID of the ASBR, and the RID of the ABR that created and flooded the Type 4 LSA.  Most importantly, the Type 4 LSA lists that ABR's cost to reach the ASBR. 

E2 routes work well when the design needs to choose the best route based on the external metric.  OSPF routers calculate the metric of E1 routes by adding the internal cost to reach the ASBR to the external cost defined on the redistributing ASBR.  One can influence the route-type by using the metric-type 1 value in the redistribution command.  For routers in a different area than the ASBR, the calculation of metric follows the same general logic used when breaking E2 routes.  Generally, the computation adds three items:
  • The best intra-area cost to reach the ABR (per that area's LSDB)
  • The cost from the ABR to the ASBR (Per Type 4 LSA)
  • The external cost for the route (Per Type 5 LSA)
So how are E1 & E2 routes different?!  Well, for E1 routes, both the external cost and internal OSPF cost matters to the choice of best routes.  For E2 routes, only the external cost matters to the choice of best route...unless a tie needs to be broken!  Also, it should be mentioned that for a given prefix / length, OSPF always prefers an E1 route over an E2 route. 

How does redistribution work if using NSSA areas?!
Being that you cannot redistribute routes into stubby or totally stubby areas (don't allow type 5 LSAs), you can redistribute into Not-so-stubby-areas (NSSAs). 









Using the above example, the ASBR attached to the NSSA area 1 redistributes a route for subnet 1, creating a Type 7 LSA.  The ASBR then proceeds to flood the Type 7 LSA throughout NSSA area 1.  When ABR1 receives the Type 7 LSA, it converts it to a Type 5 LSA when forwarding into other areas! 

And then things get real...
First off, lets take a look at the administrative distance table:


Administrative Distance (AD) is the measure used by Cisco routers to select the best path to a destination when there are more than one route to the same destination from two different routing protocols.  By default, you would prefer the path that has the lowest administrative distance.  For example: If you know a route to subnet 10.16.1.0 through both (internal) EIGRP and OSPF, you would prefer the EIGRP route (assuming default AD settings).  These administrative distance costs can be changed / adjusted so to make one path preferred over another.






Issue that can happen with redistribution:

Given the following example, you have two routers performing redistribution, which is considered to be the minimum in regards to redistribution design.  Because we have two distribution routers, routing loops can occur.  As seen in the image, Subnet X is advertised to RD2 as both an internal EIGRP as well as an external OSPF route.  With regards to redistributing between EIGRP and OSPF, the default AD settings as mentioned above prevent said loops.  When RD2 considers the internal EIGRP route as the best route, because of the lower AD, and places that route in its own IP routing table.  RD2 does not further mess it up by redistributing subnet x BACK into EIGRP because RD2 does not have an OSPF route for subnet X..wew! 

What about when its reversed?  Given the same example, but with a subnet Y being advertised from within the OSPF domain?  EIGRPs default AD saves us again!  Subnet X would work the same was as the example above, and when subnet Y works its way around...RD1 would prefer the route from OSPF over the external EIGRP route!  The default AD for an external EIGRP route is 170, which is obviously higher than the internal OSPF AD of 110..wew!

Time for things to get messed up...RIP!
Because RIP does not have a concept of internal and external routes; the proceding references refer to internal routes as routes that exisite inside the RIP domain, and external as routes that exist outside the RIP domain.  Because RIP does not have a default AD setting to defeat the domain loop problem, the different routing protocols have the ability to override the default AD.
To change the default AD values..
RIP: distance <ad-value>
EIGRP: distance eigrp <internal-ad external-ad>
OSPF: distance eigrp (external) <ad-value> (intra-area) <value> (inter-area) <value>

To defeat the OSPF-RIP domain loop problem by setting AD, just configure the AD for OSPF external routes.  The AD value doesn't matter much, but it should be higher than RIP's AD on that same router. 

Yay, we solved domain loops!!...wait a second..

Check this out..

With the given example, R9 advertises a route for 172.20.0.0/16 into the EIGRP domain with an AD of 170 as an external route.  RD1 redistributes this EIGRP external route into the OSPF domain as a E2 external route, with an AD of 110, by default.  RD2 uses the AD 110 E2 route, rather than the EIGRP external route, as its best route for 172.20.0.0/16.  As a result, RD2 can then redistribute that OSPF route back into EIGRP as an external route.  R4 learns of two external routes for 172.20.0.0/16, and the routes tie based on RD (170).  R4 may have a better EIGRP metric through RD2, depending ont he metrics used in redistribution, preferring this long route through the OSPF domain as shown.

How could we solve an issue like this?  One solution would be to cause RD2 to use a higher AD--specifically higher than the 170 AD used for EIGRP external routes--for prefix 172.20.0.0/16 as learned with OSPF.  To do this, we can use an access list to match the 172.20.0.0/16 prefix!

RD2(config)# router ospf 2
RD2(config-router)# distance 171 1.1.1.1 0.0.0.0 match-172-20
RD2(config-router)# ip access-list standard match-172-20
RD2(config-std-nacl)# permit host 172.20.0.0

What we essentially did, was tell OSPF to look for LSAs owned by RID 1.1.1.1 (RD1's RID), and if the prefix is permited by the match-172-20 ACL, apply AD 171 to this route.  So instead of preferring the external OSPF value of 110, it is made to believe that R1 is advertising a cost of 171 to reach 172.20.0.0/16.  Because the AD is increased, RD1 now prefers its AD 170 EIGRP route for 172.20.0.0/16.

Worth noting..when using the distance command with RIP or EIGRP, the distance matches the interface IP address of the neighboring router that advertises the route. 

Preventing Domain Loops by Filtering on route-tag Using Distribution Lists
A route tags is a unitless 32-bit integer that most routing protocols can assign to any given route.  Route tags can be assigned by a route-map referenced by a routing protocol distribution list or redistribute command.  The route tag allows other IOS tools to match routes to make a decision.  It is essentially the equivalent of a post it note on a route.  Using the figure above as an example, we could tag traffic coming into RD1, while denying the tagged traffic incoming into RD2 through the use of route-maps, while permitting everything else.  The configuration to accomplish something like that...

R1:
router ospf 2
router-id 3.3.3.3
log-adjacency-changes
redistribute eigrp 1 subnets route-map set-tag-11
network 172.30.0.0 0.0.255.255 area 0
roure-map set-tag-11 permit 10
set tag 11

R2:
Router eigrp 1
redistribute ospf 2 metric 1000 200 255 1 1500 route-map stop-tag-11
network 172.16.0.0
no auto summary
route-map stop-tag-11 deny 10
match tag 11
route-map stop-tag-11 permit 20

No comments:

Post a Comment