The MPLS-OPS Archive

[Roger Clark Williams <rogerw@nordlink.com>]

Tony, I had this exact question in a VPNSC class,and it is an interesting
one. Usually the box that holds that information is inside the provider's
NOC, and access to the NOC by customers is, should we say, strongly
discouraged. 

Within VPN Solution Center there is a way to provision a management VPN.
The presumption is that for VPNSC to do its job, it needs to be able to
reach each customer's VPN, and likewise the customer needs to be able to
reach the VPNSC box (ie normal IP types of traffic, known routes etc, but
in specific, SNMP is the underlying reason for it). By design, each
managed customer is a member of the management VPN along with his own
VPN. As I said above, this is not a situation that either the SP or the
customer really likes, as neither wants the other to see routes internal
to their own networks. So the management VPN is a special one, 
built to share very little information. Usually only the loopback address
of the customer CE and the NOC CE ( or "MCE") is passed between
the two networks. 

With all this, it is possible to tweak that setup to have the VPNSC box
and/or your management system box behind that CE and visible to the
customer, but that isn't the strongest of protections. If the management
box can be seen by the client, effectively anything on that subnet is
subject to unauthorized access, and perhaps different customers could see
each other's setups and other information. Not good.

What the group in the class came up with was to have an extranet on a
separate subnet and allow each client/customer VPN access to a box with a
copy of the information gathered by the management system. This would be
something like a DMZ for the NOC, and the real management system wouldn't
be here. There is still the need to segment various customers'
information on that box, so as a solution it is still just a concept.
There could be a number of other scenarios, and I mention this one simply
because it was one provider's proposed solution. It is not necessarily
the best, but perhaps it will get the discussion going. It is a real
need, and it would be great to hear from some providers as to how they
handle it.

Roger Williams


> Resent-Date: Thu, 17 Oct 2002
> 12:10:48 -0400
> X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender
> to mpls-ops-request@mplsrc.com using -f
> Date: Thu, 17 Oct 2002 16:25:49 +0100 (BST)
> From: Joseph Anthony <tonyjoe20002002@yahoo.co.in>
> To: mpls-ops@mplsrc.com
> Subject: [MPLS-OPS]: REG: MPLS Design issue
> Resent-From: mpls-ops@mplsrc.com
> X-Mailing-List: <mpls-ops@mplsrc.com> archive/latest/4672
> X-Loop: mpls-ops@mplsrc.com
> Resent-Sender: mpls-ops-request@mplsrc.com
>
> Hello, 
>
> I guess many of you would have faced a similar situation. On a provider
> network running MPLS VPN's, There is a requirement as follows - 
>
> All MPLS VPN customers, will need to access a central Network Management
> system located in the provider network, which would provide customers
> with detailed reports on their respective VPN. The server would ideally
> be providing reports on bandwidth, network uptime etc. 
>
> What would be the ideal way of provisioning the same. 
>
> The network will not provide transport for Internet traffic. 
>
> Any suggestions will be appreciated. 
>
> Regards, 
>
> Tony. 
>
>   
>
>   
>
>  
>
> Yahoo! Properties Special Buy, sell,
> rent...your flat, or even post an ad 

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml