Back in 2008, Nate wrote a blog post about migration service providers on Citylink into their own vlans. I've included bits of his post below, as the original Citylink blog server appears MIA. Si, May 2010


Background Information

Citylink's Metro Ethernet network, commonly referred to as "PublicLAN", has traditionally comprised a single layer-2 VLAN running across a plethora of 10/100/1000Mbps Ethernet media converters, hubs and switches. The traditional Citylink model has seen both Service Providers (ISPs and other SPs) and customers attach directly to an untagged access port in the main PublicLAN VLAN. Customers and Service Providers attach with a layer-3 device (router/firewall) and present a single Ethernet MAC address to the Citylink switch/hub. Service Providers typically allocate IP address(es) to their customers which they then use to deliver services to them across the shared PublicLAN switch fabric.

The traditional PublicLAN architecture has proven to be simple and effective. Once customers have leased a Citylink PublicLAN access circuit, they are free to acquire services from as many of the multitude of Service Providers attached to the network as they desire. They can also opt to participate at the local Internet eXchange (IX) at no additional cost, thereby benefiting from the local exchange of routes with other Citylink users, optimising performance to local content and reducing transit fees.

Why the migration towards Service Provider VLANs?

The need to migrate PublicLAN from a single VLAN architecture to a multiple Service Provider VLAN architecture has come about in part due to requests from Service Providers to provide such a service along with enhanced service options, combined with the need to increase the reliability of the access network (particularly the IX fabric) and address some scalability issues.

Several Service Providers have been reluctant to provide transit services to customers via the same interface as their peering relationships. Some would prefer all their customers to appear in a separate VLAN from other Citylink users, and some have expressed an interest for each of their customers to appear as a separate logical (VLAN) interface on their router. Such a service has not been practical to date with the single VLAN architecture and existing hardware limitations. However, our use of Linux-based VLAN Termination Units (VTUs) for SPVLAN delivery gives us the ability to transport b oth dot1q tagged and untagged frames transparently, providing an emulated "Q-in-Q" service. Since then, Citylink now primarly does Q-in-Q on natively on Cisco ME switches, Si May 2010

Different PublicLAN services place different requirements upon the underlying network that may warrant additional security stances which have been difficult to enforce within the single VLAN architecture. Connections to the Wellington Internet eXchange, for example, often form a vital component of an organisation's Internet connectivity/operations, yet they are have been open to compromise from other Citylink customers using poor quality and/or badly-configured router/firewall devices that can potentially interfere with other users on the network. Separating the WIX participants out into a dedicated peering VLAN allows Citylink engineering staff to assert and enforce a much stronger security stance that helps to reduce the chance of one users' activities interfering with another.

Likewise, moving customers of a given Service Provider into a dedicated Service Provider VLAN has the benefit of reducing the possibility of one Service Provider's customer impacting the service of another Service Provider's customer(s). Such an environment is attractive to Service Providers who are now also able to run an extended range of protocols for customer delivery to suit their needs, which may otherwise be inappropriate for use on a shared VLAN such as the WIX.

The other important motivator for migrating PublicLAN from a single VLAN architecture to a VLAN-per-Service-Provider architecture is to address the scalability issues inherit with a large layer-2 domain. As the number of customers attached to PublicLAN has increased over time, so too has the amount of broadcast and flooded unicast traffic increased. These packets are duplicated to every access port in the network and are sent to every PublicLAN customer. As this noise floor has increased, so too has the amount of bandwidth consumed on inter-switch links and customer access circuits. For customers still using our lower bandwidth services such as Connect4, the level of such "noise" (meaning traffic not sourced by, or destined for, them) can noticeably impact the performance of their connection. Reducing the number of hosts attached to any given layer-2 domain reduces the noise floor for all customers in the VLAN.

There is, however, one disadvantage to the VLAN-per-Service-Provider architecture: customers will now need to advise Citylink if they wish to change Service Providers so that we can arrange to migrate their access connection into the relevant SPVLAN.

FAQs:

  • Will you be migrating everyone out of PublicLAN and into the Service Provider VLANs all at once?

    No. The migration from a single, multiple-provider VLAN to a VLAN-per-Service-Provider architecture requires significant hardware and software (configuration) changes for us which we will be rolling out gradually on the network. For existing Service Providers, a new SPVLAN will be created for them and then temporarily bridged to PublicLAN while individual customer access connections are migrated across. New Service Providers will have an SPVLAN configured on the network and their customers will be added to it right from the outset.

  • Will I experience an outage while I'm being migrated into my Service Provider's VLAN?

    In most cases, no. The use of a temporary bridge allows us to have your Service Provider's VLAN configured alongside PublicLAN, so that you can continue to access your SP regardless of which VLAN you are connecting to. For customers of a single Service Provider, the change from PublicLAN to a SPVLAN can happen transparently. Otherwise, if you're a customer of multiple Service Providers (or an ExchangeNET participant) your connection will need to be split across multiple Citylink ports. This will require changes to the way in which you attach to Citylink. We'll be in contact with you to assist if we believe this to be the case.

  • But if I'm going to need additional Citylink ports, how much is that going to cost?

    Since Citylink is driving these architectural changes, existing customers using multiple Service Providers (at the time of migration) will not face any additional charges. Citylink will provision the additional switchports required (including the installation of additional building cabling where necessary) at our expense. Note, this was 2008 - best you check with Citylink on whether this is still the case! Si, May 2010

  • What if I want to change to another Service Provider on Citylink?

    As time goes on, more and more Service Providers on the network will be providing services across their own SPVLAN rather than PublicLAN. Chances are that your existing SP and your new SP will be in separate VLANs and therefore your access connection will need to be moved into the new SPVLAN. The safest option would be to assume that we have already completed our migration to a VLAN-per-Service-Provider architecture, and advise us of your plans in advance so that we can schedule a time to make the necessary changes to your access connection. You can do this by filling out the online "Change of ISP" form at http://www.citylink.co.nz/services/forms/change-isp.html. If you have any special requirements (such as the requirement for period of "dual-service" to both Service Providers) then please contact your Citylink Account Manager.