Extreme Switches Beware

So I just bought two switches, a nice Cisco 3550 with inline power - has a little cosmetic damage but it works GREAT.

Everyday I am reminded how much I love Cisco stuff over the competitors (although, to be fair, I like JunOS although have only run it in Olive and its EXPENSIVE. I would HAVE a Juniper router if the cheapest router wasn't the SRX @ around 500$ Yikes!). Today I am reminded again.

I grabbed this off of Ebay for 65$. I noticed my company uses extreme gear and I wanted the chance to learn some of the CLI. Seeing all the Layer 3 features, including NAT, at a little less than I can procure another 3550 I jumped on it:



So I am cruising along, getting used to CLI - it works pretty good. Definately different than IOS or JunOS but not shabby then I encouter this:

Damnit. Thanks Extreme. I just bought a junk switch. I simply can't make use of this if I can't even enable things I need. I am not COMPLETELY against this business model, in a way, it makes perfect sense. Customers can procure a device and only pay for the license for the features they need. However, this is an EOL device. Going to their site I am still greeted with a page where I need to log in and register and I **MIGHT* be able to procure the license I need to get this working. Please Extreme, I would rather not torrent your software, and wade through potentially harmful downloads that may damage my equipment to get what I need.
I guess this is really no different than the SMI/EMI debacle, but it is really hard for people like me who want to learn the technology and perhaps put in a good word for the company in the end (positively impacting purchasing decisions) but I just can't do that here. If Extreme doesn't respond to my registration, I will send them an E-mail and if I can't get them to pony up a license for this I am shipping this switch off ASAP and not ever looking back to Extreme again. I will learn it when I am directly faced with it in production and will recommend Cisco equipment until then. Buying this switch was a mistake at this point and I should have just found another Cisco 3550 to prepare for the INE topology like I was doing in the first place. Buyer beware!

OSPF Theory

Intro:

---

Why Link State?

1. Drawbacks of Distance Vector Protocols:
1. Slow convergence
2. Send full routing table, at a regularly scheduled interval
2. Not typically used on WAN’s due to this.

OSPF:

1. ---

   Link-state protocol
2. Does not exchange routes and metrics
3. Exchange the state of their links
4. OSPF refers metric as cost
5. LSA- Link State Advertisements arrive from OSPF neighbors
6. Gives the router a picture of the network
7. Uses the Shortest Path First (SPF) algorithm (or Dijkstra)
8. OSPF is a Link State Protocol
9. OSPF routers do no need to form adjacencies with every other router; instead, OSPF networks elect a designated router and a backup designated router.
10. If the DR fails, the BDR takes over as the DR and a new election is held.
11. The value to elect the DR and BDR is the OSPF interface priority. (By default this is 1)
12. Setting his value to 0 will prevent it from becoming a DR or BDR
13. OSPF network statements use wildcard masks (REQUIRED in OSPF)
14. Hello timer – defines how often Hello packets are sent
15. Dead timer – how long OSPF will wait for Hello packets (40s Ethernet, 120s Non-broadcast links) (The dead time is 4x the Hello time, and OSPF will adjust this dynamically)

Process:

1. ---

   Neighbor adjacencies must be formed
2. OSPF Hello packets are sent to allow neighbors to dynamically discover each other
3. OSPF Hello packets allow the neighbors to remind each other that they are still there (keep alive)
4. Default Hello packet broadcast is 10 seconds on a broadcast segment such as Ethernet, and 30 seconds on non-broadcast links such as serial connections
5. Hellos have a destination IP of 224.0.0.5 (reserved class D “multicast” range)
6. Getting Hellos does no guarantee a neighbor relationship
7. Link State Update (LSU) contains multiple Link State Advertisements
8. Designated router (DR) and backup designated router (BDR) are elected
9. The designated router is the router that will receive the LSAs from other routers in the area, and flood the LSA indicating he network change to all non-DR and non-BDR

Commands

1. ---

   Debug ip ospf adjacency
2. Show ip ospf neighbor
3. Router ospf <area #>
4. Network <network #> <wildcard mask>
5. Show ip ospf interface <cr or int name>
6. Ip ospf hello-interval (allows you to change the hello interval timer, in seconds).

Stages of OSPF Adjacencies

1. ---

   DOWN– No Hellos from neighbors
2. ATTEMPT – Unicast hello packets are sent to the neighbor (you will only see these in NBMA networks)
3. INIT – First Hello packet has been received from neighbor
4. 2-WAY Communication – each router has received a Hello packet containing its own Router ID Number
5. EXSTART – Following DR/BRD election, the exchange of link state database information can begin. Router with the highest OSPF RID # will begin the exchange and increment the initial sequence number
6. EXCHANGE – Database descriptor packets (DBD) are exchanged; these packets contain a description of the link state database
7. LOADING – Routers now send Link State Request (LSR) packets to their potential neighbor
8. FULL – Router databases are synchronized and the adjacency has been formed.

Loop Prevention

1. ---

   OSPF does not rely on distance vector loop prevention methods such as split horizon or poison reverse. Those would not work with link-state because they are not exchanging routes.
2. The OSPF Algorithm recalculates so quick that routing looks literally have no time to form.

Network Address Translation

There are three types of NAT:

1.     Dynamic NAT
2.     NAT Overload
3.     Static NAT

Dynamic NAT: Inside addresses are a 1:1 translation with a pool of public addresses. Dynamic NAT is commonly used to solve problems with addressing, mainly overlapping addresses. The client must own the addresses used in the NAT pool.

NAT overload is commonly called PAT or “port address translation.”

NAT overload translates a private address to a public address by maintaining the same port number across the translation table.

Static NAT is used for servers, meaning a single private address is mapped to a single public address. Every time communication occurs, the private is mapped to that specific public address, and vice versa. The public address in the static mapping does not have to be assigned to the outside interface of the router doing NAT. A public address can be split into multiple NAT mappings based on port numbers.

Additional references: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094831.shtml




NAT OVERLOAD:

1. Label interfaces with the IP NAT INSIDE/IP NAT OUTSIDE command
2. Identify the private address(es) to be translated
3. Write access list: ip access-list standard ALLOWED_NAT_ADDRESSES; permit 192.168.1.0 0.0.0.255, permit 192.168.2.0 0.0.0.255
4.  Enable NAT overload: ip nat inside source list ALLOWED_NAT_ADDRESSES interface s0/0 overload

Inside global is the public IP address of the router. The inside local is the IP address of the client that initiated the connection. The outside local is the address that was queried.

STATIC NAT:

1. Remove PAT (overload) configurations.
2.  Create a POOL of public IP addresses that you have available for use: ip nat pool PUBLIC_IP_ADDRESSES 209.165.200.2 209.165.200.10 netmask 255.255.255.224 Note: This is DYNAMIC NAT
3. Define NAT statement: ip nat inside source list ALLOWED_NAT_ADDRESSES pool PUBLIC_IP_ADDRESSES overload. Ensure you use the overload command!
4. Define Static NAT statement for server(s):  ip nat inside source static 192.168.2.2 209.165.200.3
5. Other Static NAT mappings might look like this for specific ports which might be more secure:

router (config)# ip nat inside source static tcp 10.1.1.2 25 63.63.63.2 25
router (config)# ip nat inside source static tcp 10.1.1.2 443 63.63.63.2 443
router (config)# ip nat inside source static tcp 10.1.1.2 80 63.63.63.2 80
router (config)# ip nat inside source static tcp 10.1.1.2 110 63.63.63.2 110

The above configuration is called STATIC port NAT mapping and can be useful to redirect specific services like SMTP (port 25) HTTPS (port 443) Web Traffic to say a web server (80), and 110 (POP3). This is especially useful in getting the most out of your single public address.

Overview:

NAT: Translate one private address to one public address (no port translation used)

NAT overload: Translate a group of private addresses to one public address (port translation used, allowing for that "group" of addresses to use that one public address)

Dymanic NAT: Translate n number of private addresses to n number of public addresses (so if we have a pool of 4 public addresses, the first 4 private addresses to arrive at the router will be NATed. This form should of course not be used)

Dymanic NAT overload: Translate a group of private addresses to n number of public addresses (port translation used, allowing for the "group" to use those public addresses).

The Best Ubuntu NAT Tutorial

It is my goal here to wade through all the BS and get straight to things that work. I looked at numerous tutorials and spent a few hours on this, but I can confidently say I know the right method to get simple NAT working with ubuntu Server.

Assuming both the NAT router and the ubuntu host have been installed and updated, we have to set the network configuration on the NAT router. Edit /etc/network/interfaces to reflect below.

(eth0 is your WAN connection to ISP and eth1 is your LAN connection to your hosts)

auto eth0

iface eth0 inet dhcp 

pre-up iptables-restore < /etc/iptables.rules

auto eth1

iface eth1 inet static

address 192.168.10.1

netmask 255.255.255.0

network 192.168.10.0

broadcast 192.168.10.255

The pre-up line restores the iptables rules you define in /etc/iptables.rules upon reboot. Otherwise you will lose them and NAT will cease to function.

Edit /etc/sysctl.conf and uncomment:

 

net.ipv4.ip_forward=1

 

Now: 

sudo iptables -A FORWARD -o eth0 -i eth1 -s 192.168.0.0/24 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A POSTROUTING -t nat -j MASQUERADE

The first rule allows forwarded packets (initial ones). The second rule allows forwarding of established connection packets (and those related to ones that started). The third rule does the NAT. 

Next we copy the working iptable NAT rule to the file that will be run when eth0 comes up.

sh -c "iptables-save > /etc/iptables.rules"

Reboot.

On the client side I just edited /etc/network/interfaces and gave eth0 an IP address on the same subnet as eth1 on the NAT router. You can use DHCP if you like. This was a test. I will be posting my entire configuration once I get this working as my main router. I just did it in vmware workstation for now.

Quick Update

Ok so I am working towards hurricane electric's IPv6 certification but it is a long road that I hope to master a variety of technologies along the way. Starting out, I was to work with a webserver, but I found that I lacked on of the fundamental underlays of web pages and the way they work, that being DNS. DNS is already an important part of the certification, but before moving to IPv6 & DNS, which I feel will be an exciting adventure seeing how DNS in IPv6 is such a critical element, but it will also help me to master BIND9. To do this I will be testing a potential decommission of pfsense, for ubuntu to act as my primary NAT, packet filter, and edge router, as well as endpoint for HE.net to provide IPv6. Many opportunities are available upon this path, things like finally learning iptables syntax since I will not be relying on GUI firewall rules. Testing this involves virtual networking with VMWARE workstation creating a primary NAT ROUTER in ubuntu 64-bit, as well as using "host only" networking to provide another "host" ubuntu server machine to test IPv6 connectivity, router advertisements (perhaps using QUAGGA), DNS connectivity and results, and many other things down the line. More details are to come, hopefully running though all the progress of turning the machine into a NAT router and getting BIND9 working.

Getting Ubuntu Server going with IPv6

I set up a Ubuntu Server in VMware workstation to test things like Quagga, Apache and BIND9. Setting it up in and of itself took a little doing. First, a shot of my virtual networking since for some reason I could not get the typical "Bridged Networking" configuration to work.


So VMnet2 is just bridged to a different adapter than the one supplying my physical machine TCP/IP access. That seemed to solve all the problems I ran into, primarily ubuntu not being able to ping the default gateway.

Then you can just add this below your initial IPv4 configuration in your /etc/network/interfaces file:
iface eth1 inet6 static
pre-up modprobe ipv6
address 2607:f0d0:2001::10
netmask 64
gateway 2607:f0d0:2001::1

Traditionally we put our DNS entries in /etc/resolv.conf but I guess that file now gets overwritten.

You should add your DNS entries to the following file: /etc/resolvconf/resolv.conf.d/base

I use OpenDNS IPv4 & IPv6 Servers:

nameserver 208.67.222.222
nameserver 208.67.220.220
nameserver 2620:0:ccc::2
nameserver 2620:0:ccd::2

Then you can run: sudo /etc/init.d/resolvconf restart