IConnectIT

Today in preparation for one of my Cisco CCIP exams, I’ve found a rather nice hierarchical overview as to how the BGP routing protocol finds the best route/path. Here’s how it’s done.

1. Ignore routes with an inaccessible next hop address
2. Prefer the path with the highest WEIGHT (Cisco proprietary)
3. Prefer the path with the highest LOCAL_PREF
4. Prefer the path that was locally originated via a network command
5. Prefer the path with the shortest AS_PATH
6. Prefer the path with the lowest origin type
7. Prefer the path with the lowest multi-exit discriminator (MED)
8. Prefer eBGP over iBGP paths
9. Prefer the path with the lowest IGP metric to the BGP next hop
10. Determine if multiple paths require installation in the routing table for BGP Multipath
11. When both path are external, prefer the path that was received first (the oldest one)
12. Prefer the route that comes from the BGP router with the lowest router ID
13. If the originator or router ID is the same for multiple paths, prefer the path with the minimum cluster list length
14. Prefer the path that comes from the lowest neighbor address

Today  I ran into a name resolution issue with my Linux (Ubuntu Desktop) desktop machine that I hadn’t noticed before. Let me try and explain.

On are LAN most servers (and clients) are located in a domain with a domain extension of .local. This is considered (by most MS minded people) to be some sort of standard for local non-public domains, mostly used for active directory domains.

For some reason I had trouble reaching servers in this domain by using the FQDN (Full Qualified Domain Name) from my Ubuntu desktop. I seemed the name wasn’t resolved to an ip-address. To verify that I used the NSLOOKUP command to see if DNS name resolving worked, and…..it did. More

After installing Wireshark om my Ubuntu Desktop I noticed that Wireshard showed no available interfaces to capture packes on. After doing some research on the net I found out that this has something to do with the privileges that Wireshark runs under. In other words Wireshark by default doesn´t allow “non superuser” users to capture packets on the netwerk interfaces.

Here’s how you can solve this issue.

$ sudo dpkg-reconfigure wireshark-common ### This will start a config wizard ###

The following wizard shows up. Make sure that you select “Yes” on the non-superusers question.

$ sudo usermod -a -G wireshark $USER    ### This makes the current user a member of the wireshark group ###

$ sudo reboot ### duh….. ###

Now if you start wireshark again, you should be able to select your intefaces to start capturing.

Need to convert data usage (MB’s) to data traffic (mbps) or vice versa? Here’s a very nice site.

http://web.forret.com/tools/bandwidth.asp?speed=4&unit=TB%2Fm

After upgrading my iMac from Snow Leopard to the brand new Mac OS X Lion (10.7) I was amazed to see that Apple managed to make this OS even more user friendly and better looking than it’s predecessor.

You can see that Apple is investing a lot in creating an intuitive OS that even your 80 year old grandmother could use with ease.

However at the same time a couple of things are now hidden because 90% of the users don’t ever use them.

For instance, the “Library” folder is now not visible anymore from within you Finder. It’s not gone, it’s just hidden. So if you want the Library folder to show up again, just run the following command from your terminal.

chflags nohidden ~/Library/

Your Library folder should now be visible again within Finder. If that’s not the case, you should probably restart Finder. To do so, use this command from your terminal.

killall Finder && open /System/Library/CoreServices/Finder.app

When you many IPSec VPN’s configured on a Cisco ASA, keeping track of all the configured pre-shared-keys (PSK’s) can be difficult.

It’s also not possible to show the configured PSK’s by using the standard “show running-config” or “show configuration” commands because the PSK’s are replaced by ****.

tunnel-group VPNCLIENTS ipsec-attributes
ikev1 pre-shared-key *****

However there’s a very neat command that lets you look into a configuration file instead of just displaying an extract of that file (like “show running-config”), that is called “more”.

When you type “more ?” you’ll see that you can have a look at all kinds of files. More

When surfing the Internet you’ll probably won’t notice when you’re accessing a site over IPv4 or IPv6. If a site is available over IPv6 a browser will prefer that over IPv4 without any notification.

Ofcourse that is a good thing because the network layer should be transparent to all normal internet users. Now being a geek, I myself would like to know when I’m accessing a site over IPv4 or IPv6.

I’ve just found a very nice plugin for Firefox which shows you, in a very nice and easy way, on what IP addresses the site your visiting is available. It’s called “ShowIP”  and can found here.

When you access a site it will show the available IP address in the statusbar of your browser, see the example below.

Today I’ve finished up implementing IPv6 on our network. All systems are now running dualstack IPv4 and IPv6 which means that they are reachable on both protocols.

Also this blog is now available through IPv6. So if you’re lucky enough to have a IPv6 enabled internet connection you’ll automatically connect via IPv6.

At the top of the site I’ve added an IPv6 Check button (provided by IPv6-test.com) and in the widgetsection on the right there’s a IPv6 detector to check how many users are connecting over IPv6 with this site.

There’s a lot of interesting actricles on the net about IPv6. In the upcoming months I’ll be working on rolling out many more IPv6 implemantations so I’ll post some articles about these implementations and the challenges I run into.

If you have any questions about your own IPv6 implementation or if you need a hand configuring your network, please don’t hesistate to drop me a mail at ron@iconnectit.nl

Check below to see the current status of the dictator uninstaller program. Let’s hope these status bars don’t freeze up in the middle of uninstalling procedure. We’ll end up with even more trouble!

Administrators managing  large vSphere HA/DRS clusters without the vNetwork Distributed Switches option will agree, adding VLAN’s (port groups) to clusters using standard vswitches can be a very time-consuming and typo sensitive job.

Imagine you’re an administrator of 16 ESX hosts running in a vSphere HA/DRS cluster. You’re asked to connect a new VLAN (VLAN ID: 100) to the cluster by adding a new tagged port group to all of the hosts within the cluster. More