Writing an F5 iRule to block traffic by user-agent

So, the F5's can do all kinds of swoopy things using the iRule scripting language. I've been playing around with simple ones.

Suppose I want to block all the traffic from a certain robot that advertises itself as having the user-agent field "AnnoyingRobot". I could use an iRule like this to block it:

when HTTP_REQUEST {
if { [HTTP::header "User-Agent"] contains "AnnoyingRobot" } {
drop
return }
}

The "contains" operator looks for a substring, so it'll catch "AnnoyingRobot/4.5" and "AnotherAnnoyingRobotButDifferent/mozilla".

The next step would be to have it search against a list of user-agents. The way to do this is with a "class" or "datagroup" (the terms appear to be interchangeable in F5-speak). So you can use the GUI to create a "string" type datagroup named "userAgentsToBlock" that contains:

AnnoyingRobot
RegisCustomUseragent
OtherStuffWeBlock

and then change the rule to be like this:

when HTTP_REQUEST {
if { [matchclass [HTTP::header "User-Agent"] contains $::userAgentsToBlock ] } {
drop
return }
}

Then apply that iRule to a given virtual server, and you're all set to drop traffic from user-agents you don't like.

SPOOOOOOOKY

So, my office (like many offices) has Halloween decorations up. Lots of cartoony graphics with headstones that read "RIP".

And I kept wandering by and reading "RIP" and thinking about the routing protocol.

So I made my own spooky Halloween decoration:

EIGRP

Except for the odd cisco class, I've never actually used EIGRP. It's another interior routing protocol, like OSPF and often used in place of it. It's cisco-only, as it's cisco's proprietary protocol, which makes it a non-starter in heterogeneous routing environments. (OSPF is based on standards and is supported by pretty much all vendors of "real" routers, which is to say "not a $30 home router for your dsl line".)

Unlike OSPF, EIGRP doesn't have the concept of "areas", so all of your internal network is lumped into a single monolithic administrative collective. Like OSPF, it establishes neighbor relationships with other routers and shares routes among its neighbors. EIGRP gives you a few more ways to tweak your routes, having bandwidth and delay instead of a simple cost metric and does route filtering a bit more granularly.

More about BGP -- load sharing across equal-cost paths

Suppose you have several equal-bandwidth or equal-cost paths between a pair of routers that want to be BGP neighbors. For example, two or more WAN links between two BGP areas. You want the routers to route over both paths. The thing to do is to use a loopback address for your BGP neighbors. You must also have "ebgp-multihop" configured as well, so BGP will be okay with going to a neighbor that is not on the same subnet as itself.

So, router A (AS 64591) and router B (AS 64592) are connected by a pair of WAN links.

On router A:

int loopback 0
ip address 10.255.255.1 255.255.255.255

router bgp 64591
neighbor 10.254.254.1 remote-as 64592
neighbor 10.254.254.1 update-source loopback 0
neighbor 10.254.254.1 ebgp-multihop


Router B looks similar:

int loopback 0
ip address 10.254.254.1 255.255.255.255

router bgp 64592
neighbor 10.255.255.1 remote-as 64591
neighbor 10.255.255.1 update-source loopback 0
neighbor 10.255.255.1 ebgp-multihop

Don't forget to include your loopback network range in the "network" statement for the BGP instance.

BGP basics: "Active" is not a good state.

BGP is TCP based. If you're got a router that wants to share BGP routes, each neighbor has to be explicitly configured. When this is done and BGP restarted, the router opens a BGP session to each of its neighbors on TCP/179 and chats about what routes it has and what routes it can learn.

If there are no routing updates, the routers exchange keep-alive packets every 60 seconds to be sure that the TCP session is still up and the routers are all happy.

When a BGP TCP session starts up, the BGP neighbor will show as state "Connect" when the router is actively trying to connect. If it successfully makes the connection, it shifts to state "OpenSent" and then through "OpenConfirm" to "Established".

If the router cannot make a successful TCP connection, it shifts to state "Active". NOTE: This does not mean that the connection has been made; just that it's actively trying to make the TCP connection. If your neighbors show as "Active", your routing is *not* working yet. Once the TCP session is established, the neighbor state goes through "OpenSent" and "OpenConfirm" to "Established". That last state, "Established" is the one you want to see in your summary of BGP neighbor states.

On a Cisco, your neighbor summary table would look something like this (taken from Cisco IOS IP Command Reference Vol 2 of 4: Routing Protocols, Release 12.3T - IP Routing Protocols Commands):

Router# show ip bgp summary 


BGP router identifier 172.16.1.1, local AS number 100 
BGP table version is 199, main routing table version 199 
37 network entries using 2850 bytes of memory 
59 path entries using 5713 bytes of memory 
18 BGP path attribute entries using 936 bytes of memory 
2 multipath network entries and 4 multipath paths 
10 BGP AS-PATH entries using 240 bytes of memory 
7 BGP community entries using 168 bytes of memory 
0 BGP route-map cache entries using 0 bytes of memory 
0 BGP filter-list cache entries using 0 bytes of memory 
36 received paths for inbound soft reconfiguration 
BGP using 34249 total bytes of memory 
Dampening enabled. 4 history paths, 0 dampened paths 
BGP activity 37/2849 prefixes, 60/1 paths, scan interval 15 secs 

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down State/PfxRcd
10.100.1.1      4   200      26      22      199    0    0 00:14:23 23
10.200.1.1      4   300      21      51      199    0    0 00:13:40 0

There are three fields that you're probably most interested in under normal circumstances:

• The first one to look at is "State/PfxRcd": If the TCP session is up and the routers are exchanging routes, then this field will be a numeric value that shows how many route prefixes have been received from the remote neighbor.
• The next one of note is "TblVer", which is the routing table version. Under normal circumstances, this should be the same if routing is stable.
• The third field of interest is the "Up/Down". If the BGP session to the neighbor is up and happy in the "Established" state, this is the duration of the current TCP session. If it's not up and happy, this will display the current state of the connection. Remember, "Active" is not what you want to see here. (Yes, I'm harping on it, but I've seen many people make the mistake of thinking that "Active" means that the connection is working correctly.)

This table (Table 41 in the same document) lists all the fields in the output and what they indicate.

Stubby and NOT SO STUBBY.

OSPF uses the concept of "area" to describe different chunks of the network.  The center of the network is "area 0", the backbone area, and it's assumed that all areas connect to area 0. 

Router interfaces, not entire routers are part of an area.  So a router can span more than one area -- for example, a router could have one interface in area 0 and another interface in area 1 and a third in area 199.  Other routers in area 1 would then see the router as a path back to area 0. 

Areas can be defined as "stubby", meaning that there's only one path out from the area, and so external routes don't get advertised to the stubby area.  A "not so stubby area" (nssa) can receive intra-area routes, but no external routes.

Who's the boss? (OSPF edition)

So, a router interface that's participating in OSPF floods the network with a HELO packet -- this is sent to a multicast address, so if you've got acl's in play make sure they allow the OSPF multicast.  One of the things the HELO traffic does, besides just announcing "hey, I'm here" to any likely devices that might also be looking for neighbors, is share out the information used for election of the "Designated Router" (DR) and "Backup Designated Router" (BDR). 

The DR and BDR serve as points of contact for exchange of routing information -- instead of each router updated every other OSPF neighbor with link state announcements, all the devices update the DR and BDR and they send out link state updates to all of the OSPF neighbors.  This reduces the complexity of the exchange of routing information.

DR and BDR election is done by OSPF priority.  If two interfaces on a given network segment have the same priority, the higher Router ID is used as a tie-breaker.  For any given OSPF device, the "Router ID" is the highest IP address on the box (including loopback interfaces).  Specific router interfaces may have an OSPF priority set explicitly as well to adjust whether or not they become DR; a priority of 0 means that the interface should never be the DR or BDR; this is described as the state "DROTHER"

Dress for success....

Apparently, when dealing with at least some VC's, "dress for success" means "wear a white penis":
'white male tech startups get funding for being white and male'. 

Also, the Wall Street Journal has an article looking at reasons that women-owned companies are generally smaller than men-owned companies (in spite of there being more new women owned businesses than men owned businesses for decades).  (And Discover magazine points out that women become more risk-averse when faced with stereotypes of women as risk averse)

more vacation. content later.

Regis is still on vacation.  Actual blog posts back on Weds.