Recently in Network Category

I've been fooling around with BGP recently, and the subject of route-maps came up. For those of you playing along at home (and by now, you all should be), route-maps allow one to filter the routing updates that BGP sends. Suppose you are doing something simple like redistributing connected networks into BGP. That works fine, as long as none of them are RFC 1918 space or internal networks that shouldn't be advertised to the outside world. If you decide to hang an internal network off one of your routers (or multi-layer switches) then the default behavior of BGP that's having connected routes redistributed into it would be to advertise those as well. Clearly, this isn't desired behavior.

By using a route-map, you can in effect tell BGP to ignore some networks and not advertise them.

To start, let's get two BGP-speakers up and exchanging connected routes. RouterA has been configured with an IP of 10.0.0.2 and RouterB with 10.0.0.3.

RouterA(config)#router bgp 100
RouterA(config-router)#neighbor 10.0.0.3 remote-as 200

RouterB(config)#router bgp 200
RouterB(config-router)#neighbor 10.0.0.2 remote-as 100

As you can see, RouterA has been placed into AS 100 and RouterB is in AS 200. This is a lab environment so the only reason I used these ASNs is to avoid having to type and re-type the ones allocated in RFC 5398 which are at the higher end of the ASN spectrum.

Anyway, once this has been done, we'll see a log message like this one taken from RouterA:

*May 22 10:40:52.455: %BGP-5-ADJCHANGE: neighbor 10.0.0.3 Up

So the routers are talking BGP to each other but so far no routes are being advertised. To give them something to talk about, we'll add some loopbacks and tell the routers to redistribute those into BGP.

RouterA(config)#int lo0
RouterA(config-if)#ip address 10.100.0.1 255.255.255.255

The RouterA sees loopbacks as directly connected networks, and adds them to the routing table as shown:

RouterA(config-if)#do sh ip ro
C 10.0.0.2/31 is directly connected, GigabitEthernet1/1
C 10.100.0.1/32 is directly connected, Loopback0

The route hasn't yet been redistributed into BGP - we've got to tell it to do that:

RouterA(config)#router bgp 100
RouterA(config-router)#redistribute connected

There are other parameters that can modify the behavior of routes redistributed into BGP, but that simple command will get the job done. Now we wait a few seconds for the updates to be pushed to RouterB and then look at it's routing table:

RouterB#sh ip ro bgp
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B 10.100.0.1/32 [20/0] via 10.0.0.2, 00:00:28

Success! RouterB has learned a route to 10.100.0.1 from RouterA via BGP. Let's add another loopback:

RouterA(config-router)#int lo1
RouterA(config-if)#ip address 10.200.0.1 255.255.255.255

Sure enough, it shows up on RouterB as well:

RouterB#sh ip ro bgp
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
B 10.200.0.1/32 [20/0] via 10.0.0.2, 00:00:37
B 10.100.0.1/32 [20/0] via 10.0.0.2, 00:06:47

That's fine and dandy assuming we want all the connected networks on RouterA to be pushed to RouterB. If we want to keep 10.200.0.1/32 from being advertised by BGP we can create a route-map to filter it from the list of updates to be sent.

The first thing we have to do is define the route-map:

RouterA(config)#route-map TESTMAP permit 10

Easy enough. 10 is just a sequence number like in regular firewall access-lists and for our purposes doesn't mean anything. The next thing we have to do is tell the router which network we want to permit (the rest will be blocked):

RouterA(config-route-map)#match ip address 1

This tells the router to look at access-list 1 and check the addresses against it before advertising them. Since access-list 1 doesn't yet exist, let's write it:

RouterA(config)#access-list 1 permit 10.100.0.0 0.0.255.255

The only tricky thing, for those of you coming from the world of firewall access-lists is that the netmask is a wildcard mask, not a standard one. Looking at this access-list entry, networks starting with 10.100 are okay to advertise. Everything has been defined with the exception of applying to route-map to BGP's redistribution of connected routes.

RouterA(config)#router bgp 100
RouterA(config-router)#redistribute connected route-map TESTMAP

Just like before, we're telling BGP to redistribute routes for connected networks but we're also telling it to only do so if the routes pass successfully through the TESTMAP route-map. Now that everything is in place, let's look at RouterB again:

RouterB#sh ip ro bgp
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B 10.100.0.1/32 [20/0] via 10.0.0.2, 00:19:10

As you can see, the route for 10.200.0.1/32 has been dropped from RouterB's routing table since it was filtered out by the route-map. There are many, many other things that can be done with a route-map, but this is intended to be more of a quick intro than anything resembling a complete guide.

OSPF area types and LSAs seem to be somewhat misunderstood concepts. If you've read this far, you're probably already aware that OSPF makes use of areas to break up the potential administrative nightmare of running an IGP in a network. If you've read THIS far, you're probably also aware that area 0, the backbone area, has a special significance to OSPF. The other area types and the link state advertisements used to toss information around between the routers are where a lot of people get confused.

Standard Areas

A standard area is often described with a phrase like "A standard area is the most basic type of area". Well great - 'standard' in what way? Standard areas can be thought of as being the "equal opportunity employer" of OSPF areas as every router in the area knows about every route. This is just fine if the routers are high-powered enough to store every route and run the SPF calculations without getting bogged down. Type 1 and 2 LSAs are passed between routers to convey information regarding their own interfaces and their neighbors. Internal routes, communicated by type 3 LSAs, and external routes, communicated by type 5 LSAs are sent through all standard areas as well as the backbone area, which is a type of standard area. Type 3 LSAs can be sourced by any OSPF router whereas type 5 LSAs only ever come from autonomous system border routers. Autonomous system border routers are also responsible for generating type 4 LSAs. An area border router that has an interface in that area and an interface in the backbone area will inject the type 4 LSA into the backbone area to ensure the route to the autonomous system border router is known. Type 4 LSAs are only passed internally.

In summary, a standard area can contain LSAs of type 1,2,3,4, and 5.

Stub Areas

If an area can be thought of as a leaf node on a network then a stub area may be appropriate. A stub area can be handy if devices in it are low-powered, or simply have no need to know about every route. A stub area is similar to a standard area, but routers in it are not aware of externally-sourced routes directly. In terms of LSAs, that means that type 5 LSAs are not permitted in a stub area. A type 3 LSA is injected into the area by an area border router to act as a default route, allowing connectivity outside the stub area. The type 3 LSA provides the equivalent of an "All Points East" sign for stub area routers. Type 4 LSAs are not forwarded into a stub area, as the default route is used.

For a router to be in a stub area, the area must be configured as such on all routers involved:

Weasel(config-router)# area 3 stub

In summary, a stub area can contain LSAs of type 1,2, and 3.

Totally Stubby Areas

Totally stubby areas are a Cisco invention designed to take the concept of a stub area one step further. In addition to the lack of type 4 and 5 LSAs, type 3 LSAs, which carry information about internal routes are also prohibited. The concept of an injected default route still applies (the only instance of a type 3 LSA in a stub or totally stubby area) but it also covers internal routes. All traffic leaving the area does so using this default route. While I've never tried this in a lab, I've been told that one can have multiple 'default routes' (in stub, totally stubby, and not-so-stubby areas) and internal metrics will be used to select the least-cost route. If you've tried this, let me know.

To configure an area as a totally stubby area, use the no-summary argument when defining the area:

Vole(config-router)# area 4 stub no-summary

In summary, a totally stubby area can contain LSAs of type 1 and 2 as well as a type 3 LSA for the default route.

Not-so-stubby Areas

Yet another Cisco-concocted area type, the NSSA is a variant of the stub area type but is allowed to contain an autonomous system border router. Since type 5 LSAs are not permitted in stub areas of any type, a type 7 LSA is used. For the record, there is a type 6 LSA that is used by Multicast OSPF. MOSPF is an extension of OSPF designed to support (surprise!) multicast. At any rate, a type 7 LSA is essentially a type 5 LSA with a fake beard and glasses on. It performs the same function as a type 5, but is permitted through NSSAs. A hard-learned lesson for me was that by default an NSSA does NOT have a default route injected into it by an area border router. To have one (yes, please) the default-information-originate argument must be used:

Marmoset(config-router)# area 5 nssa default-information-originate

This comes in handy if one wishes to route traffic out of an NSSA.

If totally stubby area functionality is desired, all area border routers must be configured appropriately:

Marmoset(config-router)# area 5 nssa no-summary

Note that if an NSSA is configured to behave like a totally stubby area, a default route IS injected by the area border routers so the default-information-originate parameter is not necessary.

In summary, a not-so-stubby area can contain LSAs of type 1,2,7 and if configured for it, a type 3 for a default route.

Bonus Fact

Type 8 LSAs are very rarely used, but can carry BGP information over OSPF. I haven't the faintest idea how to use them, so don't ask.

LSA types 9 - 11 are called 'opaque LSAs' and are reserved for future growth. I plan to make use of them in my proposed "Kinda-stubby-but-only-if-you-squint-right" area.

While I'm pretty sure all of this is correct, it's possible that I either missed something or made a type somewhere. If you spot an error, please let me know so I can correct it.

Like most of you out there, I think about OSPFv3 and IPv6 regularly. Looking up 'regularly' in the Philip-English Dictionary we see it defined as "the day before yesterday while I was on my way home from work". Specifically, I was thinking "Huh - I don't know much about OSPFv3, and even less about IPv6".

IPv6 as I'm sure you're aware, was first proposed several years ago to put some of our out-of-work bits back to work. We've got bits everywhere with nothing to do, and here we are using a measly 32 of them in an IPv4 address. Cranking that number up to 128-bits allows us to take some of these bits off the street and make the internet more confusing to boot. It's really win-win.

With these two thoughts in mind, I decided to set up a little IPv6/OSPFv3 lab. Grabbing a spare 6504 and a couple of 4948s I set to work.

Lesson The First: any IOS version that has "ipbase" in it's name will not work. You'll be able to put an IPv6 address on a routed interface, but the command to enable IPv6 routing device-wide is missing. Go for "ipservices".

ipv6 unicast-routing is the universal command to enable (surprise!) IPv6 unicast routing. ipv6 cef could also be enable if you want to use uRPF (Unicast Reverse Path Forwarding).

Putting an IPv6 address on an interface is as straight-forward as it is in IPv4:

IPv6Lab1(config-if)#no switchport
IPv6Lab1(config-if)#no ip address
IPv6Lab1(config-if)#ipv6 address 2001:410:0:5::1/64
IPv6Lab1(config-if)#ipv6 ospf 1 area 0

Notice that the last command explicitly places the interface into OSPF area 0. Rather than say "All interfaces in network x.x.x.x/y go into area z" it's on an interface by interface basis. Personally, I think this makes it much clearer, but if there's any confusion there's always the fall-back command:

IPv6Lab1#sh ipv ospf int b
Interface PID Area Intf ID Cost State Nbrs F/C
Gi1/47 1 0 58 1 DR 1/1
Gi1/48 1 0 56 1 BDR 1/1

The bulk of the commands related to IPv6 differ only from their IPv4 counterparts in that one uses "ipv6" instead of "ip". A major gripe I have with Cisco (other than those currently displayed at dearcisco.com) is that sh ip int b shows nothing related to IPv6. Not even an indicator that the interface HAS an IPv6 address. sh ipv int b shows this information but in a much more vertical format rendering it easy to scroll off the screen. I recommend using sh ipv int b | e do|una as it filters out all the 'down' or 'unassigned' interfaces.

Getting back to configuring IPv6 addresses, the ipv6 address <blah> command can take an additional parameter of eui-64. This seems to work the MAC address into the IPv6 address which can be a bit confusing; suddenly there are a bunch of hex characters that weren't typed in. Anyway, on with the show.

OSPFv3 has some other little quirks that are handy to know. In previous versions, there was a hierarchy that OSPF would go through to select the router ID used by the device. First, it would check for a hard-set router ID. In the absence of a hard-set RID, the highest IP address on the loopbacks would be used. If no loopbacks are set, the highest IP anywhere on the device is selected. Obviously it doesn't make sense to have an OSPF process running if there isn't a layer 3 configuration on the device. With IPv6 and OSPFv3 one might think that the same logic would apply. It does. Identically. IPv6 addresses are not used for RIDs (possibly for sanity reasons) in OSPFv3. If no hard-set RID or IPv4 address is configured anywhere on the device OSPF will simply refuse to start. The day will come (if it hasn't already) when someone new to a configuration will remove the "pointless" IPv4 loopback on a device. It won't be a problem at first, but when either the chassis or the OSPF process reloads OSPF won't come back up. Brace for impact.

The moral of the story is the the output of sh ipv ospf nei will look shockingly similar to that of IPv4 and earlier versions of OSPF:

IPv6Lab1#sh ipv o n

Neighbor ID Pri State Dead Time Interface ID Interface
10.0.0.4 1 FULL/BDR 00:00:36 7 GigabitEthernet1/47
10.0.0.3 1 FULL/DR 00:00:35 54 GigabitEthernet1/48

While I won't bother repeating the commands of adding an IP address to an interface and adding an interface to an OSPF area, below are the end results of my fiddling. The topology is three devices arranged in a triangle, all IPed interfaces in area 0.

IPv6Lab1#sh ipv route
IPv6 Routing Table - Default - 8 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2
IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
C 2001:410:0:1::/64 [0/0]
via GigabitEthernet1/48, directly connected
L 2001:410:0:1::1/128 [0/0]
via GigabitEthernet1/48, receive
LC 2001:410:0:2::2/128 [0/0]
via Loopback0, receive
OE1 2001:410:0:3::2/128 [110/21]
via FE80::8A43:E1FF:FE08:7C3F, GigabitEthernet1/48
C 2001:410:0:5::/64 [0/0]
via GigabitEthernet1/47, directly connected
L 2001:410:0:5::1/128 [0/0]
via GigabitEthernet1/47, receive
O 2001:410:0:6::/64 [110/2]
via FE80::226:CBFF:FE30:8980, GigabitEthernet1/47
via FE80::8A43:E1FF:FE08:7C3F, GigabitEthernet1/48
L FF00::/8 [0/0]
via Null0, receive

As mentioned in other attempts at tutorials, I am by no means an expert. According to Cisco, I'm merely an "associate". No guarantees are made as to the accuracy of this information. I may be wrong - in fact, I probably am. Consult a physician before changing your dose.

As part of my periodic process of looking through my server's logs and seeing who I should block (UFW is a fantastic iptables wrapper, incidentally), I ran across an IP that apparently belongs to Google Reader. I did some digging around on the Google Reader site, and it seems that this particular blog of mine has somehow acquired 23 subscribers. This is not to say that this blog is hosted on a server I own - this blog is generously hosted by DLuke. I haven't the faintest idea who these subscribers are, but hell, I'll take 'em!

Speaking of Google Reader, there's apparently a Facebook application that claims to allow you to use Google Reader form your Facebook account. As a former English teacher of mine recently discovered, using this application will summarily get your IP address blacklisted by Google. So you might want to stay away from that; or don't - I can't make all your decisions for you.

For those of you playing along at home who also have to have an ASA running 8.0 or 8.1 code, pay attention. The rest of you, go about your business. Move along, nothing to see here...

Cisco recently announced that a flaw exists in ASA 8.0 and 8.1 code that can force the device to reload itself if a specially-formed HTTP packet passes through it if SSL VPN is being used. There are a couple of other conditions, but from what I've read they're all pretty non-standard configurations.

The moral of the story - keep your code up to date.

There's also a paper being released at Black Hat Europe next week that will supposedly reveal a fundamental flaw in BGP and MPLS of a comparable seriousness to Kaminsky's DNS exploit of several months ago. So all those of you who run BGP (yeah yeah I know, no one who runs BGP is going to be reading the blog of little old me), heads up.

In the spirit of previous primers, I thought I'd add one regarding CSS (Content Services Switch) content rules. But first, a caveat: this was written as an introductory guide only. I may have missed something, gotten something incorrect, or in some other way be responsible for the end of the world. I am not a CCNA, CCNP, CCIE, or CC-anything else. Apply at your own risk.  Also, forgive my ASCII art - I couldn't get it looking quite the way I wanted.

Say you have a network arranged like this:

                                  [Blogosphere/Intertubes]
                                                  |
                                                  |
                     [Intelligent weasel serving as a firewall]
                                                  |
                                        [web server]

Suppose that you run a wildly successful website that allows you to purchase domesticated weasels (though not the one acting as your firewall - that one's worth millions). A single server may be fine initially, but eventually the demand for weasels overloads your server on a regular basis. Additionally, your fireweasel gets very tired.

You could take your server offline and add RAM, additional disk space, and a faster CPU to improve performance, but that's a solution that doesn't scale very well. Eventually, your server will be as fast as it can be, with as much RAM as it can hold and you'll still eventually run into the same problem as weasel demand grows.

After consulting a series of floor tiles in a local bar while mulling the problem over, it hits you. A boot. After spending several weeks recovering in a hospital, the SOLUTION hits you. A load balancer. The premise of a load balancer is that requests for content are spread over several computers in a server farm. A common load balancer is the Cisco 11500 family (11501, 11503, and 11506).

A basic layout might look something like this:

                                                [Blogosphere/Intertubes]
                                                                 |
                                                                 |
                              [Ultra-wise vole acting as perimeter security]
                                                                 |
                                                            [CSS]
                                                                 |
                                            __________ | ________
                                           |                     |            |
                                       web1             web2     web3

A web application or service is associated with a virtual IP address (VIP) in your DNS records. This IP address is assigned to the CSS, which acts as a proxy for the servers sitting logically behind it.

In the example above, when HTTP requests come in, they are first confronted by the firevole. Once the vole has allowed the requests to proceed, they are intercepted by the CSS. The CSS then passes the traffic to one of the servers behind it by consulting a set of content rules; configuration commands specifying how the requests should be handled.

Talk about why round-robin DNS wouldn't do the same thing? Sure. In general, DNS resource records have TTLs of at least several hours, sometimes higher. Making a change to add a new server during a high-load period couldn't take affect until those TTLs had expired and remote caches had updated. Additionally, A records don't have one key piece of information that a CSS possesses; server status.

A CSS uses a series of keepalive requests to the server that allow it to remove a failed server from rotation. These keepalives can range from simple, periodic socket connections to more complex verifications of URI content - ie, does domain.com/test.html still say 'OK'. DNS is not able to determine server status, so requests could be routed to a dead server.

Additionally, round-robin DNS is precisely that; round-robin. Requests will be passed sequentially to the next server in line. Sometimes that's not what you want at all. If you have three servers that are all equally well-configured that may work fine, but suppose the servers are configured differently. web1 and web2 might be powerhouse servers while web3 is an older machine that can't handle as much load. The CSS can be configured to assign 'weights' to the servers allowing you to force web1 and web2 to each handle 40% of the requests while web3 servers only 20%. You get the idea - load balancers = good.

On to configuration. Each application or service to be load balanced is defined in a 'content rule', a set of configurations dictating exactly how the load balancing should work, and which servers (called 'services') are participating. Each content rule is an independent entity on the load balancer, allowing you to control it separately.

Since you might very well be hosting multiple clients behind a single load balancer, content rules can be grouped under 'owners'. Each content rule is a series of directives such as to use a leastconn load balancing algorithm (the server with the fewest active connections gets the next request), perform keepalive checks using a socket connection to port 80 on the servers, etc. Say your machines are IPed as follows (assume the servers and the internal IP of the CSS are on a 192.168.1.x/24 network. Here's how a sample request gets processed.

                                                          {step 1} {step 7}
                                                                     |
                                     [Ultra-wise vole acting as perimeter security] {step 2} {Step 6}
                                                                 [CSS] (.1) {step 3} {step 5}
                                                                     |
                                                __________ | ________
                                               |                     |            |
                                         web1(.2)         web2 (.3)  web3 (.4) {step 4}

Step 1: A request comes in to purchase a weasel on 9.9.9.4, a VIP on the CSS.
Step 2: The firevole performs NAT translations on the request, converting the IP addresses.
Step 3: The CSS intercepts the requests on the internal VIP and checks the content rules. The rules tell the CSS that the next request should be sent to web3, so the request is transferred there.
Step 4: web3 logs the purchase request and sends back a response.
Step 5: The CSS sees that the traffic is outbound and passes it back to the firevole.
Step 6: The firevole performs NAT translations again and shoots the response back to the client.
Step 7: One freshly-minted weasel owner.

Something may have jumped out at you. The CSS is not performing any type of NAT translations, and both it's inside and outside interface are part of the same network, using the same IP address. This normally wouldn't work in a standard network. However, here the CSS is operating in dispatch mode wherein it acts as a transparent bridge between two VLANs that have the same IP address scheme. The CSS can also operate in direct mode, but that in my experience is fairly rare.

Operating as a transparent bridge has both an up and a down side. The upside is that any new servers can be behind the CSS, even if they're not being load balanced. The CSS will bridge traffic and ARP for the server, acting like a switch. No additional configuration is required.

The downside is that acting a bridge automatically means the CSS must participate in spanning-tree protocol (STP) which is used to prevent layer 2 loops and the resultant frame storms which can bring a network to it's knees. Care must be taken to configure the CSS accordingly. I've seen cabinets in a test environment be brought down because this wasn't done.

Keep in mind that this is just one possible deployment of a CSS. There are many other ways of doing it, but this seemed to me to be the easiest to understand for the unfamiliar reader.

Before signing off, a quick thank you to those of you who have posted comments and sent emails from all the continents of the world, save one (I apparently am not popular in Antarctica). It's always good to hear from people who take the time not only to read but to respond. To those of you who are silently reading along, thanks to you too.

For today's lesson, here's a little something about object-groups on Cisco firewalls.

An object-group on a firewall is a way of applying an ACL to a group of IP addresses or networks without having to type them all in each time. Think of an object-group as being a bucket of IPs, and you apply the ACL to the bucket once.

From a 'sh run' from one of my ASA 5505s:
object-group network clients <---- the bucket
network-object host z.z.z.z <--- a single IP in it
network-object x.x.x.0 255.255.255.254 <---- a network in it
network-object x.x.x.164 255.255.255.254 <---- another network, etc etc

The object-group must be applied with an ACL. Until that happens, it's just a list of hosts and/or networks.

ciscoasa(config)# access-list acl1 extended permit tcp any object-group clients eq www
ciscoasa(config)# access-list acl1 extended permit tcp any object-group clients eq https

clients is the bucket and you can see the two ACLs allowing port 80 and 443 access to that entire bucket.

ciscoasa# conf t
ciscoasa(config)# object-group network clients <--- modify the clients object-group
ciscoasa(config-network)# network-object host x.x.x.x <---- Add this IP to the group...
ciscoasa(config-network)# network-object host y.y.y.y <---- ...and add this one too

These things are really handy, especially if you're using them to regulate access to something that can change frequently. Learn them, love them, use them.

Once again, the home network is undergoing some restructuring. Fortunately, this should be the last hardware change for the foreseeable future - all the Linksys and Netopia crap is going away and being replaced by Cisco gear.

The Netopia DSL modem and both WAPs are being replaced by a Cisco 1801W with an ADSL WIC. I love having a port labeled 'ADSLoPOTS' on the back of a piece of hardware. The 1801W is being connected to a Cisco 2950 switch which is being put in place of a Linksys 24-port managed switch. As an aside, Linksys (who somehow got purchased by Cisco a while back), can't make network hardware to save their lives. A brand-new, out of the box switch lasted about three months until we had the nerve to reboot it. It never came back up.

Anyway, we're also trading out iptables and an IP Cop box in favor of an ASA 5505. Since I have another ASA 5505 on my desk at work (as well as a PIX 501, but that's just to play with) I figure I'll set up a split-tunnel site-to-site VPN connection.

Ah Cisco, where would I be without you? Out with a girlfriend, that's where.

But seriously, there's a lot of learning to be done, specifically translating the information I have regarding my DSL connection (the VCI, VPI, etc) into the proper IOS commands. Sadly, this is a one-day weekend for me so I'm kind of pressed for time. I'm working on Christmas Day, so I'm hoping the workload will allow me to do some fiddling.

After recently installing Ubuntu 8.04 on one of my boxes, I have only two complaints.

1) The laptop I have apparently has the only unsupported Atheros wireless chipset in history (AR242X).

2) Every two or three minutes, an error shows up in /var/log/auth.log (username removed):

May 13 21:26:03 neon sudo: username_removed : TTY=pts/3 ; PWD=/etc/pam.d ; USER=root ; COMMAND=/usr/bin/vi common-password
May 13 21:26:03 neon sudo: PAM unable to dlopen(/lib/security/pam_smbpass.so)
May 13 21:26:03 neon sudo: PAM [error: /lib/security/pam_smbpass.so: cannot open shared object file: No such file or directory]
May 13 21:26:03 neon sudo: PAM adding faulty module: /lib/security/pam_smbpass.so
May 13 21:26:03 neon sudo: pam_unix(sudo:session): session opened for user root by username_removed(uid=0)
May 13 21:26:03 neon sudo: pam_unix(sudo:session): session closed for user root

This message also appears whenever you sudo anything, filling up the auth log and making it virtually impossible to quickly skim through it and see meaningful messages. The error appears to be related to an auth mechanism that comes pre-enabled for SAMBA. Why that would come pre-enabled is beyond me, but the fix appears to be relatively simple.

In /etc/pam.d/common-password, find the line that says:

password optional pam_smbpass.so nullok use_authtok use_first_pass

...and comment it out. Next, find

auth optional pam_smbpass.so migrate

...in /etc/pam.d/common-auth and comment that out as well.

Done and done. Enjoy your minty-fresh auth log.

I'm studying for my CCNA and while reading a section dealing with how switches learn MAC addresses, a thought occured. The left 24 bits of a MAC is a code unique to each manufacturer while the right 24 bits is a series of bits that manufacturer has never used before (in theory - in large enough runs, you'll get some dups).

I had always assumed that if you connect two NICs with the same MAC to a port security-disabled switch the first one to be learned would be the one to receive all the traffic. My logic was that when the switch was checking it's lookup table to see to which port MAC "X" was connected, it would see the first entry, stop looking, and send it the data - X' I thought would never actually be seen in the lookup table, since presumably the switch would stop looking when it found X.

Which brings me to a tangential subject: I propose that people who use the phrase "It was in the last place I look" should be deported. It's yet another phrase with no actual meaning behind it; most people stop looking when they find something, so naturally it's going to be in the last place you look ("Honey, I found the keys but I'm going to check the couch and the front porch and make sure they're not there!"). Anyway...

The effect, I presumed, would be a 'ghost sender' throwing frames at the switch but never receiving a response. As it turns out, the switch is smarter than that (I didn't REALLY think the people at Cisco hadn't thought of that, it was just an idea).

Each time a frame is received by the switch, it apparently re-learns the MAC. When X sends something via port Fa0/1 the switch says 'Oh okay, you're on Fa0/1 - let me write that down'. Then when X' sends a frame via port Fa0/2 the switch snidely quips 'Wow, you get around, you port-hungry devil, you!' and re-learns the MAC. This is of course, assuming that switches are capable of 'quipping' (the latest research suggests they are - I know they can be snidely).

After that happens, let's assume that the traffic in response to the request X sent earlier shows up. The switch (being worried that the traffic was out that late) says "Where were you, Series Of Bits?! This is not a hotel! Go to your room it's right..." - the switch examines the lookup table - "...THERE!" and gestures angrily at port Fa0/2.

Series Of Bits, obediently goes to port Fa0/2 to find a very surprised X'. X' looks at Series Of Bits with a visage similar to when you haven't ordered a pizza and one shows up anyway. "Anybody order a series of bits??" it hollers. "Yeah, says Thomas J. Program, peaking head through the NIC's door. "But not THAT series of bits."

Meanwhile, poor, poor X is waiting for a Series Of Bits that never comes. We can only assume it begins to cry. The point of all that (other than that I'm CLEARLY single if I had the time to write all that) is that when two identical MACs are connected to the same switch bot experience seemingly abruptly random traffic as the switch learns and re-learns the MAC. Why the hell didn't I just SAY that? Because I was bored. But now I'm not.

Note: I was tempted to give the NICs a Brooklyn accent and make a "New York NICs" joke, but decided against it. You can thank me in US Dollars.