This is how we acheive the layer-2 seperation of Hosted customers in our
IDC's.
> -----Original Message-----
> From: 'Dmitri Kalintsev' [mailto:dek@hades.uz]
> Sent: 06 June 2001 23:24
> To: cisco-nsp@puck.nether.net
> Subject: Re: pVLANs question (cross-customer connectivity problem)
>
>
> On Wed, Jun 06, 2001 at 04:29:07PM +0100, Desmarais, Jonathan wrote:
> > The correct solution is to add a static route to the local
> network through
> > the participating router, to all customer systems on the
> pVLAN. And on that
> > router control the level of access to the customer with the "popular
> > databse".
>
> Is this a real life experience or a speculation? I can
> achieve the same
> effect by configuring netmask of /32 on client side, but will
> it work? I
> have a feeling that it shouldn't, that's why I ask if what
> you suggest is a
> real life experience.
>
> > Sort of fooling the customers systems into sending local
> traffic to the
> > router first.
> >
> > Regards
> > Jon..
> >
> >
> >
> > > -----Original Message-----
> > > From: Dmitri Kalintsev [mailto:dek@hades.uz]
> > > Sent: 06 June 2001 06:36
> > > To: cisco-nsp@puck.nether.net
> > > Subject: pVLANs question (cross-customer connectivity problem)
> > >
> > >
> > > We're about to implement pVLANs in our IDC. I have a
> burning question
> > > regarding addressing and cross-customer access when using
> > > pVLANs. Consider
> > > this:
> > >
> > > 1. IP address block used for customers (valid routable IP
> > > block) is say
> > > x.x.x.x/21
> > >
> > > 2. Imagine that we have a customer, who runs popular database
> > > (for example,
> > > geographic map database) and we have few other customers who
> > > wish to use
> > > this database from their applications running on their
> > > servers, so they will
> > > need an access to first customer's server, but only to
> one service, so
> > > placing them all together in community vlan will not cut
> > > anything besides
> > > making first customer very pissed off.
> > >
> > > 3. Giving all customers netmasks of /32 and assigning promisc
> > > port netmask
> > > of /21 won't help for obvious reasons.
> > >
> > > I'm thinking about giving rfc1918 addresses to hosted
> > > customers and NATing
> > > them on 6509's MSFC to provide this functionality. Any other
> > > ways of solving
> > > this problem?
> > >
> > > Or is there a problem? ;^)
> > >
> > > SY,
> > > --
> > > CCNP, CCDP (R&S) Dmitri E. Kalintsev
> > > CDPlayer@irc Network Architect @ connect.com.au
> > > dek @ connect.com.au phone: +61 39 674 3913 fax: 251 3666
> > > http://-UNAVAIL- UIN:7150410 cell: +61 41 335 1634
> > >
> >
> >
> >
> **********************************************************************
> > COLT Telecommunications
> > Registered in England No. 2452736
> > Registered Office: Bishopsgate Court, 4 Norton Folgate,
> London E1 6DQ
> > Tel. 020 7390 3900
> >
> > This message is subject to and does not create or vary any
> contractual
> > relationship between COLT Telecommunications, its subsidiaries or
> > affiliates ("COLT") and you. Internet communications are not secure
> > and therefore COLT does not accept legal responsibility for the
> > contents of this message. Any view or opinions expressed
> are those of
> > the author. The message is intended for the addressee only and its
> > contents and any attached files are strictly confidential.
> If you have
> > received it in error, please telephone the number above. Thank you.
> >
> >
> >
> **********************************************************************
> >
> ---end quoted text---
>
> --
> CCNP, CCDP (R&S) Dmitri E. Kalintsev
> CDPlayer@irc Network Architect @ connect.com.au
> dek @ connect.com.au phone: +61 39 674 3913 fax: 251 3666
> http://-UNAVAIL- UIN:7150410 cell: +61 41 335 1634
>
**********************************************************************
COLT Telecommunications
Registered in England No. 2452736
Registered Office: Bishopsgate Court, 4 Norton Folgate, London E1 6DQ
Tel. 020 7390 3900
This message is subject to and does not create or vary any contractual
relationship between COLT Telecommunications, its subsidiaries or
affiliates ("COLT") and you. Internet communications are not secure
and therefore COLT does not accept legal responsibility for the
contents of this message. Any view or opinions expressed are those of
the author. The message is intended for the addressee only and its
contents and any attached files are strictly confidential. If you have
received it in error, please telephone the number above. Thank you.
**********************************************************************
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:40 EDT