[j-nsp] IPAM like tool/DB for managing communities

adamv0025 at netconsultings.com adamv0025 at netconsultings.com
Thu Dec 27 08:48:47 EST 2018


Yes that's what I was thinking too, use RD as merely an arbitrary VPN ID.
And then I realized that even though I could use these tools for documenting the VRF config after the fact 
But I can't use these with automated service provisioning.
I need my automated service provisioning tool to query the RT DB in order to allocate next available RT from a pool e.g. "l3vpn-small-customers-pool1".


adam
> -----Original Message-----
> From: Gustav Ulander <gustav.ulander at telecomputing.se>
> Sent: Monday, December 17, 2018 3:34 PM
> To: adamv0025 at netconsultings.com; 'Roger Wiklund'
> <roger.wiklund at gmail.com>
> Cc: 'Juniper List' <juniper-nsp at puck.nether.net>
> Subject: RE: [j-nsp] IPAM like tool/DB for managing communities
> 
> Hello there,
> 
> Same issue with PHPIPAM.
> RDs are the unique identifier and always mapping towards the VRF name.
> You can add custom fields to VRFs where you can place your RTs.
> If you are running a unique RD per PE the VRF is configured in then the RD is
> not that important anyway it’s the RTs that important.
> We run the above setup and just do a fake RD per VRF since its always
> changing depending on the PE you look at.
> Of course if you really want to do it properly you would probably want to
> note every PEs instance of each VRF together with the RTs to document it
> properly.
> 
> //Gustav
> 
> -----Original Message-----
> From: juniper-nsp <juniper-nsp-bounces at puck.nether.net> On Behalf Of
> adamv0025 at netconsultings.com
> Sent: den 17 december 2018 13:51
> To: 'Roger Wiklund' <roger.wiklund at gmail.com>
> Cc: 'Juniper List' <juniper-nsp at puck.nether.net>
> Subject: Re: [j-nsp] IPAM like tool/DB for managing communities
> 
> Yes I tried NINAP, but as others IPAM tools out there it has this 1:1
> relationship between VRF and RT
> 
> I could hack around this and use the main RT thing as sort of an arbitrary ID
> (or main VRF RT) and add the actual/additional RTs as TAGs.
> 
> Tried the same thing in netbox.
> 
> But these are hacks in a sense, working around the base limitation that is
> these DBs are maintaining VRFs and assigning RTs to those -I need it to be the
> other way around. So what I’m looking for is pools of communities for
> different services, utilization of the pools, etc... these are fairly standard
> things offered by IPAM tools for IP resources but when it comes to
> communities…
> 
> 
> 
> But will take a look at the phpipam, thank you.
> 
> 
> 
> adam
> 
> 
> 
> From: Roger Wiklund <roger.wiklund at gmail.com>
> Sent: Thursday, December 13, 2018 3:09 PM
> To: adamv0025 at netconsultings.com
> Cc: Juniper List <juniper-nsp at puck.nether.net>
> Subject: Re: [j-nsp] IPAM like tool/DB for managing communities
> 
> 
> 
> NIPAP maybe?
> 
> http://spritelink.github.io/NIPAP/
> 
> 
> 
> Personally I like phpIPAM, it's quite easy to add custom stuff.
> 
> https://phpipam.net
> 
> 
> 
> 
> 
> On Mon, Dec 10, 2018 at 10:30 AM <adamv0025 at netconsultings.com
> <mailto:adamv0025 at netconsultings.com> > wrote:
> 
> Hi folks,
> 
> I'm just wondering if anyone happens to know about a tool that can be used
> to manage BGP communities (standard/extended/large communities).
> 
> I'd appreciate any pointers
> 
> Thanks
> 
> 
> 
> adam
> 
> 
> 
> netconsultings.com <http://netconsultings.com>
> 
> ::carrier-class solutions for the telecommunications industry::
> 
> 
> 
> 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net <mailto:juniper-
> nsp at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



More information about the juniper-nsp mailing list