Messages

They work, just syntax and documentation are janky as. HP used to sell them before they aligned the whole current stack under Aruba.

This.

We have some 5900's at work running Comware code (installed before my time)... in fairness, they've actually been really stable. The documentation is really shit and obviously the syntax is a weird if you're used to Cisco but all in all they're pretty powerful boxes. Also, SNMP polling can be a bit of a challenge too.

5505 acts as a small switch, none of the others do.

5506 does this now, it didn't when first released but they introduced it in 9.7 IIRC.


Have a look at pfSense, I've only used the VM briefly but it seemed pretty solid and it gets a lot of good feedback. Looks like you can run it on hardware too:

https://www.pfsense.org/products/

For hospitals, the biggest challenge is getting a change window. Over and above any petty politics doctors or administrators may pull, that change window is very hard to come by, more difficult than getting one in manufacturing.

This.

I worked in a hospital for many years, it's good in one sense because everything needs to be highly available and fast, i.e. good routing and switching gear, lots of Wireless, Security, UC and enterprise goodies, however getting a change window can be a nightmare so the rate of change is slow. Also bear in mind that if you screw up, the impact can be that people die. This can be overbearing depending on how well you cope under pressure.

I've never worked for a reseller but the feedback I get from people I know is that if you get a good one and are top of the tree, i.e. IE level, then it can be very rewarding. If you're entry to mid level then you're just thrown wherever they need you to do pretty much whatever they need, i.e. lots of travel, lots of learning on the job etc.

Nice work heath 

Slightly off topic question, but what use case would you use "object-group service xxx tcp" and being limited to only specifying tcp port numbers vs "object-group service xxx" and being able to add UDP and TCP ports? I have not found any features that don't work with the second style, and it is more flexible.

-Otanx

I've often wondered the same thing. My guess is that there isn't one and it's a legacy command from earlier code that's retained for compatibility... it's only a guess though

It's not this is it?

Code Select Expand

sh threat-detection statistics top


Also, this is quite a handy tool:

https://www.tunnelsup.com/cisco-asa-show-connections-analyzer/

Sounds like a good idea in principal, I like Opus, the quality is great between Jabber or deskphones that support it!

However, not sure the CUBE supports it, doesn't seem to appear on the supported codecs list:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/cube-codec-basic.html#concept_481BE95CF6AB447C9DB4C46866FDA2D5

In our case, for low BW connections, we usually run g.729 to the CUBE, then transcode to g.711 which is the only codec our ITSP supports.

Stick it on Eval licensing for 90 days, have a play and then activate your PAK's.

There's also the FTDv which is worth running in the lab to play about with. FirePower in general is quite a learning curve I've found, it's an awesome bit of kit when you understand everything it's doing under the hood, but it's still a bit clunky with ASA+FP Services.

I'd recommend Micronics Zero 2 Hero Sec training if you can get work to pay and have the time. They cover a lot of FP on that.

Also, Todd Lammle has started doing a specific FP course online and in person too, I've not attended that but heard good things on LinkedIn etc.

Are you licensed for AMPs and IPS?

Are you running FMC?

Have you created some schematics of the current and future setup?

I'd suggest doing that first, both from a physical and logical perspective. Think about the services you're replacing, I.e NATs, routing, DMZ, Remote Access, S2S VPN's etc. Break it down bit by bit and carefully plan what's involved in migrating each element. Take this opportunity to clear out any stale rules, 'show access-list | inc (hitcount=0)' is your friend here.

As already said, a Big Bang can be done but it all comes down to complexity and risk.

Is there a reason you're not running FTD?

Bug ID: CSCvc35378

Apparently they are working on making it externally visible.

Can't see it externally yet

Looks like the IRB doesn't work properly either:

https://supportforums.cisco.com/discussion/13221411/vpn-handle-error-new-asa-971-integrated-routing-and-bridging-feature

TAC got back to me today. They advise that 9.7.1 will crash when traffic is routed across the VTI tunnel.

The issue is fixed in 9.7.1.2 which is not yet released.


 

Here's the email chain

H Tony,

The issue seems to be matching an internal bug which should to be fixed in 9.7.1.2.

The issue seems to trigger during route-look up followed by tmatch_domain_lookup due to invalid meta L3 type changed while processing the traffic from cp to dp.

Hi [name deleted],
Thanks for the update. Is this issue affecting only VTI? IS there any immediate workaround?

I only updated to this release to utilise the long-anticipated VTI tunnel on the ASA, does this feature work in 9.7.1 at all? I gather from your email that VTI although present and available to configure, it's not actually functional. I'm trying to discover whether this issue is related to my configuration in whole on the ASA or due to the code itself.

Many thanks,
tony

Hi Tony,

Yes this issue occurs when the traffic goes through VTI tunnel on ASA. There is no work-around as of now. Upgrading to 9.7.1-2 should have the fix for the issue.

That sucks! I labbed it out on ASAv a couple of days after the code was released and it seemed to work okay in basic form with BGP and a spoke CSR1000v. Glad I didn't take it much further!

Been bolted to a CUCM project for months which we're just coming to then end of (only UCCX remaining). It's been quite good fun playing with Telepresence for the past couple of weeks but that's about as good as it gets. Collaboration is NOT my bag...

Hey Dieselboy, the 5506 (until 9.7) doesn't support any L2 switching at all. Crazy, I know! I made the mistake of ordering 3 for a project and it wasn't until implementation that I found out. Do a quick google and you'll see a lot of people complaining about it which I why I guess they've introduced IRB into the new code. Who the hell needs 8 x 1Gbps L3 ports on a SOHO device!? :|

http://www.cisco.com/c/en/us/td/docs/security/asa/asa97/release/notes/asarn97.html

Finally they've introduced support for Layer 2 switching on the 5506! That's been a real bugbear of mine!

New default configuration for the ASA 5506-X series using Integrated Routing and Bridging
A new default configuration will be used for the ASA 5506-X series. The Integrated Bridging and Routing feature provides an alternative to using an external Layer 2 switch. For users replacing the ASA 5505, which includes a hardware switch, this feature lets you replace the ASA 5505 with an ASA 5506-X or other ASA model without using additional hardware.
The new default configuration includes:
outside interface on GigabitEthernet 1/1, IP address from DHCP
inside bridge group BVI 1 with GigabitEthernet ½ (inside1) through 1/8 (inside7), IP address 192.168.1.1
inside --> outside traffic flow
inside ---> inside traffic flow for member interfaces
(ASA 5506W-X) wifi interface on GigabitEthernet 1/9, IP address 192.168.10.1
(ASA 5506W-X) wifi <--> inside, wifi --> outside traffic flow
DHCP for clients on inside and wifi. The access point itself and all its clients use the ASA as the DHCP server.
Management 1/1 interface is Up, but otherwise unconfigured. The ASA FirePOWER module can then use this interface to access the ASA inside network and use the inside interface as the gateway to the Internet.
ASDM access—inside and wifi hosts allowed.
NAT—Interface PAT for all traffic from inside, wifi, and management to outside.
If you are upgrading, you can either erase your configuration and apply the default using the configure factory-default command, or you can manually configure a BVI and bridge group members to suit your needs. Note that to easily allow intra-bridge group communication, you need to enable the same-security-traffic permit inter-interface command (this command is already present for the ASA 5506W-X default configuration).

Looks like the VTI is in there too

Virtual Tunnel Interface (VTI) support for ASA VPN module
The ASA VPN module is enhanced with a new logical interface called Virtual Tunnel Interface (VTI), used to represent a VPN tunnel to a peer. This supports route based VPN with IPsec profiles attached to each end of the tunnel. Using VTI does away with the need to configure static crypto map access lists and map them to interfaces.
We introduced the following commands: crypto ipsec profile, interface tunnel, responder-only, set ikev1 transform-set, set pfs, set security-association lifetime, tunnel destination, tunnel mode ipsec, tunnel protection ipsec profile, tunnel source interface.