The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2003-May> msg00118



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

RE: How do you monitor client VPN devices

  • From: "Thomas D. Nadeau" <tnadeau@cisco.com>
  • Date: Fri, 16 May 2003 09:21:18 -0400
  • Cc: <George.Rousson@interoute.com>, <mpls-ops@mplsrc.com>
  • Importance: Normal
  • Organization: Cisco Systems
  • Resent-Date: Fri, 16 May 2003 10:28:23 -0400
  • To: <alok.dube@apara.com>, <ymilner@unistars.lv>



> -----Original Message-----
> From: Alok Dube [mailto:alok.dube@apara.com] 
> Sent: Friday, May 16, 2003 9:02 AM
> To: ymilner@unistars.lv
> Cc: George.Rousson@interoute.com; mpls-ops@mplsrc.com
> Subject: RE: [MPLS-OPS]: How do you monitor client VPN devices
> 
> 
> Hi,
> 
> i dont know how you plan to "leak bothways", it would mean 
> that in your management VPN, each and every CPE would have to 
> have a unique IP address....? wouldnt it? Do you mean SNMP 
> based management etc? you could look at SNMP proxys but this 
> would need1. a public IP per each client site (for the proxy) 
> 2. a public IP for your central SNMP server.
> 
> Basically you would need a "backdoor" kind of solution to get 
> into the customer VPN... It would be similar to  desgning the 
> network for a "central NMS station" 
> shared by various corporates clients....so you could ask the 
> SNMP list too... Also....as a possiblity, if routers could 
> have local SNMP collectors per VRF too .........but it doesnt 
> seem too "happening" i guess... -rgds Alok

	Cisco devices support a feature called
The VPN-aware SNMP infrastructure that allows
per-VPN access from any interface (configurable)
based on VACM/V3 security access.  There are
a handful of MIBs that support this currently,
and more added in the future.  This feature
seems to do what you are interested in. I forgot
to mention this in my previous post.

	--Tom

> 
> 
> > If I leak addresses, it would have to be both ways, right? Client's 
> > VPN routes would all have to be present inside the 
> management VPN, and 
> > management VPN routes would have to be present in all client VPNs 
> > routing tables.
> >
> > How do I prevent then transit through management VPN 
> between clients. 
> > Filtering?
> >
> > What about SAA agents in IOS? In 12.2 they support VRF. 
> Does someone 
> > use those?
> >
> > -----Original Message-----
> > From: George Rousson [mailto:George.Rousson@interoute.com]
> > Sent: 16 May, 2003 12:59
> > To: Yuly Milner; 'mpls-ops@mplsrc.com'
> > Subject: RE: [MPLS-OPS]: How do you monitor client VPN devices
> >
> > Hi
> >
> > You can create a management VPN and "Leak" your customers CPE's 
> > addresses into your one.
> >
> > George
> >
> >
> > -----Original Message-----
> > From: Yuly Milner [mailto:ymilner@unistars.lv]
> > Sent: 16 May 2003 10:21
> > To: 'mpls-ops@mplsrc.com'
> > Subject: [MPLS-OPS]: How do you monitor client VPN devices
> >
> >
> > Hello,
> >
> > We have a L2/L3 MPLS VPN-capable network, cisco-based.
> > I wonder what possibilities to monitor availability of CPEs are.
> >
> > We have a NOC, which resides in system routing segment. 
> From there we 
> > can test availability of our devices (like WLL terminals, since our 
> > network is based on wireless equipment). We need to monitor the 
> > customer's devices, which reside in respective VRFs. What are the 
> > options of doing it? Can someone share his/her experience?
> >
> > Thanks
> >
> > Yuly
> >
> > -------
> > The MPLS-OPS Mailing List
> > Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> >
> >
> > Information transmitted in this message is intended only for the 
> > person or entity to which it is addressed and may contain 
> confidential 
> > and/or privileged material. If you are not the addressee 
> you may not 
> > copy or deliver this message to anyone and you should destroy this 
> > message and kindly notify the sender by reply email. Opinions and 
> > other information in this message that do not relate to the 
> official 
> > business of the company shall be understood as neither given nor 
> > endorsed by it. We do not accept liability for any viruses 
> that may be 
> > transmitted in or with this message or attachments.
> >
> > Unless specifically stated otherwise in this e-mail, this 
> e-mail and 
> > the information contained in it or attached to it shall not 
> create any 
> > binding contractual relationship between the recipient or any other 
> > party and Interoute.
> >
> > Further information about the group is available from our 
> website at 
> > www.interoute.com.
> >
> > -------
> > The MPLS-OPS Mailing List
> > Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> 
> 
> 
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> 


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