What is GLBP?

GLBP is a protocol for load balancing routers but make them appear to be a single router to other devices on a network. GLBP stands for gateway load balancing protocol. An example of a situation where this could be used is for balancing between two broadband connections for a small to medium office. As far I as am aware it will only work with cisco routers and nobody else support the GLBP protocol. A full description can be found on the cisco web site for the command reference.

How does it work?

It works the same way as other redundant gateway protocols work. Like HSRP or VRRP. However in GLBP instead of one or other router being the active gateway both routers share an ip address to make them both active in the setup. So as an added benefit of load balancing you can also have the added benefit of redundancy for free. It is possible for the device to share a single ip address because it will only ever advertise one mac / arp address to each host that requests the gateway.

Where is the benefit?

What it will not be able to do is to double an internet connection bandwidth to a single machine when nat is involved. What it will do is spread the load from multiple machines into two or more internet connections. So it is best suited to growing offices where there are too many people for a single internet connection but not yet enough to consider getting a costly leased line.

More...

Sometimes devlopers just don't get it right! Here is a great example on an open source project where they have managed to get a script really really wrong.

The original problem is here and the problem is a simple typo in the install / upgrade scripts for the package. Where a space has been inserted into command line which seperated the single argument into the command line into two parts.

The command was really meant to be

rm -rf /usr/lib/nvidia-current/xorg/xorg

But was accidently

rm -rf /usr /lib/nvidia-current/xorg/xorg

For the non linux / unix people out there this is the same as removing the "Program Files" folder from the machine when the package was installed.

Ouch!

Something that is a common problem in mssql server is deleting a very large number of rows from a table. Normally due to locking the table that the very long delete is running on. There is a few common ways of doing this. Mostly by setting row count and looping though a delete until it runs out of rows to delete. In sql server 2008 it is also possible todo this by moving the data from one table to another using a delete and the output clause.

SET ROWCOUNT 5000
WHILE (1 = 1)
BEGIN
	BEGIN TRAN
	DELETE FROM T WHERE N > 5000
	IF @@ROWCOUNT = 0
		BREAK
END
SET ROWCOUNT 0

Or like this

SET ROWCOUNT 5000
WHILE EXISTS(SELECT * FROM T WHERE N > 5000)
BEGIN
	DELETE FROM T WHERE N > 5000
END
SET ROWCOUNT 0

But what if we also wanted to take a backup of the data at the same time as we delete it. Just incase we have made any mistakes. Well this is possible using the OUTPUT DELETED clause in mssql server using the following code. Of course you will need to create the table we are going to backup to just prior to running this. In this example we are using T as the main table and TBackup as our backup table that we are moving data to.

SET ROWCOUNT 5000
WHILE EXISTS(SELECT * FROM T WHERE N > 5000)
BEGIN
	INSERT INTO TBackup
		SELECT * FROM (
			DELETE FROM T
				OUTPUT DELETED.*
				WHERE N > 5000
		) a
END
SET ROWCOUNT 0

So now we have all the data we wanted out of the main table into a second table. This may be purged later or we are simply moving things into an archive table.

Something that isn't support by default in asp.net is the ability to have end users login using either their username or their email address. Though it is somewhat easy to add this support using this little trick to override the normal login procedure on the login control.

To get started we will need our aspx page with a login control as follows.

<asp:Login runat="server" ID="Login2" DisplayRememberMe="false" 
    DestinationPageUrl="/Users/Default.aspx" onloggingin="Login2_LoggingIn" >
</asp:Login>

We can then override the default action in the event handler if we cannot find the current user trying to login and the username contains an '@' symbol.

public partial class Login : AppPage
{
    protected void Page_Load(object sender, EventArgs e)
    {

    }

    protected void Login2_LoggingIn(object sender, LoginCancelEventArgs e)
    {
        if (Login2.UserName.Contains("@") && Membership.GetUser(Login2.UserName) == null)
        {
            string Username = Membership.GetUserNameByEmail(Login2.UserName);
            if (Username == null)
                return;

            if (Membership.ValidateUser(Username, Login2.Password) == true)
            {
                FormsAuthentication.SetAuthCookie(Username, false);
                FormsAuthentication.RedirectFromLoginPage(Username, false);
                e.Cancel = true;
            }
        }
    }
}

Note: if you are going to use the above you will need to make sure that your configured provider has a unique set of email addresses per user.

I seem to keep running into a problem with a cisco router (a cisco 877) with a virgin media connection. It would appear that part of virgin's network tends to break. I don't know the exact cause but from how I understand it. It is a fault with virgin somehow and some type of compatibility issue with cisco routers.

The problem for me tends to trigger when virgin has an issue inside their network or for some reason I have to disable the internet connection. When I bring the connection back up the cisco router can never successfully get an ip address by dhcp again. Until of course virgin is contacted and something is reset at their end. It will however allocate an ip address to a computer if you plug it directly into the virgin connection.

Here is how I was debugging the issue. To start with put your cisco terminl connection into monitor mode and debug dhcp (after you become an enabled user of course). Like this

Cisco#terminal monitor
Cisco#debug dhcp

This will cause you to see output like the following.

Jun  6 08:51:39.998: DHCP: deleting entry 83D002B8 0.0.0.0 from list
Jun  6 08:52:09.437: DHCP: Try 15 to acquire address for Vlan2
Jun  6 08:52:09.441: DHCP: allocate request
Jun  6 08:52:09.445: DHCP: new entry. add to queue, interface Vlan2
Jun  6 08:52:09.445: DHCP: SDiscover attempt # 1 for entry:
Jun  6 08:52:09.445: DHCP: SDiscover: sending 290 byte length DHCP packet
Jun  6 08:52:09.445: DHCP: SDiscover 290 bytes
Jun  6 08:52:09.445:             B'cast on Vlan2 interface from 0.0.0.0
Jun  6 08:52:13.006: DHCP: SDiscover attempt # 2 for entry:
Jun  6 08:52:13.006: DHCP: SDiscover: sending 290 byte length DHCP packet
Jun  6 08:52:13.006: DHCP: SDiscover 290 bytes
Jun  6 08:52:13.006:             B'cast on Vlan2 interface from 0.0.0.0
Jun  6 08:52:17.006: DHCP: SDiscover attempt # 3 for entry:
Jun  6 08:52:17.006: DHCP: SDiscover: sending 290 byte length DHCP packet
Jun  6 08:52:17.006: DHCP: SDiscover 290 bytes
Jun  6 08:52:17.006:             B'cast on Vlan2 interface from 0.0.0.0
Jun  6 08:52:28.568: DHCP: Received a BOOTREP pkt Not for us..:  xid: 0x3E466ABF%Unknown DHCP problem.. No allocation possible
Jun  6 08:52:29.924: DHCP: Waiting for 60 seconds on interface Vlan2

Unfortunatly the information is not very forthcoming with anything that matters. Since virgin is not actually replying to any dhcp requests with anything! So the next step to try is to reboot the cable modem etc... Of course it will just keep repeating the same output as above and virgin will continue to ignore any dhcp requests for some reason.

The next part of this is to phone virgin. Tell them specificly that the router is not allocating an address. They will then head off do some checks make sure they can talk to the cable modem directly and quitly reset something. Of course on the next attempt you can then expect some sort of success.

Jun  6 08:57:31.489: DHCP: Try 19 to acquire address for Vlan2
Jun  6 08:57:31.493: DHCP: allocate request
Jun  6 08:57:31.497: DHCP: new entry. add to queue, interface Vlan2
Jun  6 08:57:31.497: DHCP: SDiscover attempt # 1 for entry:
Jun  6 08:57:31.497: DHCP: SDiscover: sending 290 byte length DHCP packet
Jun  6 08:57:31.497: DHCP: SDiscover 290 bytes
Jun  6 08:57:31.497:             B'cast on Vlan2 interface from 0.0.0.0
Jun  6 08:57:35.106: DHCP: SDiscover attempt # 2 for entry:
Jun  6 08:57:35.106: DHCP: SDiscover: sending 290 byte length DHCP packet
Jun  6 08:57:35.106: DHCP: SDiscover 290 bytes
Jun  6 08:57:35.106:             B'cast on Vlan2 interface from 0.0.0.0
Jun  6 08:57:39.106: DHCP: SDiscover attempt # 3 for entry:
Jun  6 08:57:39.106: DHCP: SDiscover: sending 290 byte length DHCP packet
Jun  6 08:57:39.106: DHCP: SDiscover 290 bytes
Jun  6 08:57:39.106:             B'cast on Vlan2 interface from 0.0.0.0
Jun  6 08:57:39.154: DHCP: Received a BOOTREP pkt
Jun  6 08:57:39.154: DHCP: offer received from 62.31.64.115
Jun  6 08:57:39.154: DHCP: SRequest attempt # 1 for entry:
Jun  6 08:57:39.154: DHCP: SRequest- Server ID option: 62.31.64.115
Jun  6 08:57:39.154: DHCP: SRequest- Requested IP addr option: x.x.x.x
Jun  6 08:57:39.154: DHCP: SRequest placed lease len option: 603658
Jun  6 08:57:39.154: DHCP: SRequest: 308 bytes
Jun  6 08:57:39.154: DHCP: SRequest: 308 bytes
Jun  6 08:57:39.154:             B'cast on Vlan2 interface from 0.0.0.0
Jun  6 08:57:42.110: DHCP: SRequest attempt # 2 for entry:
Jun  6 08:57:42.110: DHCP: SRequest- Server ID option: 62.31.64.115
Jun  6 08:57:42.110: DHCP: SRequest- Requested IP addr option: x.x.x.x
Jun  6 08:57:42.110: DHCP: SRequest placed lease len option: 603658
Jun  6 08:57:42.110: DHCP: SRequest: 308 bytes
Jun  6 08:57:42.110: DHCP: SRequest: 308 bytes
Jun  6 08:57:42.110:             B'cast on Vlan2 interface from 0.0.0.0
Jun  6 08:57:42.347: DHCP: Received a BOOTREP pkt
Jun  6 08:57:46.347: DHCP Client Pooling: ***Allocated IP address: x.x.x.x
Jun  6 08:57:46.351: Allocated IP address = x.x.x.x  255.255.255.240

Finally it gets an ip address. The reason why I suspect this is a problem inside the virgin network is simple. Evertime I have to take the connection offline I can do it by a shutdown of the interface (the easy method) or by rebooting the cisco or some such. This problem occurs in exactly the same way. However the following at the site end of things never changes.

• The cisco will still manage to get an ip address without being restarted.
• The cisco config has not changed in any way.

To make matters worse. Virgin are not capable of allocating a static ip address to the connection. their definition of static is still allocated by dhcp. So there is no way around this problem.

I guess its just one of thoose things that will never be fixed by virgin media. I think this is a virgin media issue. What do you think?