From: Todd Veillette (tveillette@xxxxxxxx)
Date: Sat May 26 2001 - 23:32:56 GMT-3
In real world I would think a static or default route would be preferred to
a stub, less cpu. Policy routing is for decision based routing. There are no
decisions to make to/from a stub. Trying to conserve the routers resources
should always be a major concern in design, especially now when companies
can't afford upgrades. I will only use policy routing/maps as a last resort.
Todd
----- Original Message -----
From: "sanjay" <ccienxtyear@hotmail.com>
To: <ccielab@groupstudy.com>
Sent: Saturday, May 26, 2001 9:14 PM
Subject: Local Policy routing -alternative solution to using static routes
> Local Policy Routing works great in situations where you are not allowed
to
> use static or default routes. But it all depends on your network topolgy.
I
> think the best practice of using local policy routing is when there is
only
> one path to a router (something like a stub network) on an OSPF network. I
> have 4 routers accross a frame cloud, all running OSPF and in Area 0. I
have
> another router attached via PPP serial connection to one of the OSPF
routers.
> After doing redistribution, of course some routers weren't able to ping
the
> IGRP router (different masks). I set up local policy routing and set the
nex
> hop address to point to the OSPF router to which it is connected via
Serial.
> This works great. I can ping everything out on the OSPF network from the
IGRP
> router and vice versa. So the moral of this story is, from my opinion,
local
> policy routing works great if you only have one path to a router.?? Any
> thoughts from anyone ???
>
> Thanks to the person who recommend local policy routing as another
solution to
> the damn redistribution issues between classfull and classless routing
> procotocls where using static routes is a Taboo.
>
> later,
> Sanjay
> **Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:30:54 GMT-3