...

Thursday, August 26, 2010

Misc 49

When talking about big commercial networks, there is always a need for reliability. This reliability comes in the form of redundant network devices: Redundant servers, redundant switches, and redundant routers.
Server farms and clustering are implemented to group servers, and Spanning-Tree Protocol allows for handling of redundant links in switched networks, but what about routers?

Today we'll look at three common redundancy protocols: HSRP, VRRP, and GLBP.

HSRP is one of the first redundancy protocols employed by the IOS. HSRP stands for Hot Standby Routing Protocol, and like what its name suggests, it allows routers to be "hot devices" (think of "hot sites") for each other and automatically come online once it detects that the active router is down. A virtual IP is used for each group, and a virtual MAC in the form of 0000.0c07.ac[groupID] is replied for ARPs. HSRP is Cisco proprietary.

VRRP is the Virtual Router Redundancy Protocol. It is the industry standard for redundancy between routers, featuring lower timers than the HSRP to ensure quicker detection of a failed active router.

GLBP is Cisco's response to the VRRP. GLBP stands for Gateway Load Balancing Protocol. GLBP allows for load balancing across all routers in the standby group. The concept works around a designated router known as the Active Virtual Gateway. All routers, including the gateway, are also known as Active Virtual Forwarders. Each AVF is assigned a forward number tied to a virtual MAC address which they are responsible for responding to. The AVG responds to ARP requests for the virtual IP with the virtual MAC of the AVFs in the group.

The same mechanism used in HSRP is applied if the active AVG goes down. If an AVF goes down, another AVF takes over and the AVG would stop redirecting it to the downed virtual MAC. There are two timers in an AVG, a redirect timer, and a secondary hold-down timer. The redirect timer is the time it takes for an AVG to decide to stop directing hosts to the downed AVF, and the secondary hold-down is the time it takes for the forward number to be freed for reassignment.

In all protocols, there are many ways to trigger a switch over. If the active forwarder becomes unreachable, the standby routers automatically take over. However, we can also set active routers to automatically trigger a switch over by tracking an object (such as a host), or an interface.

Today we'll look at all three protocols with this topology:


The network is split into two parts, the top network (1.1.1.0/24) and the bottom network (2.2.2.0/24). This is the addressing scheme used:

Top:
T1 - f0/0 - 1.1.1.1
L1 - f0/0 - 1.1.1.3
R1 - f0/0 - 1.1.1.4

Bottom:
B1 - f0/0 - 2.2.2.1
L1 - f0/1 - 2.2.2.3
R1 - f0/2 - 2.2.2.4

Assume that we want the virtual IP to be 1.1.1.2 for Top, and 2.2.2.2 for Bottom, we'll first configure HSRP.

On L1, add its f0/0 interface into group 0 of HSRP like this:
in f0/0
standby 0 ip 1.1.1.2


Similarly, on R1, add its f0/0 interface into group 0:
in f0/0
standby 0 ip 1.1.1.2


That is the complete configuration for a basic HSRP topology. Right now, pinging 1.1.1.2 will yield a response. To see who you're really connecting to, simply attempt to telnet in. To simulate a failure, simply administratively shut down the Top interface of the active router. Note the time it takes for the router to recognize the downed peer.

To verify HSRP operation, we can use:
show standby

Now, we'll attempt to change our protocol to VRRP. To do this, we'll type this on both the routers:
no standby 0 ip 1.1.1.2

Then we'll enable VRRP on both routers through:
vrrp 1 ip 1.1.1.2

Test for failure again and you'll realize that the routers recognize the downed peer much quicker. Verification information can be obtained through:
show vrrp

Now we'll switch over to GLBP. Disable VRRP, then enable GLBP using:
glbp 0 ip 1.1.1.2

The first thing I want you to type when the network converges is:
show glbp

On L1 you should see something similar to this:
FastEthernet0/0 - Group 0
  State is Active
    2 state changes, last state change 00:06:33
  Virtual IP address is 1.1.1.2
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 2.104 secs
  Redirect time 600 sec, forwarder timeout 14400 sec
  Preemption disabled
  Active is local
  Standby is 1.1.1.4, priority 100 (expires in 7.128 sec)
  Priority 100 (default)
  Weighting 100 (default 100), thresholds: lower 1, upper 100
  Load balancing: round-robin
  Group members:
    c202.0410.0000 (1.1.1.3) local
    c203.0410.0000 (1.1.1.4)
  There are 2 forwarders (1 active)
  Forwarder 1
    State is Active
      1 state change, last state change 00:06:23
    MAC address is 0007.b400.0001 (default)
    Owner ID is c202.0410.0000
    Redirection enabled
    Preemption enabled, min delay 30 sec
    Active is local, weighting 100
  Forwarder 2
    State is Listen
    MAC address is 0007.b400.0002 (learnt)
    Owner ID is c203.0410.0000
    Redirection enabled, 599.568 sec remaining (maximum 600 sec)
    Time to live: 14399.568 sec (maximum 14400 sec)
    Preemption enabled, min delay 30 sec
    Active is 1.1.1.4 (primary), weighting 100 (expires in 9.564 sec)


At the top, there is FastEthernet 0/0 - Group 0 followed by "State is Active". This state refers to the AVG state. If the router is active, then it means that it is the AVG. On the other hand, if it says Listen, then that router is a standby AVG.

At the bottom, two forwarders are listed. This is the list of all forwarders on the list. At this point, my router is the forwarder for Forwarder 1 (it responds to the first MAC) while it listens for the status of Forwarder 2.

Telnet into 1.1.1.2 from T1, disconnect, and attempt to "show arp". You should see:
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  1.1.1.1                 -   c200.0410.0000  ARPA   FastEthernet0/0
Internet  1.1.1.2                 3   0007.b400.0001  ARPA   FastEthernet0/0
Internet  1.1.1.3                 4   c202.0410.0000  ARPA   FastEthernet0/0
Internet  1.1.1.4                 4   c203.0410.0000  ARPA   FastEthernet0/0


Note that now 1.1.1.2 is associated to the MAC of forwarder 1, which is for L1. Now, shut L1 down and attempt to telnet back. At this point, L1 should not be able to respond for Forwarder 1's MAC, so it should not go through, right?

Miraculously, it does! R1 actually responds to Forwarder 1! Now, disconnect and attempt to "show arp", you should see:
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  1.1.1.1                 -   c200.0410.0000  ARPA   FastEthernet0/0
Internet  1.1.1.2                 3   0007.b400.0001  ARPA   FastEthernet0/0
Internet  1.1.1.3                 4   c202.0410.0000  ARPA   FastEthernet0/0
Internet  1.1.1.4                 4   c203.0410.0000  ARPA   FastEthernet0/0


The MAC associated to 1.1.1.2 hasn't changed! This is evident that R1 has actually taken over the Forwarder of L1! To verify, type "show glbp" and you should see:
There are 2 forwarders (2 active)
  Forwarder 1
    State is Active
      3 state changes, last state change 00:00:04
    MAC address is 0007.b400.0001 (learnt)
    Owner ID is c202.0410.0000
    Redirection enabled, 585.960 sec remaining (maximum 600 sec)
    Time to live: 14385.956 sec (maximum 14400 sec)
    Preemption enabled, min delay 30 sec
    Active is local, weighting 100
  Forwarder 2
    State is Active
      1 state change, last state change 00:23:12
    MAC address is 0007.b400.0002 (default)
    Owner ID is c203.0410.0000
    Redirection enabled
    Preemption enabled, min delay 30 sec
    Active is local, weighting 100


R1 is now in charge of both forwarder 1 and 2! Now, notice the line that says "Load balancing: round-robin". This is the load-balancing policy, which simply makes to take turns. There is a weighted option which can be configured with:
glbp 0 load-balancing weighted

What this does is that it allows routers to be assigned a weight value. If L1 has a weight of 2 and R1 has a weight of 1, then L1 will receive 2 clients for every 1 client R1 receives. The weight can be configured using:
glbp 0 weight 2

Now we'll talk about priority and preempt. Notice that after your L1 came up, only the Forwarder was returned to it. The AVG is still R1. This is because by default routers have preempt set for AVFs, and no preempt set for AVGs. Preempt simply means that if the router comes back online, should the rights be given back to it. To enable preemption for AVG on L1, simply type:
glbp 0 preempt

Priority determines the next router that would be the standby for the active. The higher the priority number, the more likely it is to become the next active router when the current active goes down. Priority also determines if a router can be preempted. If a router has the priority of 150, and a router with the priority of 100 attempts to preempt, it will not succeed. The default priority is 100. The priority can be set using:
glbp 0 priority 150

The weight, in addition to load-balancing, can be used to determine if the router still serves as a AVF or not. The weight parameter allows you to set upper and lower thresholds. If you specify the lower threshold, then the router will be taken offline when its weight is at that threshold. If you also specify the upper threshold, then the router will not resume it role until it is higher than that amount. This is similar in operation to a schmitt trigger. Right now we'll use a simple system that specifies 1 = Offline, 2 = Online:
glbp 0 weighting 2 lower 1 upper 2

Now we'll need to specify an object to track. We'll track f0/1 (the other side's interface):
track 1 interface FastEthernet0/1 ip routing

Go back into the interface. From there, we'll enable tracking to specify that if track object 1 is down, the weight should be decremented by 1, effectively disallowing the router to be an AVF:
glbp 0 weighting track 1 decrement 1

On HSRP and VRRP, this can be done by using:
standby 0 track 1 dec 100
vrrp 1 track 1 dec 100

Thursday, August 5, 2010

Debian 21

Apart from allowing proxy access to subnets in Squid, you can actually specify an authentication scheme to be used with it. The authentication will come in the form of a HTTP - Basic Access Authentication window. We'll set up Squid to do just that in this article. We first of all install Squid:apt-get install squid

The entire Squid system is controlled by the /etc/squid/squid.conf file, so let's open it up with:
nano /etc/squid/squid.conf

In this file, there are several things we'll need to change such as port number (optional) and allowed computers. First we'll change the port number, to do this, press F6 and type in "http_port". On about the fourth search, you should be able to find this line:
http_port 3128

Modify it to whatever you like and save your configuration. By default, Squid doesn't allow any proxy requests. To allow traffic, you'll need to use the "http_access" statement. The "http_access" statement specifies an "acl" each, and whether to permit or deny it. To begin, we'll press F6 and search for the keyword "localnet". You should end up with this:
acl localnet src 10.0.0.0/8
acl localnet src 172.16.0.0/12
acl localnet src 192.168.0.0 /16


Let us break down the format of the ACl declaration. The ACL declaration comes in the form:
acl aclname acltype argument

The available options in specifying an ACL can be found by searching (F6) for "TAG: acl". In this case, the above example shows the acl matching source address from RFC1918 subnets. Now, we'll want to use an ACL to specify or "match" an authentication method. Whether the ACL returns true or not depends on whether the authentication program (in this case, a supplied helper program) returns a true or false.

We'll first begin by setting up the authentication scheme, which would be NCSA Authentication. NCSA Authentication reads an NCSA-compatible password file made using the "htpasswd" command. To specify this method (we'll create the password file later), search (F6) for "passwd". You should end up at this line:
# auth_param basic program /usr/lib/squid/ncsa_auth /usr/etc/passwd

Obviously, /usr/etc/passwd doesn't exist because there is no such folder and Debian and because we haven't created a NCSA file yet. We'll uncomment the line and change the directory of the file to this:
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd

Now, we'll need to specify to use the authentication as a method. If you read the introduction to authentication a little higher (or by searching for "TAG: auth_param"), you would see that you need to specify an ACL of the type proxy_auth. To do this, we'll place this somewhere near our localnet ACLs:
acl authenticate proxy_auth REQUIRED

The REQUIRED keyword forces the server to accept only valid user names. Now, we'll apply the ACL by placing a http_access statement somewhere after "http_access allow localnet" (search for it):
http_access allow authenticate

Now finally, we'll need to create the NCSA password file. To do this, browse over to /etc/squid/ and type:
htpasswd -c passwd kelvin

The -c is to create a new file. To add more users in the future, omit the -c parameter. We'll now need to permit Squid to read it by allowing read permission for "others":
chmod o+r passwd

Coincidentally, the /etc/shadow file is NCSA-compatible, so you can actually use it instead of your own NCSA file to authenticate against existing Linux users. Remember to set the read permission in the server.

Now that we have everything in place, it's time to restart the proxy server through:
/etc/init.d/squid restart

Now after we set the browser to point to the proxy server, try to browse somewhere and you'll see a message similar to this:


In a future article we'll go through proxy authentication through Active Directory. Active Directory implements the LDAPv3 protocol and we'll be able to do this using squid's built-in ldapv3 helper.
<