Which port for DHCP?

For a long time, I never remembered which UDP port was for the DHCP server and which was for the client. I finally came up with a trick... you have to have a server in place before you can have any clients, right? Therefore, the first port, 67, is the port the server listens on. The second port, 68, is the source port the client uses.

TCP, UDP, and the Crossover

I often see only-tcp or only-udp allowed in firewalls for certain protocols that work best with both. We have to continue to keep our eyes on the industry to see where things are going so we can be most efficient. Below are some examples, listed with the primary/traditional protocol, then the reason why the other one should also be allowed. In many cases, things will work without allowing the "secondary" protocol, but their efficiency may be hampered.

• https (tcp/443) - Since its inception, https has been a tcp protocol. However, in recent years, and especially with the advent of HTTP/3, allowing only tcp is not good enough. Even before HTTP/3, DTLS has made a tcp-only stance not good enough in regards to https.
• dns (udp/53) - The intro to RFC 7766 says it perfectly: Most DNS transactions take place over UDP. TCP is always used for full zone transfers (using AXFR) and is often used for messages whose sizes exceed the DNS protocol's original 512-byte limit. The growing deployment of DNS Security (DNSSEC) and IPv6 has increased response sizes and therefore the use of TCP. I have seen situations where AWS responds with data longer than 512 bytes, and it's not uncommon to find TXT records (e.g., for SPF) to exceed that length as well.
• rdp (tcp/3389) - Microsoft's Remote Desktop Protocol works better if both tcp and udp are allowed. It has supported udp since version 8.0 and it creates a smoother experience.
• ldap (tcp/389) - Microsoft is now starting to use ldap over udp in certain scenarios.

There are surely a lot more, and the list will surely grow, but I just thought I'd comment on a few...

The Case of the Roaming Windows Domain-Joined Laptop

The title is inspired by Mark Russinovich's great series “The Case of the Unexplained.” He is a technical wizard, and I am definitely not even in the same ballpark. But, inspiration is inspiration, so here we go.

I have a work laptop that is joined to our Active Directory domain. When I would bring it home it would take about 90 seconds to unlock. I finally took a packet capture via tcpdump on my home router running OpenWRT in order to see what the heck it was doing for that long.

I knew it would be trying to query DNS and I also knew that it would not find what it was looking for, since it queries, via SRV records, various services in the _mscdc zone of your domain. For example: _ldap._tcp.dc._mscdc.mydomain.me. Sure enough, those responses quickly answered with a “no such name.” So that's not causing the slowdown (well, very slightly, but nothing really worth mentioning).

Because DNS wasn't working, it started try alternate methods of locating a domain controller. It started sending NetBIOS Name Service broadcasts on UDP port 137. It also started sending multicast queries to 224.0.0.252 on UDP port 5355, which is Link-Local Multicast Name Resolution. I wondered if I disabled both of those methods if it would increase my unlock speed. It did! If I'm on the LAN (or VPN'ed in), DNS works just fine, so I don't need these fallback methods. Perhaps there's more I could have done, but I was satisfied with my results. The method behind those results I explain in the next paragraph...

Disabling NetBIOS over TCP/IP Manually and via DHCP

To disable NetBIOS over TCP/IP manually, go into the TCP/IP settings in Windows 7/8/10. Go to Advanced, WINS, Disable NetBIOS over TCP/IP.

For DHCP, you can search the Internet for how to disable this via various DHCP server software. Since I run OpenWRT at home, I'll focus on that. DHCP option 43 is the “vendor specific” attribute. As for the other parts of it, I won't go into that at this point. OpenWRT runs dnsmasq for IPv4 DHCP. The syntax for setting NetBIOS via option 43 for dnsmasq can be found here. To adapt that to OpenWRT, just add the following line to /etc/config/dhcp under the config dhcp 'lan' context:

config dhcp 'lan'
  list 'dhcp_option' '43.01:04:00:00:00:02'

Disabling Link-Local Multicast Name Resolution

There is no DHCP option for disabling Link-Local Multicast Name Resolution, so it has to be done on the device itself via registry entry at:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient

Create a DWORD value called EnableMulticast with a value of 0.

Hopefully your domain computer “logs in” and unlocks faster via cached credentials, even when you're out of communication with a domain controller.

windump and pcap for Windows and interface name enumeration

Tonight I took the plunge: I moved from winpcap and windump from Riverbed (formerly from CACE and before that from Politecnico di Torino) to npcap. There are lots of great reasons discussed on the npcap page, not to mention that winpcap hasn't had an update since 2013.

Even though I installed it with winpcap compatibility, I still got an error when running windump. That was fixed by installing WinDump for Npcap (see the Releases section for pre-compiled binaries).

It has always bothered me that enumerating interfaces using windump -D was more luck and trial-and-error than actually being able to see which interface you want to dump. So I wrote a little batch file called listif.cmd that will give me a nice list so I can run windump -i # to dump my packets. Besides windump itself, it doesn't require anything that doesn't come with Windows.

@echo off

setlocal ENABLEDELAYEDEXPANSION

set LIST=%temp%\getmac-list.txt

echo Getting available adapter list...
getmac /fo csv /v > %LIST%

echo Resolving available adapter list...
for /f "tokens=1,3 delims=.{}" %%a in ('windump -D') do (
 for /f "tokens=1,2 delims=," %%m in ('findstr "%%b" %LIST% 2^>nul') do (
  set CONN_NAME=%%m
  set ADAPTER_NAME=%%n
  echo  %%a. !CONN_NAME:"=! (!ADAPTER_NAME:"=!^)
 )
)

First Hop Redundancy Protocol ARP Problem

Let me start by saying that this article is Cisco-specific, though it applies to IOS, IOS-XE, and NX-OS. I’ve not used IOS-XR, so I don’t know about that one.

When using an FHRP, like HSRP or VRRP, you can’t “force” a router to cause another device to update its ARP table simply by pinging it, as you can with an actual interface IP address. This could create a situation where you want to convert a single router into two redundant routers, but you don’t have access to clear the ARP table on the other devices in the network.

Sometimes it’s not even necessary to worry about MAC changes. For example, imagine I have an ASA with an address of 10.91.50.1 pointing to 10.91.50.254 for its next-hop router. I have one router with interface Gi0/0 configured as 10.91.50.254 with a MAC address of f40f.1bbf.01b0. Let’s say I change the interface address to 10.91.50.252 and make 10.91.50.254 the VRRP address, which yields a MAC address of 0000.5e00.015b. The ASA will continue to think that 10.91.50.254 has a MAC address of f40f.1bbf.01b0, that is until its ARP cache times that entry out. And this is perfectly okay! The router will continue forwarding those packets on. When the ARP cache times out and the ASA does an ARP request for 10.91.50.254, it will learn the new VRRP MAC address of 0000.5e00.015b and all will be well.

But what if you want to test failover before you have a chance to let the ASA time-out its ARP table? Or what if you don’t have access to the ASA to see what it has in its ARP table (is it pointed to the burned-in MAC or the VRRP MAC)?

In that case, maybe we can “force” an update on the ASA (or whatever else) without having access to it. Let’s try (from the router):

router# ping 10.91.50.1 source 10.91.50.254
% Invalid source address- IP address not on any of our up interfaces

Unfortunately, it doesn’t let us. However, if you do an extended ping, it does let you:

router# ping

Protocol [ip]:

Target IP address: 10.91.50.1

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Ingress ping [n]:

Source address or interface: 10.91.50.254

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0x0000ABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.91.50.1, timeout is 2 seconds:

Packet sent with a source address of 10.91.50.254

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Boom, ARP table updated on remote device. I would say that the fact you can’t ping it while specifying an FHRP source interface from the command-line but you can ping specifying an FHRP source from extended ping is an oversight on behalf of the Cisco engineers. Oh well, it is what it is.

By the way, this works on IOS for both HSRP and VRRP addresses. On my Nexus 7010, version 6.2(16), you can even specify the source IP address from the command-line, instead of having to go through the extended ping interaction. For example: ping 10.200.5.218 source 10.91.50.254.

Workaround for “Windows AD domain is the same as my company’s primary DNS domain name,” Part 2

Previously I wrote about a Workaround for “Windows AD domain is the same as my company’s primary DNS domain name.” It involved installing a tiny web server on each domain controller. Today I'm going to write about an alternative way...

Let’s say my organization is “sojourners.me” and I use that for my internal Active Directory domain name (yes, not recommended) as well as the public face of my organization. It’s bad because people inside the network don’t resolve “sojourners.me” to the public webserver--they resolve it to the internal domain controllers (which is required for DFS to function properly).

Here’s a workaround... proxy autoconfiguration magic.

function FindProxyForURL(url, host) {
  if (shExpMatch(host, "sojourners.me"))
    return "PROXY proxy.sojourners.me:3128; DIRECT";
  else
    return "DIRECT";
}

If you’re interested in more info on FindProxyForURL, there are good references here and here.

You may say, “We don’t use a proxy server at my company. Our users don’t have proxy settings in their browsers.” For Windows AD-joined machines, a proxy autoconfiguration script can be easily rolled out via Group Policy Object. You can use your favorite search engine to search for “proxy auto configuration script gpo” or words to that effect. In the past, doing this on Firefox was more of a pain, but in the last few years they made the default proxy option to use the system proxy settings. As an alternative to GPO, you can play with DHCP and/or WPAD settings or get creative.

What should that auto configuration script point at? Using Squid, Apache proxy module, NetsScaler (like we have), or another proxy server of your choice, you can easily run a proxy service that won’t have to do much. In fact, with the script above, the only proxy requests it will have to handle are the ones to send it to the public web server, which should then send a HTTP 301 or 302  redirect to “www.sojourners.me.”

In a DNS Bind

Recently a friend, who also works in IT, asked me, “What DNS server do you guys run?” I had to think for a second, because I wondered where to begin. It’s not a quick, easy answer.

Note that I use the term “domain” and “zone” more-or-less interchangeably in this post.

Internal

We run Windows Server 2012r2 DNS on our domain controllers, as many organizations with Active Directory infrastructure do: DNS is critical to its operation. We also make extensive use of dynamic DNS with DHCP integration. We don’t use external caching servers or anything like that for our internal network. Every workstation and IoT device is pointed at two of our domain controllers. You can get away with that when you work at a company with less than 5,000 devices. We did a Cisco Umbrella (formerly OpenDNS) pilot recently, but besides their on-premises server that augments the DNS a bit, it’s more-or-less Microsoft AD DNS as the star player.

“Semi-Private”

We have business partners that have trust relationships with our Active Directory. However, we don’t give them direct access to our internal Active Directory servers. They configure their DNS to perform “Conditional Forwarders” to us. What they actually hit are two Unbound DNS servers running on Windows Server 2012r2. Unbound is very flexible caching name server software. We use it because we want them to see “parts” of our internal network, but also “parts”of our public DNS... basically we use Unbound to override parts of our public space with private resolution, then whatever we don’t override gets sent on to our public DNS servers. We also do extensive NAT’ing, so we need to override the internal IP addresses as well.

Public

We used to use the free GoDaddy DNS service that came with domain ownership purchased through them. However, after the DDOS attacks on Dyn on October 16, 2016, we decided that we should diversify DNS providers. In addition, we had just purchased a new /24 IPv4 range as well as wanting to take control of the reverse lookups for the two /27 subnets we lease from one of our ISPs. We upgraded to GoDaddy’s Premium DNS and employed DNS Made Easy as our second provider. While they are providing secondary services for our main three zones, they are providing primary services for the PTR records for our two /27 subnets, our /24, as well as our IPv6 subnet’s ip6.arpa zone.

Notify Me!

We quickly discovered that there were some problems with this arrangement... namely in the way that our providers handle NOTIFY messages. In case you’re not aware, NOTIFY messages are an important component of keeping DNS servers in sync. If I change a record on my primary DNS server and NOTIFY is not functioning properly, it will take up to the refresh interval specified in the zone’s SOA record to replicate to the secondary. Actually, without NOTIFY, it’s the responsibility of the secondary server to “reach out” to the primary when it’s refresh interval is reached. If NOTIFY is working properly, the primary server reaches out to its secondaries to tap them on the shoulder and say, “Hey, I have some new information, ask me what it is,” at which point the secondary will issue an IXFR or AXFR transfer request.

Problems

The problem we found is that GoDaddy will only send NOTIFY messages to DNS servers defined as NS records for a particular domain. However, DNS Made Easy will not listen for notify messages on its authoritative servers--they have their own set of servers that listen for NOTIFY messages. GoDaddy offers no way to add those servers to an “also-notify” list. I sent trouble tickets to both companies, and (eventually) they both agreed that it was a problem. They also both said that this was a low priority thing as nobody else besides me seemed to care, and basically said they’ll get to it some day (insha’Allah, as our Arab friends would say).

BIND to the Rescue

ISC’s BIND software is insanely flexible. We ended up setting up a virtual private server with Linode whose $5/month role was primarily to act as a broker between two grumpy DNS providers who didn’t want to share nicely. It’s like the referee at the beginning of the boxing match that forces the boxers to shake hands. The BIND set up is pretty simple: in our options section, we have defined a max-refresh-time 120 that tells it to check the serial number on the primary server every two minutes. Then in our relevant configurations, we have also-notify { dnsmadeeasy-slaves; }; with the dnsmadeeasy-slaves defined in the masters section. In addition, we have notify-explicit; which ensures that the BIND server notifies the secondary (slave) servers upon discovery of a change. GoDaddy has a place to define an access-list that allows the BIND server to initiate a zone transfer. The BIND server also allows the DNS Made Easy servers to transfer the zones from BIND.

Final Answer

To answer my friend’s original question (which at this point he probably wished he hadn’t asked), I guess we’re running five different interfaces (Windows, Unbound, GoDaddy, DNS Made Easy, and BIND). I’m not sure which DNS software the providers are running, since the cute little BIND trick has been overridden (try nslookup -type=txt -class=chaos version.bind. 208.80.126.2). It’s amazing how much more complicated something can turn out to be beyond what you had originally intended.

The Point

Besides simply explaining what our crazy DNS set up is, my point is that if you know the technology well enough, you can leverage the right tool to get the job done. If you have to learn a new configuration file format, that’s not a big deal if you have an idea of what’s supposed to happen. One of the things I also tell my colleagues is that the software is supposed to serve you, you are not supposed to serve the software.

Workaround for “Windows AD domain is the same as my company’s primary DNS domain name”

I have seen many companies over the years who have their internal domain set as the same domain that their corporation uses publicly. For example, if my company is Example, Inc, my primary web and e-mail presence might be example.com. When my Windows NT 3.5 domain was set up in 1997, we called it EXAMPLE, as it seemed logical. When Windows 2000 came out and we upgraded to Active Directory, it became logical to create example.com as the AD DNS Name. The recommendation is to NOT do that, but for many it was done before the recommendations were widely published (or they didn't think to look), and they simply have to live with it.

Years ago, most non-technical users (in my estimation) believed there was something magical about the “www” portion of a web address. For example, “www.example.com” was any given company’s web site. However, more and more people are dropping the “www” and just going to “example.com”. It’s the responsibility of the IT people (DNS and web administrators) to make sure the DNS A record for @ (domain root) points to the web server address, and the web admin must make sure the site answers for www.example.com and example.com and presents the same content to both (or redirects one to the other).

Here comes the problem in the first paragraph. For one thing, it requires split DNS: there is a public “version” of all the example.com records, and a private version. Within an Active Directory infrastructure, the private version of example.com (with no host name specified) should resolve to the IP address of all the domain controllers. For example, if I have three domain controllers, nslookup example.com should return 10.1.1.5, 10.1.2.5, and 10.1.3.5, assuming those are the addresses of my DCs. Most likely, the domain controllers are also not hosting the public web site (and they sure shouldn’t be!). This means that if I’m inside the network, pointing to internal DNS servers and I type example.com into my web browser, I won’t get anywhere.

The simplest solution I found in that case is to redirect the request to www.example.com, which can point to the public address of the public web server--what people expect to hit when they type in example.com internally. To do this, we could install IIS on every domain controller and set up a HTTP 301 or 302 redirection to www.example.com. But installing IIS on every domain controller adds overhead, etc, to the box, as well as lots of new DLLs and other things to introduce security problems (anyone remember Code Red?).

Another solution is to use ncat and NSSM (the Non-Sucking Service Manager). ncat can sit in memory with the help of NSSM and simply redirect http queries to the box to www.example.com. All that is needed is two exe files and one batch file to be copied to each server. Here’s how it could be done.

redir.cmd
@echo off
echo HTTP/1.1 302 Found >%temp%\redir.txt
echo Location: http://www.example.com/ >>%temp%\redir.txt
c:\redir\ncat -l 80 < %temp%\redir.txt


Put all three files (ncat.exe, nssm.exe, redir.cmd) in c:\redir. Then install the service using nssm with the following command (run as administrator):

nssm install "Web Redirector" c:\redir\redir.cmd

You could even deploy it to all your DCs remotely. You could do it your way, or using something like this:

deploywebredir.cmd
@echo off

setlocal ENABLEDELAYEDEXPANSION
set DCLIST=\\

for /f "delims=. " %%a in ('nltest /dclist:%USERDNSDOMAIN% ^|findstr /c:"[DS]"') do (
 md \\%%a\c$\redir
 for %%b in (ncat.exe nssm.exe redir.cmd) do copy /y %%b \\%%a\c$\redir
 set DCLIST=!DCLIST!%%a,
)

set DCLIST=%DCLIST:~0,-1%

psexec %DCLIST% -e c:\redir\nssm install "Web Redirector" c:\redir\redir.cmd


If you’re not familiar with psexec or nltest, you should get up to speed! Just search for them in your favorite search engine.

If you want to make this more secure, define a user with no particular privileges (besides Log on as a Service) and set the service to run as that user. Even if someone buffer overruns ncat.exe, they will only have basic user access.

Application Performance II

I thought I would just tell a few quick stories about my encounters with application efficiency and how the network was blamed. In the spirit of humility, I'll offer where I feel I did poorly and where I did well, and what lessons I learned.

City Police Database
The biggest, most obvious example of this was when I was doing some consulting work for a city government, which shall of course remain nameless. They had gotten a new application (and when I say new, I mean it--it had not been seriously proven in any other installations). I was asked to make the application high-availability. The application was not ready to be installed yet, but I was to do the up-front work. The parameters were thus:

• We don't want to buy any new network equipment
• The redundancy must go across multiple sites, which are connected by DS3 links several hops away.
  

So I devised a method I thought was pretty good to fit these parameters. It used pre-existing Cisco 3845 routers: one at the "main site" and one at the "backup site." The 3 servers that made up the program (two application servers and one database server) went on a new VLAN that was routed by the 3845. The VLAN at the main site had one particular IP subnet and the VLAN at the backup site had another subnet. But each server had a loopback interface, and those interfaces were the ones that DNS pointed to. The 3845 at the main site used Cisco's IP SLA with tracking, tracking the application's TCP port on it's physical address. If the application went down, it stopped advertising the loopback /32 via EIGRP. The backup site would then start advertising, because it had a route to that /32 address but with an administrative distance of 200, which is lower than EIGRP's external administrative distance of 170.

All that is background, which is actually not related to my point. All of this redundancy stuff should probably not have been put in, at least without a careful up-front study of the application itself. That's another lesson: do your homework first, and save a lot of headache. If you have built a Cadillac simply to transport monkeys, you've probably wasted your time and efforts (and the customer's money). My personality type is ISTP, which if you know psychology, tells you why I went ahead and did all this.

It turns out that the application was horribly written in many ways--it didn't run as a service, it ran as a user-level program, so we had to set the servers to auto-login, etc. But the biggest problem was, and the point of this section, the performance. It had never been load-tested, nor had it been run over anything less than a gigabit network. So when it was slow, it was of course the fault of the network, and more specifically, the network engineer who obviously didn't know what he was doing.

Here's what we determined after I did a careful analysis of the application (without seeing any code or finding this out from the programmers who didn't speak English very well). The client component of the application, which sat on the user's workstation, was doing SQL queries in the background. Instead of doing a query like:

• select COMPONENT from TABLE where SOMETHING > 100;

it was doing something like:

• select * from TABLE;

then once it downloaded the huge amount of data, it would "post-filter" that. Yes, definitely a network problem when every query resulted in the downloading of over 100 megs of data, which would then be weeded out by the client software just to show 10 records.

It was really difficult maintaining humility in this, and I must confess that though I did maintain humility while investigating, I blew a gasket once I discovered the problem.

Pharmaceutical Database
There was a particular pharmaceutical company I consulted for who wanted a fast link between their main site and another site where many users were as well as off-site backups sat. They already had a DS3 between the sites, but they wanted to put in an additional 100 Mbps connection, which they did. I then configured all the routers, etc, to route things primarily down the 100 Mbps connection and secondarily down the DS3.

Everything was fine and we verified the routing was going the correct way, etc. But then the database backups started going much slower than they had before. After investigating, I discovered that the DS3 ran more-or-less directly from their office in West Bend, WI, to the office in Waukesha, WI. However, the 100 Mbps connection ran from West Bend, WI, up to the CO in St Paul, MN, then down to Waukesha, WI.

Obviously, the latency over the 100 Mbps connection was significantly more (25-30 milliseconds) than the latency over the DS3 since the distance was so much further. This can be understood here. So this was a network problem, if you will. However, again, the way the database was synchronizing, it was doing thousands of little queries, rather than a bulk transfer.

Here were some possible solutions, in no particular order.

1. Modify all the computers to use a higher TCP window size using the Window scale option. Without window scaling, you have to consider latency when determining the maximum speed of a TCP session. It goes like this:
   
   Window Size (bytes)
   ------------------- * 8 bits/byte = bps
   Latency (sec)
   
   So 65535 / .025 * 8 = ~21 Mbps. So we could not get more than 21 Mbps from this connection.
   
2. Make the syncing go over the DS3.
3. Ask the programmers re-write the way the database synchronizes.
4. Make the carrier reroute the 100 Mbps connection.
   

First we enabled TCP window scaling option for the two servers that needed to synchronize across this connection. That didn't seem to help. Then we dug into just how the application was working and discovered the little queries that made the syncing work, which would be unaffected by window sizing. So we tried option 3, because it was what we determined to be the best. The programmers laughed and said it was a networking problem and it was our fault because it used to work better. We probably should have pushed them harder and gotten management involved more, but we didn't. We tried option 4 but that was impossible because the carrier was based in MN and would have charged roughly a bazillion dollars to run fiber directly between the two sites, and this carrier was originally chosen precisely because they did a good price/sales job on the management.

Ultimately we made the syncing go over the DS3 using offset lists in EIGRP for /32 routes for those two servers. That also meant that there would be asynchronous routing when anything communicated across the WAN with one of those two servers (besides the server-to-server communication of course). No one cared, as long as it "worked better" and redundancy was there.

Two lessons from these experiences:

• Do your homework! Don't rush ahead without asking a lot of good questions. Some things may seem obvious based on your past experience, but don't assume.
• If you determine something to be the best option and it gets laughed off by the people you're suggesting it to, go to management ready to explain all the ins-and-outs of the problem as you understand it.
• Whatever your personality type, attempt to show restraint in running ahead with solutions. Brain-storm, but remember that brainstorming is not meant to be implemented on a whim. Sleep on it and run it by colleagues and other smart people.
  

Remember, work as a team to get it resolved. If you blame someone else, try to put yourself in their shoes and always speak with humility and remind people you are on the same team--you just want to find the best solution. This kind of thinking is often contagious, and usually management will appreciate it. Of course, this isn't always true, and you can't control other people, but if you keep your cool, things will go better, at least for you.

Application Performance and the Jesus Way

Application Efficiency, Part I
The website Ethereal Mind, which I often read, had a recent post in response to another post by Matthew Norwood entitled Programming Bad Performance. It touched on something every network engineer feels when application performance is slow somewhere on the network. It's a topic I have dealt with a lot in my professional career so I uncharacteristically weighed-in with a comment, which I present below in a modified form...

It seems that the onus, or bur­den of proof, is often on the net­work engin­eer to fig­ure out just what the prob­lem is, since the net­work is this mys­ter­i­ous entity that most people don’t know much about. I have found two types of server admins in my exper­i­ence:

• The ones that assume it’s their prob­lem and never think about the net­work, but then it proves to be a net­work prob­lem (often when attempt­ing to estab­lish com­mu­nic­a­tion between a ser­vice net­work and an internal net­work).
• The ones that assume (along with all the users, usu­ally) that it is a net­work prob­lem and very quickly start point­ing fin­gers.

I have found that over the years I have learned a lot more about effi­cient data­base pro­gram­ming, ana­lyz­ing server cpu, memory, and disk util­iz­a­tion, etc, than I ever wanted to, as a means to simply find what the real prob­lem is. Greg at Etherealmind points out that prov­ing it’s not the net­work, or at least cast­ing plaus­ible reason to believe it’s not, will get you home on time. I agree with that, but in a world of people say­ing, “It’s not my prob­lem” and wash­ing their hands of it, I want to put forth a little more effort to get to the bot­tom of things.

Something else that I have learned is that humil­ity is really import­ant. If you start act­ing cocky and the prob­lem turns out to be yours, you really look like, and are, a jerk. Taking more of a “Let’s fig­ure this out together” atti­tude is much more likely to lead to suc­cess and team unity in the end. The real art is being able to foster and main­tain that atti­tude when other people seem to be out for blood.

The Jesus Connection
I'll make this my first post that crosses my two categories of blogging. Wanting to live life in a way that Jesus would do it, the previous paragraph helps see one or two ways of doing that. The bible often speaks of humility... three places that jump out to me:

• Do nothing out of selfish ambition or vain conceit. Rather, in humility value others above yourselves, not looking to your own interests but each of you to the interests of the others (Philippians 2:3-4).
• For those who exalt themselves will be humbled, and those who humble themselves will be exalted (Matthew 23:12).
• When pride comes, then comes disgrace, but with humility comes wisdom (Proverbs 11:2)

Unity is also key to solving problems. It's amazing how humility and unity go together as well (I think that's pretty obvious). If everyone is cocky, it does not help team unity--it just creates divides. Be completely humble and gentle; be patient, bearing with one another in love. Make every effort to keep the unity of the Spirit through the bond of peace. There is one body and one Spirit, just as you were called to one hope (Ephesians 4:2-4).

Three of my favorite topics: humility, unity, and hope!

Home Router and DD-WRT

I just discovered DD-WRT , which is replacement firmware supporting a large number of SOHO routers (e.g., Netgear, Linksys, D-Link, etc). I tried it on my new D-Link DIR-615 and so far it seems to be working well. One of the big things I was going for was QoS (Quality of Service) which can prioritize things based on some criteria. For example, I prioritized Skype so my wife and I can have good conversations with people back in the US, even if someone else is transferring a large file.

There are a lot of other slick features as well, for example, there are instructions on how to create a tunnel with popular brokers, such as SixXS and Hurricane Electric.

Since DD-WRT is Linux, it opens up a world of possibilities as well, for example, ssh access combined with Dynamic DNS allows remote logging in for testing purposes, etc.

IPv6 with Cisco ASA, Windows 2008, Linux

It's my first blog post in nearly a year. One of my new years resolutions is to post at least three times/week. We'll see how it goes.

Recently I was implementing IPv6 using the devices mentioned above. The Cisco ASA firewall code was 8.2(1), which supposedly supports IPv6... it seems unless you have a failover pair. If you set a static IPv6 address, the IPv6 on the interfaces will shut themselves down because of a DAD (duplicate address detection) failure as both the active and the standby firewalls will assume whatever address you put in. With IPv4, you can enter a "standby" address on each interface so that won't happen. The way around it on a failover pair is to use the EIU-64 address (the prefix+the 48-bit MAC address and padding between the vendor part and the device part). Therefore, both firewalls will have unique addresses and there will be no conflict. The problem with this is:

• The addresses become full sized monsters
• The address will change in the event of the standby firewall going active
  
• Both firewalls give out RA (router advertisement) messages

With Linux, if I hard-code a default route, it will pay attention to that, primarily. If I hard-code a default route in Windows 2008, it seems to simply add it to the other ones it obtained via the RA messages it received. As a result, IPv6 will be quite flaky on Windows with two routers, if one is not forwarding traffic (in the ASA world, the standby firewall will not route anything).

I can think of two solutions:

• Upgrade the ASA to 8.3 code, which allows IPv6 failover commands and should work fine. The problem with this is that you will have to upgrade the RAM, which is a pain.
• Suppress the RA messages from the ASA. This can be done with the " ipv6 nd suppress-ra" interface configuration command.

Obviously the first solution is better, but the second one works if upgrading is not possible.

Cheers!
Matt

IPv6 and You (and me)

A whole lot of articles have been written about IPv6. I'm just now starting to take seriously the importance of knowing it, as more and more sites are predicting the impending depletion of public IPv4 addresses. My take, and I'm certainly not unique here, is that it will be more important at the Internet edge than on internal corporate networks.

I think that internal networks will run parallel IPv4 and IPv6 for a long time. I think the IPv4 stack will be used for almost all internal communication, while IPv6 will start to get used for communication to Internet-based IPv6-enabled hosts.

If I were a company, I would start to bug my ISP for a block of IPv6 addresses to tinker with. Set up the routers and the Internet firewalls for starters. Put an IPv6-only test server or two on a service network and see about getting them functioning. Once some of those tests are done, see if you can get a few hosts on the internal network connecting to that server using IPv6.

One of the problems, at least for a lot of small/medium-size Cisco customers I know, is having layer-3 switches that support IPv6. Many customers of this size rely on the IP routing capabilities of switches such as the 3560 and 3750. Even the base image is capable of static routing (as well as RIP and EIGRP stub). However, to route IPv6, one needs to upgrade them to Advanced IP Services, a significant cost. So, what are the options?

• Don't allow IPv6 on the internal network.
• Cough up the money to upgrade all switches doing routing to Advanced IP Services.
• Hang a router or routers off a "core" switch that can route IPv6 between VLANs; this isn't viable if any kind of hierarchical scheme is in place.
• Take the opportunity to replace the hardware for all switches doing routing to a model that supports IPv6.

Then of course you have to assign the addresses. You can use the IPv6 stateless address autoconfiguration (SAA), but that doesn't give out information like DNS server addresses, etc. Perhaps it could be used for servers where you statically assign its DNS servers, but leave the rest to SAA. If this is done, certainly care needs to be taken because my understanding is that the 64-bit prefix is combined with the 64-bit interface identifier. If this is the case, the server's address would change if the MAC address of the NIC changed. So then perhaps static addresses are better. But wait, IPv6 has a slick built-in feature for magically renumbering a network. I must still ponder this... Obviously clients can just use DHCPv6 or a SAA in combination with DHCPv6...

I've written enough now to prove how much more I have to learn. The process goes on...

Cheers.