Hi Paul,
Actually this could be a trivial issue, but in the real world customers
can fall in any kind of inconvenient due to a wrong naming system :)
In my case (Telecom Italia), customer has a naming convention for
routing-instances, where each vrf is a client of course. For
route-distinguisher choice i'm not completely sure because it completely
depends on provisionig people, that here act independently from
operations and engineering.
Anyway, in troubleshooting and network maintainence we observed that:
- preferently the instance name should refer to the instance type (in
order to be able to easly differentiate between L3VPN and VPLS for
example, directly looking at the name)
- not sure that using VLAN in the RD composition is a good choice: here
we have clients with accesses in many vlans, and for us this is not a
meaningfull parameter in order to identify the customer, possibily in
your case this could be a future evolution ?; possibly it should be used
a univoque ID for customer that can be inserted both in instance-name
and in the RD value.
In any case, i think the key here is in having a very robust tool
(database) for provisioning: not possible to demand to JUNOS this kind
of reponsabilities.
Cristian
On 06/11/2013 11:26 AM, Paul Stewart wrote:
Hey thereŠ.
Subject line might be a bit confusing but here goes:
In our Juniper network, we have a growing number of LSP's. Primarily
these LSP's are used for l2vpn connections and some VPLS.
In our l2vpn configurations we assign VRF information which might look
like this:
vrf-target target:12345:2049
We are adopting target:our_asn:vlan_number as our standard way of "naming"
these targets. Obviously we want to avoid duplications across the
network. Our eBGP connections are all community driven as well and we
want to avoid assigning VRF-target that may conflict with them.
Is there any suggested "tracking" options that folks use to ensure network
wide unique VRF targets are being assigned? We could use a spreadsheet
(yuck) or build a database for this just looking for feedback on how
others tackle this today.
Any/all feedback much appreciatedŠ
Paul
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
--------------------------
Cristian Frizziero
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
