There has been a rumour floating around lately that Amazon is going to be introducing Ethernet switches. A move like this by Amazon will eventually challenge manufacturers like Cisco Systems. I have came across a video from Packet Pushers where Greg Ferro talks about the possibilities and avenues which Amazon would take to venture into the switching or even networking arena.
As Greg stated, Amazon, in this case AWS already run their own network on their own hardware and software. This is because they cannot have a profit margin by relying on another vendor. It would be cheaper in the long run, to run on your own hardware and software managed and manufactured by themselves. Furthermore, it will be near impossible to run the biggest cloud architecture in the world and run the network on some other vendor. They would most likely run their underlying network as a fabric, controlled by Software Driven Network SDN such as OpenFlow and run the rest of the architecture virtualized and controlled by the AWS console.
When it comes to subnetting most people usually stop at /30. This will give them a netmask of 255.255.255.252 thus resulting in two usable IP address along with one Network and one Broadcast address.
The /31 subnet prefixes was introduced in RFC3021 which defines that it can be used on a point-to-point link. A point-to-point interface does not need broadcast address, therefore we don’t really need to assign a /30 address prefix. On a /31 bit segment, both addresses are interpreted as hosts addresses.
The main advantage of using /32 prefix will enable us to limit the number of network address required on a segment. Therefore, if a company using multiple point-to-point networks using public IP addresses, then they will be able to save half of its allocated IP space.
This post will cover the IPv6 configuration on Ubiquiti Edge Router ERPoE-5 running Version 1.9.1. I will be going through the whole process of setting up IPv6 connectivity using Hurricane Electric 6in4 tunnel.
I will not be using the real IP Addresses, however the reader should be able to understand and substitute for their own configuration.
This is a home network, therefore a lot of aspects are not considered in the design!
- There are three VLANs. (Main (1) , Guest (2) , Automation (3) )
- Since there is no native IPv6 support from my ISP, I am using a 6in4 Tunnel to get IPv6 working.
- The EdgeRouter is the public facing device connected to a vDSL Modem via eth0.
- The Ethernet interfaces eth1, eth2, eth3, eth4 are bridged via bridge interface br0.
- Bridge interface br0 has a 192.168.1.1/24 RFC1918 address assigned to VLAN1 and also used as the management IP.
In this part, I will be covering the tunnel creation. You need to head to Hurricane Electric (HE) https://www.tunnelbroker.net and get yourself an IPv6 tunnel. I have used a /48 Routed Prefix for my configuration which you can see below.
The Route Distinguisher (RD) and the Route Target (RT) can be somewhat confusing to someone who is trying to learn the concept on MPLS. In this post, I will try and explain what RD and RT are in relation to MPLS.
To answer this question, we will use the following diagram.
On Cisco ASA, You cannot have DHCPd and Relay configured at the same time.
- You can either add a relay server and add the DHCP scopes.
- You can add different DHCP scope to the ASA DHCPd.
The following object-group consists the latest IANA ROOT DNS Servers which can be used on the Cisco ASA firewalls.
IANA Root DNS Servers (IPv4/IPv6)
object-group network IANA-ROOT-DNS
description IANA Root DNS Servers (IPv4/IPv6)
network-object host 188.8.131.52
network-object host 2001:503:ba3e::2:30
network-object host 184.108.40.206
network-object host 2001:500:84::b
network-object host 220.127.116.11
network-object host 2001:500:2::c
network-object host 18.104.22.168
network-object host 2001:500:2d::d
network-object host 22.214.171.124
network-object host 126.96.36.199
network-object host 2001:500:2f::f
network-object host 188.8.131.52
network-object host 184.108.40.206
network-object host 2001:500:1::803f:235
network-object host 220.127.116.11
network-object host 2001:7fe::53
network-object host 18.104.22.168
network-object host 2001:503:c27::2:30
network-object host 22.214.171.124
network-object host 2001:7fd::1
network-object host 126.96.36.199
network-object host 2001:500:3::42
network-object host 188.8.131.52
network-object host 2001:dc3::35
When it comes to firewall rules, there are a number of things I follow as best practice. To start with, you need to make sure you have all the necessary information in place before writing your firewall rules.
Ask yourself the following questions… If you don’t have the answers, go back to the drawing board and get all the necessary information.
- Do you have all the necessary ports required for the firewall?
- Do you have all the IP/Subnet information?
Make the ACLs short and sweet
It is always a best practice to avoid using IP addresses in ACLs.
- Make sure that the ACLs are intuitive to anyone who is not familiar with your network.
- You should be able to understand how the firewalling is done by reading the ACLs.
This will guide you through adding and removing interfaces from VSAN Database. Even though I have tested this on Cisco MDS 9124, the process is virtually the same on the Cisco Nexus platforms with a slight difference on interface names.
When you issue the command show VSAN membership will tell you which VSAN member an interface is part of.
Interfaces are usually in VSAN 1 being the default and it can be moved to other VSAN by using the following commend.
vsan 100 interface fc1/1
If you want to remove an interface from a particular VSAN, you need to move it back to VSAN 1.
The following post shows how to specifically allow specific DNS servers on a Cisco ASA firewall. In this example, I am using Google DNS to be allowed through the firewall.
object-group service DNS-PORTS
service-object udp destination eq domain
object-group network GOOGLE-DNS
network-object host 184.108.40.206
network-object host 220.127.116.11
access-list ACL_in extended permit object-group DNS-PORTS NETWORK 255.255.255.0 object-group GOOGLE-DNS
The following post will explain one of the recommended method of filtering unwanted traffic from the internet to the internal network.
Most administrators filter RFC-1918 traversing from the internet to internal networks, while they are allowing a list of bogons prefixes which is defined in RFC-3330. These addresses are _not_ publically assigned, therefore should not see them as source IP destined to your internal network. Furthermore, it is a best practice from a security prospective to filter these ranges in case you are targeted with a spoofing attack.
As a reference to this post, please check RFC-3330 which contains all the prefixes in question.