A VLAN, or Virtual Area Network, is a group of devices that have sequential IP addresses and are behind a firewall. VLAN is a list of IP addresses that you control. You can assign these addresses as you like. The firewall's ACLs (Access Control Lists) are controlled by the customer. Every customer has their own VLAN with ** ** ** or IP addreses. They have a separate VLAN in each datacenter where they have equipment.
Firewall and ACLs
ACL refers to a list IP addresses, both origin and destination, and ports where traffic is permitted to pass. The *router* does this? Access control lists can generally be configured to control both inbound and outbound traffic, and in this context they are similar to firewalls. How are they different from firewalls, is at all? Is the ACL just the "firewall settings"?
Link to How to Request Firewall Changes
If you run out of IP addresses in your VLAN.
You can either migrate to a larger one or, have a second one. Migration currently requires brief downtime.
Relevant tickets: #4128 /#4625/#3952
5. Will migrating be available through the API in the future?
8. VPNs??? What are they exactly. Customer VPN question and answer:
What is the capacity of our VPN hardware?
Currently there is no customer-allocated VPN hardware. If you need VPN capabilities, please let us know and we may be able to provide them to you for a fee.
You can open all traffic between VLANs in each datacenter but will travel ovre the internet.
Stateful vs. non stateful inspection.
What about instructions:
1. When you launch new instance, please use --ip= flag of `manage-instance launch` command to explicitly declare IP address of instance in new address block.
2. Please note new command `manage-instance bundle` implemented in last CLI release. With this command you're able to migrate your instances to new address space right now. You need to create images from every your instance and launch instances from these images in new address space. Please note that making image requires shutting down origianl
Migrating to new addressspace is not mandatory right now - in case if you don't need PTR (reverse DNS) records for your old instances. You may wait till we will implement and release features for more convenient migration.
Please, when you launch new instances, explicitly assign them IP addresses from new IP ranges, to not fail into IP migration process with these new instances in the future. To be able to assign IPs to newly launched instances, you need the most recent version of CLI to be installed on your management instance(s).
What does this mean?
> > We're close to the process of IP renumbering in both LAX1 and NYM1
> > datacenters. Our infrastructure still needs some features to be
> > implemented, but assignment of the second VLAN of bigger size from the
> > new IP space is possible right now - if you will carefully follow
> > instructions on how to work with it.
> ---WBR, Alexander Novitskiy
VLANs available in 24, 56, or 120 usable IPs. Some of each range go to ** equipment.
Assignment of new VLANs could take up to workday, as it involves changes in ACL rules for all your VLANs.
You'll need a separate VLAN in each datacenter where you have equipment. Also, by default, we DON'T open traffic between VLANs in different datacenters that belong to the same customer. We do the last by purpose, understanding that traffic between VLANs in different datacenters go thru public networks and thus could be faked/spoofed/etc.
By default when we assign second VLAN in the same datacenter, we apply to the new VLAN all general (not host-specific) rules from the old VLAN, and open all traffic between VLANs in the same datacenter. Let us know if we should change these rules.
Meanwhile I'll prepare instructions on how to deal with multi-VLAN environment, how to migrate instances from old IP space to the new one with the existing API/CLI functionality, et cetera.
I want to start some instances in the LA data centre but it seems we have
run out of IP addresses:
root@manage ~# manage-instance launch --share_name=cust002
--path=images/bsr.fs.tgz --name=bsr03_la_openx_org --server_id=LAX1:111
--cpu_units=4 --memory=7448mb --disk=650gb
No free IP addresses to start an instance
This is a fairly major problem for us.
Can you please let me know what the status is with the IP addresses in LAX1?
These questions are also answered on the wiki FAQ but may be helpful here.
1. Why do you use ACLs instead of a stateful firewall?
Stateful inspection is most useful for protecting outbound traffic, but with hosting, the servers tend to receive traffic instead of initiate it. Also, because we are dealing with an unknown amount of traffic, the ability to scale is very important. Stateful inspection is an expensive task for a device to perform and therefore subject to strict capacity limitations (we're talking sub Gigabit for most firewalls). On the other hand, Cisco routers perform ACL packet filtering at line rate with absolutely no performance hit. So, while stateful inspection is appropriate for small, stable amounts of outbound traffic or for protecting niche pieces of the network, (like e-commerce databases), ACLs are more scalable and efficient for protecting inbound traffic to servers. If a customer still desires a stateful firewall, we can add it for a fee.
2. What are the security implementations at each relevant layer of the OSI Reference Model?
- Layer 1 - (Physical Layer) All your network gear and servers are protected in secure, locked colocation facilities.
- Layer 2 - (Data Link Layer) Extensive use of VLANs provides segregation of each customer's traffic from AppNexus traffic and other customers' traffic.
- Layer 3 - (Network Layer) Bi-directional ACLs are applied on every routing interface with a Default Deny policy, meaning only explicitly permitted traffic is allowed to pass.
- Layer 4 - (Transport Layer) The use of TCP-based protocols provides connection reliability and allows for session protection via ACLs and host firewalling.
- Layer 7 - (Application Layer) There is extensive use of encryption (SSH, SSL-VPN) throughout the network.
3. How do you detect, prevent, and manage DDoS attacks and application-level attacks?
Preemptive protection against DDoS attacks is difficult, because we have no way of knowing when, where, or what type to expect. Also, please note that AppNexus does not manage nor monitor the customer's applications (even their OS). That said, in the event of an attack the use of Cisco ACLs allows us to apply deny statements for the source of the attack without affecting performance of the rest of the network. Also, we highly recommend that our customers utilize the F5 server load balancing technology for front-ending their web applications, as the F5s provide built-in DDoS protection when it performs full-proxy session offload.