phaqphaq

This february I had my 30th birthday. My boss surprised me with an eeePC 1000H as an unexpected as well as also a very cool gift

Ok, I must admit, that I took a glimpse at the tiny netbooks more than once. My dream was to actually run it with OS X instead of Windows or Linux.

So, just the next-day my netbook was OS X-ified (a topic, which I’ll cover later on), only to notice some more or less annoying issues.

One of the most annoying issues was the stock WiFi, which required a very ugly 3rd party tool for configuration and was so absoluty not OS X-alike.
(more…)

Well, well, well …

I just stumbled accross a minor difference between Cisco and Foundry, the latter being mostly Cisco-alike.

To update an ACL on Cisco devices (at least the ones I encountered so far) I usually do this:

conf t
!
no ip access-list extended MY_ACCESS_LIST
!
ip access-list extended MY_ACCESS_LIST
    my permit/deny list entries
!
end

This results in immediate application of the access list, so we’re just fine and happy.

Doing the same on a Foundry results in… nothing.
Well, not quiet, at least the changes are applied in terms of “visibility” in the running config or with a “sh access-list name MY_ACCESS_LIST” statement, but they are not enabled.

Once more RTFM holds true, especially when talking about “familiar devices”, which we usually understand well enough to work with easily (which usually holds for most Cisco-alikes), but ommit reading the entire manual for exact THAT reason. Honestly, how many of you REALLY (I mean REALLY!) do this ….?

In this case I learned from the manual, that a Foundry/Brocade devices needs an implicit reload of the access lists after modying them (Dough!).

The command line should effectively read:

conf t
!
no ip access-list extended MY_ACCESS_LIST
!
ip access-list extended MY_ACCESS_LIST
    my permit/deny list entries
!
ip rebind-acl all
!
end

So, I could have saved me 15 minutes if I HAD actually read the manual section about ACL before …