Kent,
You are fighting muscle memory here - believe me with some experience you
will see the JUNOS policy structure is quite intuitive and a great deal more
flexible than Cisco. For example, in Cisco, when you do redistribution, it
applies at the global level, and can only pass through one route-map. JUNOS
allows you to configure different policies that do different things and
chain them together. For example, you can have a policy that sets a
community string for a POP, and then another that sets community for certain
static customers. So long as the policy is written to complete and seek the
next policy, then you can chain them together to have them set _both_
policies.
>
> Yes I am from cisco background, well who isnt? :-)
> Not that my IQ does not allow me to understand this, but I am
> not seeing
> anything wrong with cisco redistribution command. To juniper,
> the import and
> export policy both used for filter routes within the protocol
> and during
> redistribution. The former applyes to routes already exist,
> you just apply
> the filters, but in the redistribustion, you do not have any
> routes from one
> protocol to another. The nature logical thoughout is:
Policy import and export is done from the perspective of the routing table.
You export routes from the routing table to the RIB/LSDB of the protocol,
and you import from the RIB into the routing table.
So, you have BGP routes in the table. You can export them from the table to
the IS-IS LSDB (as external or extended IP reachibility TLVs). In cisco,
you have the redistribute command - in Juniper you have export. In Cisco
you have route-maps that define import policy. In Juniper, you have import
policy. There is no
route-map/prefix-list/filter-list/unsuppress-map/suppress-map/distribute-lis
t confusion. You create policy that does filtering, as-path manipulation,
community manipulation, route-leaking between levels, metric setting, etc.
in one place. In Cisco, you have a BGP peer, you have access-lists,
filter-lists, route-maps, as-path access-lists, prefix-lists,
coommunity-lists, etc. Choose your poison.
> 1) there is an export policy configured under this protocol,
> for example,
> ISIS, this should apply to routes being advertised from
> routing table to
> ISIS, as by default, all routes are being propogated from
> routing table to
> protocol, so I just apply the policy to the routes;
>
> 2) looking at policy, it says match from bgp to ISIS, hem?
> What routes can I
> match by this policy? nothing. Because, the routing table by
> default does
> not advertise routes from bgp to ISIS.
You have told it to by defining an export policy. In IS-IS (and all routing
protocols in JUNOS) the protocols export the routes in the table that were
imported from thatr protocol alone. This has nothing to do with LSP/LSA
flooding, which are done independently of the routing table. But when you
want to export something from one protocol to another, you define export
policy that has match and set conditions. Envision it like this:
In Cisco, you can redistribute from one protocol to another. So, you have:
router bgp
redistribute isis route-map isis-to-bgp
!
route-map isis-to-bgp permit 10
set metric 10
!
In Juniper, you have
protocols {
bgp {
export isis-to-bgp;
}
}
policy-options {
policy-statement isis-to-bgp {
from protocl bgp;
}
then {
metric 10;
accept;
}
}
The only difference here is that in cisco, the redistribute command has a
protocol option after it. In essence, 'redistribute isis' is the same as
'export from protocol isis'.
>
> I will have to call this confusion.
> As Juniper is standing on the shoulder of cisco, (how many
> former cisco
> employees they have?), I can see JUNOS definitely is way
> better than IOS
> from the bottom of the structure and many other aspects(I
> believe cisco had
> this embeded style in early age), but the way they define
> redisditribution
> this isnot clever at all.
I thought the same thing - at first - now I think it is quite clever in
fact. Now, there needs to be some better debugging, but that will come (I
hope).
chris
>
> Thanks.
>
> Kent
>
> ----- Original Message ----- hg
> From: "Jeff Aitken" <jaitken@aitken.com>hg
> To: "Kent Yu" <yux@lucent.com>
> Cc: <juniper-nsp@puck.nether.net>
> Sent: Monday, May 14, 2001 8:59 AM
> Subject: Re: [j-nsp] Route redistribution
>
>
> > On Mon, May 14, 2001 at 11:33:44AM -0700, Kent Yu wrote:
> > > Junipers route redistribution concept really confuses me.
> > > By definition, routes from the protocols are imported
> into the routing
> > > table, then exported to their respective routing protocols.
> >
> > Right.
> >
> >
> > > So in order to redistribute routes, I will have to use
> policy, right?
> >
> > Yes.
> >
> >
> > > But to me, isnt policy only used to filter routes that
> already exist?
> >
> > In the example you cited, the routes "already exist",
> they're just in
> > another protocol. By default, BGP routes are not exported
> into ISIS.
> > The example shows how you configure a policy to change the default
> > behavior. The application of that policy in the 'protocols isis'
> > section is what enables that policy (i.e., it is the equivalent of
> > the cisco 'redistribute' statement in the 'router isis' section).
> >
> >
> > > I mean, by default, there should no routes from bgp to ISIS, so to
> > > what routes the above policy applied?
> >
> > The policy applies to whatever routes the policy says it
> applies to. :-)
> > In this case:
> >
> > policy-options {
> > community Edu members 666:5;
> > policy-statement edu-to-isis {
> > from {
> > protocol bgp;
> > community Edu;
> > }
> > to protocol isis;
> >
> > Note the compound structure of the clause; it says that
> routes must come
> > from bgp *and* match the 'Edu' community, and be destined for ISIS.
> > Only if all of these conditions are satisfied will the
> 'then' portion of
> > the policy apply.
> >
> >
> > > Or can I understand as that the policy configuration actually
> > > activates redistribution?
> >
> > See above. What activates the redistribution is:
> >
> > protocols {
> > isis {
> > export edu-to-isis;
> > }
> >
> >
> > > If it is, I must say it is really confusing, at least to me.
> >
> > Confusing? Not really. Different from Cisco? Absolutely. If you
> > come from a Cisco background, JUNOS policy language and the
> application
> > of policies will take a little while to get used to.
> >
> >
> > > Also, the manual states: For IS-IS, you should not apply routing
> policies
> > > that affect how routes are imported into the routing
> table; doing so
> with a
> > > link-state protocol could easily lead to an inconsistent topology
> database.
> >
> > Yes, you generally don't want to muck with your IGP in this fashion.
> > Personally I would have used a different example;
> redistributing ISIS L1
> > routes into L2 or redistributing static routes into BGP
> would both be
> > more "practical" as examples IMHO.
> >
> >
> > --Jeff
>
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:42 EDT