From: Howard C. Berkowitz (hcb@xxxxxxxxxxxx)
Date: Mon Apr 08 2002 - 11:14:50 GMT-3
At 9:42 AM -0400 4/8/02, Lupi, Guy wrote:
>One of your points was below:
>
>OSPF default-information originate doesn't fit the bill, because I
>have two redistribution points. If I had one redistribution point, I
>could, in good conscience, do default-information originate always,
>because the traffic would blackhole. But with two points of
>redistribution, I want default originated only if the point of
>redistribution indeed can act as a default router.
>
>You stated that you solved the issue with conditional default advertisement
>in BGP, OSPF can also do conditional advertisement of defaults. So if you
>had 2 OSPF routers, and you only wanted a default originated if it could act
>as a default, you could configure them to advertise a default only if they
>have a specified route in the table that indicates connectivity with the
>rest of the network. With the following:
Thank you, Guy. It sounds like you've dug into default information
originate even more deeply than I have. My focus usually has been on
the policy implications of the command: using it with E1 defaults
(with identical metrics) at multiple points to effect load sharing,
using it with E2 defaults to give a primary/secondary backup.
I had always thought that having it operate without "always" required
that the originating router specifically had a valid 0.0.0.0/0 route,
not simply generic connectivity to other routers. That still may be
true of the basic command, but with the route map you have added,
that may be a valid workaround.
I did find a way to get the effect I wanted, but it is somewhat ugly!
In the next few days, I will be posting some other observations,
questions, etc., from the viewpoint of a scenario designer, and I
encourage everyone, including scenario vendors, to discuss these
things constructively. While I can't say it will always give people
insight into the proctor's mind, I think it is useful to have some
idea of the process someone goes through in designing a lab scenario.
>
>r5#
>router ospf 100
> log-adjacency-changes
> area 1 authentication message-digest
> area 1 virtual-link 140.4.3.3 authentication message-digest
> area 1 virtual-link 140.4.3.3 message-digest-key 1 md5 cisco
> redistribute eigrp 102 subnets route-map eigrp2ospf
> network 140.4.1.0 0.0.0.255 area 1
> network 140.4.2.0 0.0.0.255 area 1
> network 140.4.22.0 0.0.0.255 area 20
> neighbor 140.4.1.3 priority 200
> default-information originate route-map defaultoriginate
>!
>route-map defaultoriginate permit 10
> match ip address prefix-list defaultoriginate
> match ip next-hop 3
>!
>access-list 3 permit 172.16.0.4
>!
>ip prefix-list defaultoriginate seq 5 permit 192.168.6.0/24
>
>This configuration tells r5 to originate a default route only if it has a
>route for 192.168.6.0/24 via 172.16.0.4 in the routing table.
>
>
>r5#sh ip route
>
>D EX 192.168.6.0/24 [170/2251264] via 172.16.0.4, 20:48:50, Serial1
>
>Now, going to r6, it has a default route from r5:
>
>r6#sh ip route
>
>O*E2 0.0.0.0/0 [110/1] via 140.4.1.2, 00:00:52, Serial0
>
>Now I have stopped r5 from receiving the route 192.168.6.0/24 via a
>distribute list on the upstream router.
>
>r5#sh ip route
>
>
>r5(r2)#sh ip route
>Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
> D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
> N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
> E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
> i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter
>area
> * - candidate default, U - per-user static route, o - ODR
> P - periodic downloaded static route
>
>Gateway of last resort is not set
>
> 1.0.0.0/24 is subnetted, 1 subnets
>B 1.1.1.0 [20/0] via 192.168.2.1, 18:53:44
> 140.4.0.0/16 is variably subnetted, 14 subnets, 4 masks
>O 140.4.8.0/24 [110/66] via 140.4.1.3, 16:17:32, Serial0
>O 140.4.9.0/24 [110/66] via 140.4.1.3, 16:17:32, Serial0
>C 140.4.1.0/28 is directly connected, Serial0
>C 140.4.2.0/24 is directly connected, Loopback0
>O 140.4.3.0/24 [110/65] via 140.4.1.3, 16:17:32, Serial0
>O 140.4.4.0/25 [110/65] via 140.4.1.3, 16:17:32, Serial0
>O IA 140.4.5.0/24 [110/10065] via 140.4.1.3, 16:17:33, Serial0
>O 140.4.6.0/24 [110/65] via 140.4.1.3, 16:17:33, Serial0
>O IA 140.4.28.0/30 [110/20063] via 140.4.1.3, 16:17:33, Serial0
>O IA 140.4.28.0/24 [110/10064] via 140.4.1.3, 16:17:33, Serial0
>C 140.4.22.0/24 is directly connected, Loopback1
>O IA 140.4.33.0/24 [110/70] via 140.4.1.3, 16:17:33, Serial0
>C 140.4.55.0/24 is directly connected, Virtual-TokenRing1
>O E2 140.4.87.0/24 [110/20] via 140.4.1.3, 16:17:33, Serial0
> 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
>D 172.16.0.0/21 [90/2297856] via 172.16.0.4, 21:52:56, Serial1
>C 172.16.0.0/24 is directly connected, Serial1
> 130.1.0.0/24 is subnetted, 2 subnets
>C 130.1.20.0 is directly connected, Ethernet0
>C 130.1.85.0 is directly connected, Tunnel0
> 10.0.0.0/24 is subnetted, 2 subnets
>B 10.10.10.0 [20/0] via 192.168.2.1, 18:53:46
>B 10.10.77.0 [20/0] via 140.4.87.7, 00:02:03
>B 192.168.0.0/24 [20/0] via 192.168.2.1, 18:53:46
>D EX 192.168.2.0/24 [170/2251264] via 172.16.0.4, 20:53:00, Serial1
>r5(r2)#
>
>R5 has now stopped advertising the default route to the network because the
>route it is dependent on is no longer in the routing table.
>
>r6(r3)#sh ip route
>Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
> D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
> N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
> E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
> i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate
>default
> U - per-user static route, o - ODR
>
>Gateway of last resort is not set
>
> 140.4.0.0/16 is variably subnetted, 14 subnets, 4 masks
>O 140.4.8.0/24 [110/2] via 140.4.4.6, 16:17:18, Ethernet0
>O 140.4.9.0/24 [110/2] via 140.4.4.13, 16:17:18, Ethernet0
>C 140.4.1.0/28 is directly connected, Serial0
>O 140.4.2.0/24 [110/65] via 140.4.1.2, 17:02:55, Serial0
>C 140.4.3.0/24 is directly connected, Loopback0
>C 140.4.4.0/25 is directly connected, Ethernet0
>O IA 140.4.5.0/24 [110/10001] via 140.4.4.6, 16:17:18, Ethernet0
>C 140.4.6.0/24 is directly connected, Loopback99
>O IA 140.4.28.0/30 [110/19999] via 140.4.4.6, 16:17:18, Ethernet0
>O IA 140.4.28.0/24 [110/10000] via 140.4.4.6, 16:17:19, Ethernet0
>O IA 140.4.22.0/24 [110/65] via 140.4.1.2, 16:17:19, Serial0
>C 140.4.33.0/24 is directly connected, TokenRing0
>O IA 140.4.55.0/24 [110/10010] via 140.4.4.6, 16:17:19, Ethernet0
>O E2 140.4.87.0/24 [110/20] via 140.4.4.6, 16:17:19, Ethernet0
> 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
>O E2 172.16.0.0/24 [110/20] via 140.4.1.2, 16:17:19, Serial0
>O E2 172.16.0.0/21 [110/20] via 140.4.1.2, 16:17:19, Serial0
>O E2 192.168.2.0/24 [110/20] via 140.4.1.2, 16:17:19, Serial0
>r6(r3)#
>
>I hope this helps, if I understand the scenario correctly it should.
>
>Guy
>
>
>-----Original Message-----
>From: Howard C. Berkowitz [mailto:hcb@gettcomm.com]
>Sent: Sunday, April 07, 2002 8:24 PM
>To: ccielab@groupstudy.com
>Subject: Statics, defaults, and the lab
>
>
>I've been working on a practice scenario, involving, among many other
>things, RIP-OSPF mutual redistribution. My challenge is that I wanted
>to do something that is real-world good practice: standardizing on
>loop0 interface addresses that are /32, postulating the customer
>would eventually transition completely to OSPF.
>
>The challenge is how to ping discontiguous /32's in a RIP network. In
>principle, it's not something RIPv1 can do. If this were the real
>world, I could solve this trivially with a couple of static and
>default routes. I can make it work under some fairly bizarre
>constraints, like using extended ping to force a source address to
>which has a return path.
>
>To do what I want to do with routing, however, the alternatives are
>so bizarre that I wonder if it's beyond what conceivably could be on
>the test. Now, this is NOT a request for NDA information, but it's
>my impression from Solie and various CCIE power sessions that the lab
>scenarios NEVER use static or default routes. Am I correct here, or
>is "NEVER" really "HARDLY EVER"?
>
>Let's see...some of the ways I've hacked it:
>
> 1. Implement policy routing and set default interface.
> 2. Use BGP as an intermediate protocol between RIP and OSPF so I
>can use conditional default advertisement
>
>OSPF default-information originate doesn't fit the bill, because I
>have two redistribution points. If I had one redistribution point, I
>could, in good conscience, do default-information originate always,
>because the traffic would blackhole. But with two points of
>redistribution, I want default originated only if the point of
>redistribution indeed can act as a default router.
>
>BGP conditional advertisement would do what I want. If I could put a
>default route into the OSPF router, and control default origination
>by the reachability of the next hop of the default route, I could
>also make it work. The OSPF router really wouldn't use the default
>route other than as a control mechanism for default information
>originate.
>
>Am I simply creating a situation that is outside the reasonable scope
>of the lab?
>
>This scenario and others, incidentally, will be available for free
>noncommercial use from Gettlabs, but we need to work out some server
>issues that I hope will be done in the next couple of days. It's too
>long to post here.
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:57:59 GMT-3