> -----Oprindelig meddelelse----- > Fra: Stefan Fouant [mailto:sfou...@shortestpathfirst.net] > Sendt: 30. april 2011 17:48 > Til: Peter Krupl; juniper-nsp@puck.nether.net > Emne: RE: [j-nsp] vrf-export practical proposals welcome.... > > > -----Original Message----- > > From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- > > boun...@puck.nether.net] On Behalf Of Peter Krupl > > Sent: Friday, April 29, 2011 7:55 AM > > To: juniper-nsp@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 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp