I'm in the process of configuring QoS on Nexus 9k.  I've finally started to wrap my head around the differences in the 9k compared to the Catalyst, and am making progress... but have run into one issue: The 2k FEX only supports COS to queue mapping.  This is fine; I have a system-level qos policy which maps COS to appropriate qos-groups.  When the traffic arrives at the 9k (93180YC-EX switches), I want it to be marked with the correct PHB so that we can ensure end-to-end QoS as the upstream switches are a pair of Catalyst 6k's.  From what I have been reading, I should be able to apply my policy-map which performs classification and marking to the FEX uplink ports. However, when attempting this, the 9k doesn't seem happy: switch-dc-1(config-if)# int po111 switch-dc-1(config-if)# service-policy type qos in MARKING Interface port-channel111 is a fex fabric port Cannot apply qos policy. How can I classify and mark traffic with DSCP coming from the FEX into the 9k?  We need more granular control over the queuing from the datacenter into the campus.  I'm either missing something or this isn't supported... any input is appreciated! Thanks -P ... View more

  We have a fairly common edge config:  - Our own public ASN  - An ARIN-assigned address block  - Two routers, two ISPs.  Full BGP routes from the providers and iBGP running between the edge.  - IPSec SAs established from each router to various upstream services   A recent flap reminded me that the IPSec SAs aren't tied to the respective routers - there's a shorter path to the upsteam IPSec peer through one of our ISPs, so both routers use that ISP for the endpoint IP.  Obviously, we want the edge routers to ignore the iBGP routes for the remote IPSec endpoints so that an outage of one ISP will not cause all the tunnels to go down and reconnect.   I can think of a few different ways to do this (route-map with a prefix list inbound from the iBGP peer which reduces the local preference, route-map setting a community for inbound routes and then modifying local pref accordingly, etc).  However, how would I go about this when I can assume that I don't know the prefix length?   Example - I have disparate IPSec endpoints, a.a.a.a/32 and a.a.a.z/32.  Sure, I can look at the BGP table and see that I'm receiving an advertisement for a.a.a./22 - but I would be remiss in assuming that this will never change.  If I set a prefix-list for a.a.a.a/22 le 32 or similar, that will get hosed if the upstream starts advertising a /21 or larger.   I'm sure there are probably numerous ways to accomplish this, but I'm looking some ideas on how others may have gone about influencing the outbound traffic for a single IP or a subnet that will be contained in a summary route which may change.   Thanks! -P ... View more

Hi all, I'm having a problem with ZBFW appearing to cause retransmits when connecting from an inside host to a host on the remote side of the DMVPN.  ICMP appears to work fine, but RDP ends up with two sessions: one established and one half-open.  When the half-open session times out, the connection dies. What's interesting is that initiating a connection from a DMVPN host to an internal host, the connection gets established and I can stay connected all day with no problem.  The router in question is a 7206vxr running 15.1(4)M7, and it serves as an internet edge router.  All routes are present (EIGRP over DMVPN) and internet access is fine. If I move the tunnel interfaces into the LAN security zone, no problem.  Traffic flows from inside to outside.  It's just when I have them into a separate zone, things get strange.  I'm posting a sanitized config in case there's some glaring issue I've missed. Output from 'sh policy-map type inspect zone-pair LAN-to-DMVPN sessions' when initiating an RDP session: policy exists on zp LAN-to-DMVPN Zone-pair: LAN-to-DMVPN   Service-policy inspect : LAN-to-DMVPN     Class-map: LAN-to-DMVPN (match-all)       Match: access-group name LAN-to-DMVPN    Inspect       Number of Established Sessions = 1       Established Sessions         Session 68AFD3A0 (192.168.77.160:3623)=>(172.23.2.13:3389) tcp SIS_OPEN/TCP_ESTAB           Created 00:00:09, Last heard 00:00:09           Bytes sent (initiator:responder) [0:0]       Number of Half-open Sessions = 1       Half-open Sessions         Session 68B027A0 (192.168.77.160:3623)=>(172.23.2.13:3389) tcp SIS_OPENING/TCP_SYNSENT           Created 00:00:09, Last heard 00:00:09           Bytes sent (initiator:responder) [0:0]     Class-map: class-default (match-any)       Match: any       Drop         0 packets, 0 bytes Note the same source and destination pairs with different session IDs. Now, when I connect from DMVPN to LAN via RDP: policy exists on zp DMVPN-to-LAN Zone-pair: DMVPN-to-LAN   Service-policy inspect : DMVPN-to-LAN     Class-map: DMVPN-to-LAN (match-all)       Match: access-group name DMVPN-to-LAN    Inspect       Number of Established Sessions = 1       Established Sessions         Session 68B051A0 (172.23.2.13:55622)=>(192.168.77.160:3389) tcp SIS_OPEN/TCP_ESTAB           Created 01:21:17, Last heard 00:00:00           Bytes sent (initiator:responder) [585503:10830828]     Class-map: class-default (match-any)       Match: any       Drop         2 packets, 40 bytes Also note that this connection has been up for over an hour, and it does _not_ create the half-open session when the initial connect takes place. Any ideas? Thanks! -P ... View more