Eric Stewart: Running Off At The Mouth

CCIE Studies: OSPF E1 vs E2 For Dummies

by Eric Stewart on Mar.14, 2015, under Networking, Technology

First, if you’re reading this, I’m hoping you have at least some basic idea of OSPF and route redistribution between OSPF and other routing protocols.  Second, this page is really going to be an attempt to restate what I pulled from a more technically written article that has a really nice example I put into GNS3 and followed along with to figure it all out.  Indeed, some of what you might find in this post will refer to this example and might even include command results copied from following along in that lab.

So, What Are The E1 And E2 Routes?

They are, in OSPF speak, external routes – either “Type 1” or “Type 2”.  Routes that have been redistributed somehow into OSPF (in a Not-So-Stubby-Area, they start out as N1 and N2 routes).  Most redistribution, by default, uses the “Type 2” route, but you can specify that the redistributed routes be “Type 1” if you want.

So What’s The Difference?

The textbook answer?  E1 routes contain path metric information, and E2 routes do not.  If a route reaches a router from two sources and it’s E1 from one and E2 from the other, it will prefer (regardless of the metric difference) the E1 route.

So What Does That Really Mean?

If you have an ASBR or two redistributing E2 routes into an OSPF autonomous system (not just an area, but the whole AS), every router that gets the route will see the route with whatever metric you configured for it on the ASBR.

If the ASBR(s) redistribute the routes as E1 routes, each router in the OSPF AS will show, for a given route, a metric that includes the metric computed for the path to the distributing ASBR as well as the metric configured on the ASBR for the route.

It would be logical, then, for an E1 route to be preferred, since it’s providing to the router a more accurate representation of the best path to the destination.

Is It Really That Simple?

No.

E2 routes do actually contain path information.  And as far as my lab of the example noted at the beginning of the article, it’s used as a tie breaker.  But only as a tie breaker: if the the E2 route is coming in from through two different paths sourced by two different ASBRs, and one ASBR advertises it with a lower metric than the other, even if the path metric added to the route metric would be larger than the other path, it will put the route with the lower route metric in the routing table.  A quick and dirty note with some numbers – RM+PM from ASBR1: 2+100 and ASBR2: 3+5, indicating that the path to ASBR2 is faster, ASBR1’s route will be installed into the routing table because the route metric is lower.

And if the path metric is equal and the route metric is equal?  Equal cost load balancing.

Some Command Output

Now, you should really lab this up yourself and go through Brian McGahan’s article on iNE to get a better understanding of the situation.  There’s a lot of information there and doing it yourself will help you greatly.  But for my purposes in this, here’s what you need to see.

First, at the router trying to get to a particular destination, with the routes being redistributed as E1 routes, here’s a simple “show ip route 10.1.6.0”:

R1#show ip route 10.1.6.0
Routing entry for 10.1.6.0/24
  Known via "ospf 1", distance 110, metric 3, type extern 1
  Last update from 10.1.13.3 on FastEthernet0/3, 00:00:04 ago
  Routing Descriptor Blocks:
  * 10.1.13.3, from 10.1.5.5, 00:00:04 ago, via FastEthernet0/3
      Route metric is 3, traffic share count is 1

So you see the “metric” and “route metric” are the same.  And you’re even told what type of route it is.  But here’s the same route converted to an E2 route:

R1#show ip route 10.1.6.0
Routing entry for 10.1.6.0/24
  Known via "ospf 1", distance 110, metric 1, type extern 2, forward metric 2
  Last update from 10.1.13.3 on FastEthernet0/3, 00:00:03 ago
  Routing Descriptor Blocks:
  * 10.1.13.3, from 10.1.5.5, 00:00:03 ago, via FastEthernet0/3
      Route metric is 1, traffic share count is 1

There are some important differences.  The metric/route metric is now 1 – that’s because the two hops from the source are now not considered – this is how type 2 routes work.  But the key here is the presence of the “forward metric” – this is the “path metric”.  The other important note here is that if you play with the numbers, with an E2 route from two sources, the forward metric is only taken into account when the route metric is the same.  In fact, you could have one route with a route metric of 10, the other with a route metric of 1 … and correspondingly, a forward metric of 2 and a forward metric of 1000, the path with the route metric of 1 will be installed.  But if you converted the routes to E1, then obviously the route metrics would be 12 and 1001, and the first route would be installed in the routing table.

Why Would You Choose E2 Over E1 Then?

Well, I guess I get to talk out of my ass for a bit.

If you have only one point of redistribution, it doesn’t matter – there’s only one ASBR, one metric, and the other OSPF routers in the AS will fall back to using the forward metric and you’d end up with probably the same results anyway.

But, say you have routes coming into your network from two locations and you want, no matter what, the routes only going through the “B” router if the “A” router is down (or isn’t getting the routes to redistribute them for some reason), even if the traffic starts close to the “B” router, then you advertise the route from “A” with a lower metric than you advertise it from “B”.

That’s Pretty Much It

Is there something about this on the CCIE exam?  Probably not.  In fact, if you’re working on your CCNA or CCNP, and the question comes up, just recite the textbook answer: E2 routes contain no path metric information.

But if you want to know the dirty details, this should get you started … now head over to Brian’s article and do the lab!

:, , ,

Hi! Did you get all the way down here and not find an answer to your question? The two preferred options for contacting me are:
  • Twitter: Just start your Twitter message with @BotFodder and I'll respond to it when I see it.
  • Reply to the post: Register (if you haven't already) on the site, submit your question as a comment to the blog post, and I'll reply as a comment.

Leave a Reply

You must be logged in to post a comment.