interesting thread, that doesn't seem to die. I worked at ASA shops, then went to PaloAlto shops. and now back at an ASA shop. the lack of switching in 5506-x is new to me, since I haven't worked with them in the past 4 years. I will reiterate that Cisco ASA team has officially, for years, been on a downward spiral. I almost crapped my pants when I found out that there was no switchport on the 5506-x, especially since there are 8 freaking ports on the dam thing. So i will change my comment to ASA team is has officially gone "stupid," or whatever the hell you want to say. First off, why 8 dam ports on a SOHO device - unless you make them a switch? Nobody is going to have 6+ routed subnets in a SOHO deployment? So I would almost give Cisco a "F", but for a good college try. but why not build the dam thing with 3-4 ports then - if they are going to be only routed?   So you are now officially stupid as a team, and didn't even try. It almost like someone opted to make a rube-goldberg type of ASA firewall just for the **bleep**s/giggles. Only, it actually got productized?!?!?! I guess that's what too much money does to a company. Anyway, this trend is disheartening. I was around for the ACE load-balancer, which was a fine device, until Cisco killed it off.   And i have seen the downward spiral of the switch platform as Cisco tries to push overly complicated SD networking, and diminish the 2960 line. And Cisco phone systems have become an untamed outlandishly complicated beast. So man, I would start dumping Cisco stock ASAP. Look at Ubiquiti, Palo Alto, A10, Citrix, F5, Digium, Shoretel, HP, Aruba.   BTW... i played around with the BVI interface thing on the ASA 5506x, and its equally stupid. Here are some issues: 1. the BVI interface doesn't accept ACL's like a regular interface (making it not like a VLAN) 2. to manage the ASA from the inside G1/X ports, you need to configure ssh/http management command for each G1/x port. this should normally go on the Vlan=BVI interface only, as the G1/x ports are bound to that broadcast domain. Very strange. 3. In ASDM, the Inside interface shows "down", even though its up and attached to BVI interface. Whats up with that?!?!? 4. The general config bloat and unnecessary nat/acl commands required at each G1/X interface suggest something is really wrong. 5. im seeing some strange ICMP connection loss error message, probably related to the crappy BVI implementation. I shodul say that I cannot ACL my way out of the error with a very liberal allow rule, so there has to be some sort of ASIC hardware **bleep** going on under the covers that i cannot fathom.   So WTF cisco! From "firepower" to "firesale"! activate your wonder twin powers quickly! ... View more

still doesn't work in version 3. LOL ... View more

according to every MQE switching document I have read for the past 15+ years, the call quality would suffer without the appropriate QoS commands on the switchport. I could have missed something that is newly released but im pretty sure these commands need to be there.   This bug and its release notes are stupid and disheartening at the same time. there should be at least a workaround mentioned so that one can run QoS on all access ports conveniently. ... View more

just had this problem on a newer cisco 3560cx, and was able to work around by:   1. blow away all "auto qos" of same type on all applied interfaces on switch 2. re-apply the "auto qos" of desired type on 1 or more interfaces. thx for the tip! didn't need TAC. ... View more

interesting thread that seems to continue on into 2018. Searching the web, I was able to find vendors that make cisco compatible 10G-BaseT SFP+. search for this: "cisco SFP-10G-T. there are a few on amazon. It even looks like HP sells their own such product!   I would like to hear a cisco-certified answer, why lack of 10Gbase-T SFP+ continues into 2018. curious minds want to know. :)   As a side note, I was reviewing the Cisco 4900M switch which is EOS soon. the recommended upgrade path is the 4500-X switch, which doesn't have any 10 Gbase-T option - to the best of my knowledge. So it seems like they are going backwards, taking 10 Gbase-T out of the 4900M and suggesting customers go to a fiber/twinax-only solution.   Any insiders have enlightening answers?         ... View more

hello gane, hope you can work through the problem. this was about 2 years ago for me and my memory is a bit foggy. I think I had to obtain the special firmware for the module itself. also, keep in mind that the NM version of module does some advance network monitoring (netflow) and needs to be paired with the correct switch OS. so you may get an error if your switch license level doesn't support the NM monitoring. also, I vaguely remember the upgrade taking a really long time for programming phase - like 10-15 minutes before the reload. ... View more

hi I see this general problem on IPsec L2L tunnel between two cisco routers. is there any sort of smart dhcp relay option now to allow dhcp relay to originate the request on behalf of some other address, such as router loopback; or to make this dhcp relay function work on a router over VPN tunnel? many thx in advance! ... View more

hey phil, once I distribute the RRI into either EIGRP or OSPF, I can set the tag. this tag should be carried through the IGP, and be usable for manipulating the BGP redistribution. the P2P DC link runs the IGP. the MPLS is a second network in/out of each DC. so both DC's do have awareness of the RRI route. Im still testing this solution, but I think I can set the origin somehow with BGP based on the EIGRP or OSPF route tag. prepend AS based on a route tag is not supported within BGP - at least that's what the error message implies. If I cannot add the origin in some way as a path prepended, I think I can do this with communities and filtering the MPLS inbound BGP RRI route (from the other DC), based on a preset community. Here are come cool links on BGP origin tagging from IGP: http://packetlife.net/blog/2009/jan/19/bgp-route-auto-tagging/   https://ccieblog.co.uk/bgp/bgp-automatic-tag-as-path-tag ... View more

hey phil, thx for quick reply. if I redistribute the RRI route into BGP at both sites, it will be come an equal hop path out on MPLS network from both DC's. I want to prefer the DC that originally got the RRI. And I cannot redistribute into EIGRP at both sites, but by doing the redis. at DC1, the EIGRP relationship with DC2 will carry the route across. After some more research today, I think I can do this as follows, but its going to require OSPF, as the RRI device is ASA and ASA doesnt support 'tags' in EIGRP. 1. receive route on ASA 2. on ASA, tag it with route tag 65001/65002 for each DC respectively. these are just tags representing the AS. not actually used as AS. DC1 tags with 65001; DC2 with 65002. 3. on ASA, RRI route into IGP, which has to change to OSPF. :( 4. OSPF carries the route everywhere (both DC's). 5. redis. the OSPF route into BGP at both DC's, but use a route-map to match the tag. 6. the site without the incorrect tag will just drop the route; the site with correct tag does the redis. I'm still playing around with running BGP solely and removing the IGP (EIGRP/OSPF) entirely, but not quite sure I want to do that yet. may lab it up tomorrow to the extent I can. ... View more