Ali Abbas

So – I was greeted today with a mail queue pilling up and the ClamAV daemon crashing

root@mail:/# /etc/init.d/clamav-daemon start
Starting ClamAV daemon: clamd LibClamAV Warning: ***********************************************************
LibClamAV Warning: ***  This version of the ClamAV engine is outdated.     ***
LibClamAV Warning: *** DON’T PANIC! Read http://www.clamav.net/support/faq ***
LibClamAV Warning: ***********************************************************
LibClamAV Error: cli_hex2str(): Malformed hexstring: This ClamAV version has reached End of Life! Please upgrade to version 0.95 or later. For more information see  www.clamav.net/eol-clamav-094 and www.clamav.net/download (length: 169)
LibClamAV Error: Problem parsing database at line 742
LibClamAV Error: Can’t load /tmp/clamav-fc828b33b2c147c0486f8abb160d930e/daily.ndb: Malformed database
LibClamAV Error: Can’t load /var/lib/clamav/daily.cvd: Malformed database
ERROR: Malformed database

Yes, ClamAV end of life was announced in October last year but what escaped me was that since 15 April 2010, the CVD would contain a signature to disable your ClamAV install – so much to force you to upgrade

So on the run what do you do? Well clearly, delete the daily.cvd file and stop freshclamav to download the new signature.

root@mail:/# /etc/init.d/clamav-freshclam stop && rm /var/lib/clamav/daily.cvd
root@mail:/# /etc/init.d/clamav-daemon start
Starting ClamAV daemon: clamd LibClamAV Warning: ***********************************************************
LibClamAV Warning: ***  This version of the ClamAV engine is outdated.     ***
LibClamAV Warning: *** DON’T PANIC! Read http://www.clamav.net/support/faq ***
LibClamAV Warning: ***********************************************************
.
root@mail:/#

We are now back in business – note this is just a “on the run” solution and I would clearly need to upgrade the client now to 0.95

What about that postfix mail queue?

root@mail:/# postsuper -r ALL && postqueue -f

Cheers,

Ali

The BGP Next Hop Attribute is useful when passing routes received from an eBGP speaker and advertised to an iBGP speaker within the same Autonomous System.

By default when a route is advertised to an eBGP outside of the AS, the router will make sure that the next hop attribute reflects its IP address… now imagine a route is advertised to an iBGP speaker and sourced into the BGP AS group. What is going to happen is that all iBGP routers will have as next hop the external eBGP router of the external Autonomous System.

To prevent this, we can make sure that a route advertised to an iBGP router reflects the IP address of the router sourcing that route into the AS to the iBGP neighbors and not the IP address of the eBGP neightbor which originally advertised this route.

It is important to keep in mind that BGP always make sure that a “hop/destination” is reachable before advertising – if the hop is not reachable, the route will still be held in the BGP table… in the previous case we discussed, the eBGP neightbor from the external  AS would have been “reachable” to our eBGP router (edge-t1), but not necessary to our iBGP speakers within our AS (depending on your configuration).

To avoid potential routing black-holes, one must then make use of the “next-hope-self” attribute to force the iBGP speaker to set the next hop of the route advertised to its own IP address.

- An example configuration on IOS would look as follow -

edge-t1# conf t
edge-t1(config)# router bgp 65100
edge-t1(config-router)# neightbor 10.210.0.10 remote-as 65100
edge-t1(config-router)# neightbor 10.210.0.10 next-hop-self
edge-t1(config-router)# exit
edge-t1(config)#do wr

* Furthermore, you may also use the “set ip next-hop peer-address” under a route-map and apply that route-map on outgoing routes to the BGP neighbor.

Cheers,

Ali

HSRP stands for “Hot Standby Router Protocol”

RCF 2281 defines in detail HSRP – http://tools.ietf.org/html/rfc2281

The purpose of this post isn’t to dive into the details of HSRP but simply to shed light on an HSRP feature often overlook when setting redundant routers for redundant ethernet path.

HSRP Election

When powering up routers running HSRP, the routers (by default in group 0) starts sending to each other (multicast: 224.0.0.2) hello packets to determine who else is part of the HSRP group. Past that, the routers start an election process based on the router’s set HSRP priority.

The HSRP priority is set by using the command “standby priority <number>”

interface fa0/0
standby priority 80

Keep in mind that the default priority is “100″… that is to say if no “standby priority” command is issue on this interface, this interface would have a priority of 100.

Once the routers elect the active router based on who has the higher priority, the other members of the HSRP group become “passive” routers or in Cisco terms “standby routers”.

What happens if all routers do not have a custom priority set or have the same priority?

If all routers have the same priority, then the router who has the “highest” IP address is elected the active router

A Typical HSRP Setup

As you can guess … the red path references the active router and the path through which the hosts on the LAN would be routed. Now keeping in mind that HSRP is running interface fa0/0 of both routers and that the link on s0/0 from the active router to the ISP would fail (see 2nd figure)

Since the serial link on the active router would fail, traffic would be redirected from the active router to the passive router on the secondary Ethernet interface… so in a nutshell, the active router still remains the active route (fa0/0 never fails) but the computers of the LANs have one more hop to go through to connect to the ISP.

The new path is show in “blue”

While this is not a technical issue in itself, it is possible to have the Virtual IP Address failover to the passive router by “monitoring” the state of the serial interface “s0/0″ and not only the state of fa0/0.

As we said earlier, the process of electing the active router in an HSRP group is to first evaluate the HSRP interface priority and then in case of a tie the highest IP address.

The command to enable interface tracking is

standby track INTERFACE PRIORITY_DECREMENT

So a typical configuration on both routers would look as follow

Active Router
int fa0/0
ip address 192.168.1.100 255.255.255.0
standby ip 192.168.1.1
standby track S0/0 30

Passive Router

int fa0/0
ip address 192.168.1.101 255.255.255.0
standby ip 192.168.1.1
standby priority 90
standby track S0/0 30

On both router’s fa0/0 we have setup “interface tracking” on serial 0/0 with a priority decremental value of 30 – that is to say if s0/0 on the active was to go down, the HSRP priority of fa0/0 would be of (100 – 30) so 70… since the HSRP priority of the passive router is 90, the VIP will then failover to the passive router which will become the active router.

Traffic will then be routed directly through the second router without having to be re-routed through the first router as seen in the 3rd figure.

It has been a while since the last release of pwgen (version 0.3)…

0.4 is now published on AMO | https://addons.mozilla.org/en-US/firefox/addons/versions/12441#version-0.4

ChangeLog

- Added Excluded Characters option
- Added Special Characters option (possibility to add/remove to special characters list)
- Added Spanish Translation (provided by Ricardo A. Rivas | rivica@gmail.com)
- User Interface Options redesigned

Hi,

I am pleased to announce that quaggOS in alpha version has been released.

quaggOS is a live linux distribution I created which turns a server/pc into a full BGP/OSPF router. This is achieved by using the Quagga routing solution application.

For more information, visit http://quaggOS.org

To download and test the alpha release, click here