what did you learn today?

Check out Cisco's ISE, it couples centralized MAB with posture which adds some real intelligence to it. If you MAB a printer and someone spoofs the mac, but doesn't act like a printer it can figure it out and updated access policy etc.

We had a presentation about this from Cisco a few weeks ago, and to be perfectly frank that behavior classification feature whiffs a little bit like snakeoil, and also like a recipe for headaches down the road because someone, somewhere built a printer that doesn't behave like the ISE thinks it should behave.

Check out Cisco's ISE, it couples centralized MAB with posture which adds some real intelligence to it. If you MAB a printer and someone spoofs the mac, but doesn't act like a printer it can figure it out and updated access policy etc.

We're using ISE actually. We have a giant list of allowed endpoints and a couple of really simple policies. We're not using it for anything cool.I'm not a huge fan though. There's a bug in some oracle db component in the thing that starts consuming disk space until it kills itself. Happened at an inopportune moment and we weren't able to get anything useful from Cisco for weeks. They eventually gave us a script that cleans the db out and frees up space. Unfortunately it broke something in the boxes so we had to take the admin role away from a secondary node.

Check out Cisco's ISE, it couples centralized MAB with posture which adds some real intelligence to it. If you MAB a printer and someone spoofs the mac, but doesn't act like a printer it can figure it out and updated access policy etc.

We had a presentation about this from Cisco a few weeks ago, and to be perfectly frank that behavior classification feature whiffs a little bit like snakeoil, and also like a recipe for headaches down the road because someone, somewhere built a printer that doesn't behave like the ISE thinks it should behave.

It's customizable, you're not stuck with the profiling criteria out of the box (and they update it). It certainly works for people, though I'm sure not perfectly, and is def 100% better than plain old device level MAB.

Check out Cisco's ISE, it couples centralized MAB with posture which adds some real intelligence to it. If you MAB a printer and someone spoofs the mac, but doesn't act like a printer it can figure it out and updated access policy etc.

We had a presentation about this from Cisco a few weeks ago, and to be perfectly frank that behavior classification feature whiffs a little bit like snakeoil, and also like a recipe for headaches down the road because someone, somewhere built a printer that doesn't behave like the ISE thinks it should behave.

Check out Cisco's ISE, it couples centralized MAB with posture which adds some real intelligence to it. If you MAB a printer and someone spoofs the mac, but doesn't act like a printer it can figure it out and updated access policy etc.

We had a presentation about this from Cisco a few weeks ago, and to be perfectly frank that behavior classification feature whiffs a little bit like snakeoil, and also like a recipe for headaches down the road because someone, somewhere built a printer that doesn't behave like the ISE thinks it should behave.

I finally broke down and read about that. The problem isn't the PIX/ASA code itself, though it could be better I guess. The problem is in the protocol implementation in some servers/clients. The SMTP commands are supposed to be sent one command at a time. Instead, some servers/clients send them one character at a time resulting the the firewall seeing 'e-h-l-o' instead of ehlo, or 'r-c-p-t- -t-o' instead of rcpt to, for example. This leave the firewall going, 'e is not a valid SMTP command, h is not a valid SMTP command', and so on. It sucks, and they could probably fix it, but I can see how it happened and why Cisco doesn't really see it as their fault (though it is their problem).

The point of the SMTP/ESMTP inspection engine is to check for strict protocol adherence - or the entire point is to prevent non standard implementations from working. On by default maybe was a borderline poor choice (I can see it both ways) but it does exactly what it says it does. People misunderstanding that isn't really Cisco's fault - except for possibly the failure to implement different naming conventions for inspections required to support a protocol through NAT/FW (FTP, TFTP, ICMP, etc) and ones designed to enforce standard protocol behavior.

Today I learned that when someone wants to make free phone calls, they really want to make free phone calls. Going on for 36 hours now, even though the firewalls are dropping the packets, some wanker from Germany has been trying to register phones to various servers in my ACD cluster.

The point of the SMTP/ESMTP inspection engine is to check for strict protocol adherence - or the entire point is to prevent non standard implementations from working. On by default maybe was a borderline poor choice (I can see it both ways) but it does exactly what it says it does. People misunderstanding that isn't really Cisco's fault - except for possibly the failure to implement different naming conventions for inspections required to support a protocol through NAT/FW (FTP, TFTP, ICMP, etc) and ones designed to enforce standard protocol behavior.

Cisco was blocking standards-compliant ESMTP/SMTP, though. ESMTP has a negotiable extension for pipelining, for instance. There are good reasons why most people had to disable that poor attempt at fixing protocol compliance.

TIL that Dell apparently canned our sales rep without telling us, and now I'm not sure who to e-mail to put in an order via PO.

We never got a Premier site because we weren't spending enough to get their attention, so now I may have to stick $800-1600 of LCDs on my credit card.

OTOH, HP is apparently assigning a rep to us due to our spend level, even though we buy directly from CDW (so I'm not exactly sure what purpose the rep would serve). Too bad HP's monitors aren't as nice as Ultrasharps.

The point of the SMTP/ESMTP inspection engine is to check for strict protocol adherence - or the entire point is to prevent non standard implementations from working. On by default maybe was a borderline poor choice (I can see it both ways) but it does exactly what it says it does. People misunderstanding that isn't really Cisco's fault - except for possibly the failure to implement different naming conventions for inspections required to support a protocol through NAT/FW (FTP, TFTP, ICMP, etc) and ones designed to enforce standard protocol behavior.

Cisco was blocking standards-compliant ESMTP/SMTP, though. ESMTP has a negotiable extension for pipelining, for instance. There are good reasons why most people had to disable that poor attempt at fixing protocol compliance.

Don't get me wrong, I'm not advocating for turning it on (or off), just that its behavior is documented, including the subset of ESMTP commands and RFCs supported. Again, on by default is certainly questionable, but the behavior is not undocumented.

He deployed multiple times to production without permission on a Friday and claimed he did it because I wasn't up to speed.

I will be looking at locking down his access to production and will have to learn to fight harder about sticking to process when the business side wants to change rules mid flight (giving the contractor root access to setup the production server to get things working 'faster').

TIL that apparently Infrastructure Navigator 2.0.something does not work with a fully patched 4.1 U3 Host. There are apparently build numbers that work on a 4.1 P03 (first time I've seen that notation). Good thing we're upgrading the Hosts next to 5.1

TIL that on Friday, Saturday and today we've had 15-20K call failures each day. And that according to my primary voice carrier, all the call examples for those failed calls are showing SS7 normal call clearing. This is going to be a fun one to troubleshoot.

TIL that on Dell PowerConnect 6200 series switches, when you use LAGs and jumbo frames, you need to set MTU 9216 on the LAG itself, not only on the member ports, and it has to be done through CLI, as there is no mention of this in the GUI or user manual.

Today, I learned that is you move the last VM of a vApp in vCloud director, any attempt to create a new VM in that vApp or move an existing VM to that vApp will fail with "unknown error". Of course, you will not be able to stop or delete the vApp so you're left with a ghost entry.

No big deal but I'll add it to the already hug heap of bugs, inconsistencies and shortcomings of vCloud directory 5.0.

TIL that on Dell PowerConnect 6200 series switches, when you use LAGs and jumbo frames, you need to set MTU 9216 on the LAG itself, not only on the member ports, and it has to be done through CLI, as there is no mention of this in the GUI or user manual.

This is a feature, not a bug

I keed, I keed.

Yeah, I learned the hard way that MTU needs to be set across the port, port channel, LAG, etc on Dell PowerConnects. Fun!

....although it doesn't specifically say so, that I can tell, the OAB on a SCC Exchange 2007 build, should be on the actual volumes assigned to the host and not the shared/clustered volume.

Or else OAB will stop updating after a short while.

That's not true at all. Our (E2k7 SCC) OAB is on a clustered volume and it works fine. It actually happens to be on my log drive.

It's true on mine.

I do it that way, blammo, error. I put it on the local storage instead of the isci presented cluster storage and it works great. I read up on the issue before doing it, and that's what I found out via Google.

....although it doesn't specifically say so, that I can tell, the OAB on a SCC Exchange 2007 build, should be on the actual volumes assigned to the host and not the shared/clustered volume.

Or else OAB will stop updating after a short while.

That's not true at all. Our (E2k7 SCC) OAB is on a clustered volume and it works fine. It actually happens to be on my log drive.

It's true on mine.

I do it that way, blammo, error. I put it on the local storage instead of the isci presented cluster storage and it works great. I read up on the issue before doing it, and that's what I found out via Google.

scorp? Authoritative answer please

The cluster storage wouldn't happen to be a CSV enabled volume would it? That could cause some issues...

....although it doesn't specifically say so, that I can tell, the OAB on a SCC Exchange 2007 build, should be on the actual volumes assigned to the host and not the shared/clustered volume.

Or else OAB will stop updating after a short while.

That's not true at all. Our (E2k7 SCC) OAB is on a clustered volume and it works fine. It actually happens to be on my log drive.

It's true on mine.

I do it that way, blammo, error. I put it on the local storage instead of the isci presented cluster storage and it works great. I read up on the issue before doing it, and that's what I found out via Google.

scorp? Authoritative answer please

The cluster storage wouldn't happen to be a CSV enabled volume would it? That could cause some issues...

....although it doesn't specifically say so, that I can tell, the OAB on a SCC Exchange 2007 build, should be on the actual volumes assigned to the host and not the shared/clustered volume.

Or else OAB will stop updating after a short while.

That's not true at all. Our (E2k7 SCC) OAB is on a clustered volume and it works fine. It actually happens to be on my log drive.

It's true on mine.

I do it that way, blammo, error. I put it on the local storage instead of the isci presented cluster storage and it works great. I read up on the issue before doing it, and that's what I found out via Google.

scorp? Authoritative answer please

The cluster storage wouldn't happen to be a CSV enabled volume would it? That could cause some issues...

Yup, it is.

Put it on a non CSV volume. MS specifically says HyperV only for CSV volumes.

....although it doesn't specifically say so, that I can tell, the OAB on a SCC Exchange 2007 build, should be on the actual volumes assigned to the host and not the shared/clustered volume.

Or else OAB will stop updating after a short while.

That's not true at all. Our (E2k7 SCC) OAB is on a clustered volume and it works fine. It actually happens to be on my log drive.

It's true on mine.

I do it that way, blammo, error. I put it on the local storage instead of the isci presented cluster storage and it works great. I read up on the issue before doing it, and that's what I found out via Google.

scorp? Authoritative answer please

The cluster storage wouldn't happen to be a CSV enabled volume would it? That could cause some issues...

Yup, it is.

Put it on a non CSV volume. MS specifically says HyperV only for CSV volumes.

People have very different definitions of how long is a "long power outage". Up to a certain point, it can make sense to add more battery strings to get extended runtime. Depends a lot on the intended lifetime of the installation. But there's a definite turning point. And it's measured in low-single-digit-hours. Not in days. That's what petroleum products are for.

It definitely still is relevant. The most useful thing to take away for our discussion is:

Quote:

If the registry value was accidentally removed and needs to be re-created, it should point to the shared location, not system drive (which is not shared), something like K:\OABGen, where K: is shared storage drive.

MS specifically states that the OAB folder should be on shared storage in a SCC. I'm not sure what Danger Mouse is doing, but it's not "Right(TM)."