From: Chuck Larrieu (chuck@xxxxxxxxxxxxx)
Date: Sat Mar 03 2001 - 02:02:00 GMT-3
Yes indeed, a very interesting thread.
As I said, this is a trick question. My thanks to everyone who played, both
on line and privately. I sure learned a lot.
Given the following information, which route will ospf prefer, and therefore
place into the routing table?
>
> a) E1 ( external type 1 ) with a cost of 84
> b) E2 ( external type 2 ) with a cost of 20
>
> For extra credit - why?
The answer is A) external type-1 routes are always preferred to external
type-2 routes. Why? Because. Well, it states so in the RFC, and there is an
explanation in RFC2328 on pages 23 and 24 ( and some other pages reference
this as well )
ftp://ftp.isi.edu/in-notes/rfc2328.txt
I also received an interesting commentary from Erick, about RFC 2178 versus
RFC 2328 compliance in router vendor code. This stuff is indeed complex, and
there are a lot of ways one can be tricked by what one sees and how the
protocol behaves. Yes, the cost of the E1 routes in my setup is higher than
the cost of the E2 routes. Still they are preferred. Whatever sources you
have that say that E1 routes are preferred because they have a lower cost
are wrong. The traces below demonstrate that.
This leads to my usual rant about the reliability of sources. These days
there are a lot of publishers trying to cash in on the certification
bonanza. They rush books to press written by folks who may not understand
what they are writing about, and reviewed in a cursory manner by folks who
are rushed to return the work for printing. We all know there are a lot of
errors in a lot of the books. You just can't take the word of one source
over any others. The RFC's are the source of goodness and light. T of these
"rush job" publications are to be avoided.
Something Howard used to talk about on the other list. Hot potato versus
cold potato routing. I believe the reason the E1 routes are preferred to E2
routes is that an E1 route contains within it the actual cost to the ASBR.
Traffic destined for external networks will follow the optimum path. E2
route costs do not change as they propagate through an OSPF domain.
Therefore traffic to external networks may take a suboptimal path to the
egress. Even though the cost is higher, the E1 route can be for more
effective in routing traffic through the OSPF domain.
I know Tom Thomas sometimes monitors this list. Wouldn't it be great if he
could chime in on this topic?
I promised some traces. Let's start with the E2 routes in the table,
followed by a debug ip routing trace, which shows the E1 routes replacing
the E2 routes. Last is the subsequent routing table.
Gateway of last resort is not set
20.0.0.0/8 is variably subnetted, 8 subnets, 5 masks
O E2 20.254.254.0/24 [110/20] via 10.10.3.3, 00:00:27, Serial0.2
O E2 20.253.253.0/30 [110/20] via 10.10.3.3, 00:00:27, Serial0.2
O E2 20.6.6.0/24 [110/20] via 10.10.3.3, 00:00:27, Serial0.2
O E2 20.253.253.2/32 [110/20] via 10.10.3.3, 00:00:27, Serial0.2
O E2 20.50.0.0/17 [110/20] via 10.10.3.3, 00:00:27, Serial0.2
O E2 20.40.40.32/27 [110/20] via 10.10.3.3, 00:00:27, Serial0.2
O E2 20.40.40.64/27 [110/20] via 10.10.3.3, 00:00:27, Serial0.2
O E2 20.50.128.0/17 [110/20] via 10.10.3.3, 00:00:27, Serial0.2
10.0.0.0/8 is variably subnetted, 7 subnets, 4 masks
C 10.10.2.0/24 is directly connected, Serial0.1
C 10.10.3.0/24 is directly connected, Serial0.2
C 10.10.5.0/24 is directly connected, Serial0.3
O IA 10.3.0.0/16 [110/74] via 10.10.3.3, 00:00:28, Serial0.2
C 10.1.0.0/16 is directly connected, Ethernet0
O IA 10.202.0.0/20 [110/74] via 10.10.2.2, 00:00:36, Serial0.1
O IA 10.202.16.2/32 [110/65] via 10.10.2.2, 00:00:36, Serial0.1
1d22h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed
state to
up
1d22h: RT: del 20.6.6.0/24 via 10.10.3.3, ospf metric [110/20]
1d22h: RT: add 20.6.6.0/24 via 20.253.253.6, ospf metric [110/84]
1d22h: RT: del 20.40.40.32/27 via 10.10.3.3, ospf metric [110/20]
1d22h: RT: add 20.40.40.32/27 via 20.253.253.6, ospf metric [110/84]
1d22h: RT: del 20.40.40.64/27 via 10.10.3.3, ospf metric [110/20]
1d22h: RT: add 20.40.40.64/27 via 20.253.253.6, ospf metric [110/84]
1d22h: RT: del 20.50.0.0/17 via 10.10.3.3, ospf metric [110/20]
1d22h: RT: add 20.50.0.0/17 via 20.253.253.6, ospf metric [110/84]
1d22h: RT: del 20.50.128.0/17 via 10.10.3.3, ospf metric [110/20]
1d22h: RT: add 20.50.128.0/17 via 20.253.253.6, ospf metric [110/84]
1d22h: RT: del 20.253.253.0/30 via 10.10.3.3, ospf metric [110/20]
1d22h: RT: add 20.253.253.0/30 via 20.253.253.6, ospf metric [110/84]
1d22h: RT: add 20.253.253.1/32 via 20.253.253.6, ospf metric [110/84]
1d22h: RT: del 20.254.254.0/24 via 10.10.3.3, ospf metric [110/20]
1d22h: RT: add 20.254.254.0/24 via 20.253.253.6, ospf metric [110/84]
Gateway of last resort is not set
20.0.0.0/8 is variably subnetted, 10 subnets, 5 masks
C 20.253.253.4/30 is directly connected, Serial1
O E1 20.254.254.0/24 [110/84] via 20.253.253.6, 00:00:50, Serial1
O E1 20.253.253.0/30 [110/84] via 20.253.253.6, 00:00:50, Serial1
O E1 20.6.6.0/24 [110/84] via 20.253.253.6, 00:00:50, Serial1
O E1 20.253.253.1/32 [110/84] via 20.253.253.6, 00:00:50, Serial1
O E2 20.253.253.2/32 [110/20] via 10.10.3.3, 00:00:50, Serial0.2
O E1 20.50.0.0/17 [110/84] via 20.253.253.6, 00:00:50, Serial1
O E1 20.40.40.32/27 [110/84] via 20.253.253.6, 00:00:50, Serial1
O E1 20.40.40.64/27 [110/84] via 20.253.253.6, 00:00:50, Serial1
O E1 20.50.128.0/17 [110/84] via 20.253.253.6, 00:00:51, Serial1
10.0.0.0/8 is variably subnetted, 7 subnets, 4 masks
C 10.10.2.0/24 is directly connected, Serial0.1
C 10.10.3.0/24 is directly connected, Serial0.2
C 10.10.5.0/24 is directly connected, Serial0.3
O IA 10.3.0.0/16 [110/74] via 10.10.3.3, 00:00:52, Serial0.2
C 10.1.0.0/16 is directly connected, Ethernet0
O IA 10.202.0.0/20 [110/74] via 10.10.2.2, 00:00:52, Serial0.1
O IA 10.202.16.2/32 [110/65] via 10.10.2.2, 00:00:52, Serial0.1
So let's see. If the lab were to ask you to redistribute routes into ospf
such that they would be preferred, you would do that how? ;->
Thanks again, everyone.
Chuck
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:29:19 GMT-3