[j-nsp] vrf-export practical proposals welcome....

[Peter Krupl]

Hi,

By removing the communities and replacing them with tags, would still not 
Put all the configuration in one place. I will not do any tags or communities 
on the static routes, but instead move it all to policy-statements.

Thanks for confirming that communities set in one policy can indeed be matched 
in a "chained" Policy.

Please disregard my previous post, my finger slipped while moving the mouse 
over the send button.

Kind Regards,
Peter Krüpl

> -----Oprindelig meddelelse-----
> Fra: Stefan Fouant [mailto:sfouant at shortestpathfirst.net]
> Sendt: 30. april 2011 17:48
> Til: Peter Krupl; juniper-nsp at puck.nether.net
> Emne: RE: [j-nsp] vrf-export practical proposals welcome....
> 
> > -----Original Message-----
> > From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> > bounces at puck.nether.net] On Behalf Of Peter Krupl
> > Sent: Friday, April 29, 2011 7:55 AM
> > To: juniper-nsp at puck.nether.net
> > Subject: [j-nsp] vrf-export practical proposals welcome....
> >
> > Hi Group,
> >
> > I trying to think of a practical solution for communities to be
> applied
> > to VRF routes.
> > We have a mpls network consisting of several MX'es as PE routers. The
> > PE routers have
> > BGP PE-CE perrings and off course PE-PE peerings.
> >
> > Our advertising of routes to external peers is controlled by
> > communities..
> >
> > Applying a community directly to a static route is possible albeit
> > ugly, since this
> > spreads community assignment to both static routes and policy
> > statements.
> 
> You could use the internal 'tag' statement on the static routes, and
> then
> simply match on 'protocol static' and 'tag x' for your export policy.
> Then
> set the communities in your action statement.  This would
> resolve/remove the
> issue of community assignments on the statics.
> 
> > Applying a community to a direct(connected) route seems only to be
> > possible
> > by applying a vrf-export policy for the PE-PE sessions, and applying
> a
> > policy to
> > the PE-CE neighbours.
> >
> > For the sake of consistency i would strongly prefer a solution where
> > theese are only defined
> > in a single place. So im thinking of a solution where the setting of
> > communities is in a seperate policy,
> > and then several policies are applied where needed.
> >
> > Policy1, apply route target (this is necessary in a vrf-export
> policy)
> > Policy2, apply communities according to route filter.
> > Policy3, filter based on communities (even those set by policy2, is
> > this even possible)
> 
> This should be possible so long as you don't have a terminating action
> in
> your policy term.  Use of the 'next term' and 'next policy' can assist
> you
> in controlling the flow of policy evaluation to ensure that once a
> community
> is set a subsequent term can be performed to perform additional
> filtering
> based on those communities, etc.
> 
> HTHs.
> 
> Stefan Fouant, CISSP, JNCIEx2
> www.shortestpathfirst.net
> GPG Key ID: 0xB4C956EC