Hi John, William,
This would be a lovely feature to have, and indeed you could craft some SLAX
commit script to do it for you.
In our network we offer our subscribers (well, members of a consortium) very
granular BGP communities to traffic engineer their announcements to our peers
and upstreams.
We allow for opt-in announcement, opt-out blocking, prepending 1/2/3/6 times,
and we do this on a per-IX and per-ASN basis.
Eg: you want to block announcements to peer A at IX Y, prepend x3 to
peer B at all IXes, where default policy is to announce to all peers.
Eg: you want to announce to peer C at IX Z, and peer D at all IXes, and
no-one else.
As you can imagine, that's a lot of BGP policy and a lot of BGP communities.
My solution to this is peeringdb.com API + scripts + templates.
This way config is automatically generated off-box and then pushed via SSH.
I just give my script an ASN as input and it finds IX overlap, generates config
for our IX-facing routers, and pushes the right config where it's needed.
Kind regards,
Niall
> -----Original Message-----
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
> Jackson, William
> Sent: 05 November 2016 20:29
> To: John Brown <j...@citylinkfiber.com>; juniper-nsp
> <juniper-nsp@puck.nether.net>
> Subject: Re: [j-nsp] MX series BGP config macros ?
>
> The parameter feature in IOS-XR is very nice, although there are other parts
> that aren’t so great.
> I havent seen anything like this on Junos.
>
> I must say I believe that this part of Junos has been abandoned somewhat and
> could do with some developer time.
>
> On 05/11/2016, 21:24, "juniper-nsp on behalf of John Brown"
> <juniper-nsp-boun...@puck.nether.net on behalf of j...@citylinkfiber.com>
> wrote:
>
> Hi,
>
> I'm trying to build a BGP policy config that will advertise routes based
> on how
> a subscriber tags a route towards us.
>
> If they send a route with community 65010:XXX with XXX = an ASN
> then we will not announce it towards that ASN.
>
> In a small configuration this is pretty easy to do, but I'm looking at
> trying to
> see if there is a more elegant and scaleable solution.
>
> With hundreds of peers on a router, it doesn't make sense to have a bunch
> of
> community members for each ASN
>
> It would be nice to have code that did
>
>
> protocol bgp
> group eBGP-Some-Peer
> peer-as 1234
> export [Dont-Export]
>
>
> policy-statement Dont-Export
> term
> from
> protocol bgp
> community 65010:$PEERASN
> then
> reject
>
>
>
> Where $PEERASN gets expanded to 1234 because of the BGP session
> it is associated with.
>
> Then I can just apply Dont-Export to multiple peers and not have to
> customize
> it for each one
>
>
>
> Hopefully this explains it well enough.
>
> Thank you
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
