A 52mn presentation by Allan Packer and Neelakanth Nadgir from Sun Microsystems.

** keep in mind ZFS can only be used in userspace on linux (through fuse) due to license comptability issue (GPL/BSD license)

enjoy!

A while back, I wrote a post on Ethernet Flow Control and IGMP snooping and how using TCP flow control on top of Ethernet Flow Control could easily alienate your network. If you are not familiar with Ethernet Flow Control, then I highly suggest, you go over my post in order to understand what I will be talking about here.

An understanding of the Spanning Tree Protocol is also highly required, which I won’t go in depth in this post.

Small Recap

Ethernet Flow Control makes use of PAUSE frames in order to notify an endpoint host to stop sending packet for an X amount of time; Depending on the bandwidth of the link, the PAUSE frames are sent at a specific interval of time.

100Mbps – each 300ms
1Gbps – each 30ms
10Gpbs – each 3ms

That is to say, sending more PAUSE frame than the appropriate set interval will considerably slow down the network and generate unexpected side effects.

Using PAUSE frame to have a new STP topology converged – DOS

- Target Designated ports

Because PAUSE Frame simply notify the host to stop sending frames; if we were to flood all the Designated ports of a root switch, we would immediately cut all transmission of root BPDU and user frame. This by consequence, will cause all root ports on the other switch to enter into a new STP convergence, since the root bridge has been completely cut off.

- Target Blocking ports

Remember, in the Blocking state, the port still receives BPDU without forwarding frames. Now let’s say we decide to flood all the segments connecting to the blocking ports. What do you think will happen? well, the blocked port no longer receives BPDU and after 20seconds starting transitioning to the listening state, a total of 50 seconds later, a new convergence has taken place, resulting in a redundant link becoming active and thus creating a switching loop/brodcast storm, which will degrade the network and bring it to its knees.

How to prevent an STP DOS

1. Disable Ethernet Flow Control on a port if not needed

2. Set a threesold for Pause Frames sent and received

3. Monitor for STP topology state changes

4. Monitor the traffic for high frequencies of TCN and TC BPDUs

Cheers,

Ali

Dilbert says it all

I am not usually out looking to post comic strips on this blog, but surely enough Dilbert nailed it today.
Dilbert.com

ClamAV 0.94 end of life

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

BGP Next-Hop-Self Attribute

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