The last week i've been experimenting with an ES20 card and i must say i'm impressed. A lot of nice features (that should be standard in the simple 6500/7600 LAN cards too) are included while some other are there to help you accomplish whatever ethernet scenario comes into your mind.
These are some features that differentiate it from the simple 67xx cards:
- Subinterfaces
- Subinterface Switchport / Subinterfaces MultiPoint Bridging (MPB) with Spanning Tree
- Ethernet Multipoint Bridging with Local VLAN significance per port
- Double-tag IP termination
- Flexible QinQ mapping and termination
- many MPLS features
- many QoS features
The ES20 card supports (among other) the following L2 features:
Flexible QinQ Mapping and Service Awareness
The Flexible QinQ Mapping and Service Awareness on 7600-ESM-2X10GE and 7600-ESM-20X1GE feature allows service providers to offer triple-play services, residential internet access from a DSLAM, and business Layer 2 and Layer 3 VPN by providing for termination of double-tagged dot1q frames onto a Layer 3 subinterface at the access node.
MultiPoint Bridging over Ethernet (MPBE)
The MultiPoint Bridging over Ethernet (MPBE) on 7600-ESM-2X10GE and 7600-ESM-20X1GE feature provides Ethernet LAN switching with MAC learning, local VLAN significance, and full QoS support. MPBE also provides Layer 2 switchport-like features without the full switchport implementation.
Both features are supported only through Ethernet Virtual Connection Services (EVCS) service instances.
EVCS uses the concepts of EVCs (Ethernet virtual circuits) and service instances. An EVC is an end-to-end representation of a single instance of a Layer 2 service being offered by a provider to a customer. It embodies the different parameters on which the service is being offered. A service instance is the instantiation of an EVC on a given port on a given router.
This was my test setup regarding the ES20 :
CISCO7609
WS-SUP720-3BXL
7600-ES20-GE3C
IOS 12.2.33SRC
I also used 2 6500s (with 6724-SFP cards) and 2 routers (7200s), creating an ethernet-only network like the following:
Router-1 <===> 6500-1 <===> 7609 <===> 6500-2 <===> Router-2
My objectives were the following:
1) Start from single-tag ip termination (Router-1) and end to double-tag ip termination (Router-2)
2) Translate an outer vlan to a new one (2999 => 3999) while moving from 6500-1 to Router-2, leaving the inner vlans unchanged and vice versa
3) Terminate an outer-vlan/inner-vlan pair (2999/103) locally on the 7609
4) Apply some egress QoS (shaping, LLQ) on the above 2 vlans on the 7609
Router-1 <===> 6500-1
Router-1 interface is an ethernet interface with many ip subinterfaces
interface GigabitEthernet0/2.101
description ** 6500-1 - vlan 101 **
encapsulation dot1Q 101
ip address 10.101.0.1 255.255.255.252
!
interface GigabitEthernet0/2.102
description ** 6500-1 - vlan 102 **
encapsulation dot1Q 102
ip address 10.102.0.1 255.255.255.252
!
interface GigabitEthernet0/2.103
description ** 6500-1 - vlan 103 **
encapsulation dot1Q 103
ip address 10.103.0.1 255.255.255.252
6500-1 interface is a dot1q-tunnel (double-tagging all incoming frames)
interface GigabitEthernet3/9
description ** Router-1 **
switchport
switchport access vlan 2999
switchport mode dot1q-tunnel
mtu 9216
mls qos trust cos
mls qos cos-mutation COS-TUNNEL-MAP
spanning-tree bpdufilter enable
6500-1 <===> 7609
6500-1 interface is a trunk (allowing only the original outer vlan)
interface GigabitEthernet3/10
description ** 7609 Gi5/0/0 **
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 2999
switchport mode trunk
switchport nonegotiate
mtu 9216
mls qos trust cos
mls qos cos-mutation COS-TUNNEL-MAP
spanning-tree bpdufilter enable
7609 interface includes a service instance for the outer vlan translation
interface GigabitEthernet5/0/0
mtu 9216
service instance 2999 ethernet
encapsulation dot1q 2999
rewrite ingress tag translate 1-to-1 dot1q 3999 symmetric
The number 2999, which is used for defining the service instance, can be whatever you like; it doesn't have to be the same as the vlan number. I just used the same number for easiness.
The "encapsulation dot1q 2999" command defines the ingress match criteria for this service instance.
The "rewrite ingress tag translate 1-to-1 dot1q 3999 symmetric" command defines a 1-to-1 translation of the ingress matched vlan (2999) to 3999 and the opposite ("symmetric").
Generally, the service instance is "equivalent" to a trunk port.
7609
The 7609 does mainly two things:
Outer vlan translation (see above) and egress shaping
class-map match-all TRAFFIC1
match cos 6 7
!
policy-map TRAFFIC1
class TRAFFIC1
shape average 128000
class class-default
shape average 10000000
!
interface GigabitEthernet5/0/0
mls qos trust cos
service instance 2999 ethernet
service-policy output TRAFFIC1
!
connect EVC1 GigabitEthernet5/0/0 2999 GigabitEthernet5/0/1 3999
The "connect EVC1..." command creates the evc that connects the 2 service instances of the 2 interfaces of the 7609.
IP Q-in-Q termination for a specific outer-vlan/inner-vlan pair and egress LLQ/policing
class-map match-all TRAFFIC2
match cos 3 5
!
policy-map TRAFFIC2
class TRAFFIC2
police 5000000
priority
class class-default
shape average 1000000
!
interface GigabitEthernet5/0/0.2999103
description ** local termination - vlan 2999/103 **
encapsulation dot1Q 2999 second-dot1q 103
ip address 10.103.0.2 255.255.255.252
service-policy output TRAFFIC2
Policing must be used together with priority for LLQ.
7609 <===> 6500-2
7609 interface includes a service instance for the outer vlan translation
interface GigabitEthernet5/0/1
description ** 6500-2 **
mls qos trust cos
service instance 3999 ethernet
encapsulation dot1q 3999
rewrite ingress tag translate 1-to-1 dot1q 2999 symmetric
6500-2 interface is a trunk (allowing only the translated outer vlan)
interface GigabitEthernet3/11
description ** 7609 Gi5/0/1 **
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 3999
switchport mode trunk
switchport nonegotiate
mtu 9216
mls qos trust cos
mls qos cos-mutation COS-TUNNEL-MAP
spanning-tree bpdufilter enable
6500-2 <===> Router-2
6500-2 interface is a trunk (allowing only the translated outer vlan)
interface GigabitEthernet3/12
description ** Router-2 **
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 3999
switchport mode trunk
switchport nonegotiate
mtu 9216
mls qos trust cos
mls qos cos-mutation COS-TUNNEL-MAP
spanning-tree bpdufilter enable
Router-2 interface is an ethernet interface with the remaining IP Q-in-Q subinterfaces
interface GigabitEthernet0/2.3999101
description ** 6500-2 - vlan 3999/101 **
encapsulation dot1Q 3999 second-dot1q 101
ip address 10.101.0.2 255.255.255.252
!
interface GigabitEthernet0/2.3999102
description ** 6500-2 - vlan 3999/102 **
encapsulation dot1Q 3999 second-dot1q 102
ip address 10.102.0.2 255.255.255.252
Btw, the CCO configuration page about ES20 must be one of the worst ever written. Many configuration examples are wrong (they probably haven't even tried them), while some other are missing explanations.
Posts
Hi,
ReplyDeleteSo you are saying that you won`t be able to create subinterfaces on 67xx cards? (don't know the answer, want to find out)
Per instance a WS-X6724-SFP on a CISCO7609-S with a RSP720-3CXL-GE.
You know if they support QPPB (both the 67xx and the ES20s)?.
Thanks in advance.
Subinterfaces are supported in most releases after SXF (SRA added some features), as long as you don't configure the same vlan on different interfaces. Also there are some limitations with vtp client/server mode and normal range vlans and you can only have single tag subifs.
ReplyDeleteMultiplexing of L2 and L3 services under the same physical interface, using different subifs is supported using the MUX-UNI (Multiplexed User-Network interface) feature.
But (if i remember right), only MPLS is allowed as encapsulation in the xconnect command under the subifs (so they are of limited usage).
So "real subinterfaces", like the ones that are used on routers, need the ES cards. But generally... yes, subinterfaces are supported on LAN cards.
Regarding the QPPB support, i think it's a "limitation" of the 6500/7600 hardware/software (all ios versions i have tested do not support it, although it's in the cli), so it seems it doesn't depend on the various cards.
Hello,
ReplyDeleteI currently have 8 Cisco 7609 routers with the ES-20 cards in them. I must say, the days of subinterfaces are gone. You can now create service instances by the large number. So there can be a service instance for;
Bridge-domain
advanced l2vpn ie; VPLS(point to multi-[point)
MPLS(pseuedowire)
I have 1 ES-20 with 20 gig ports for access
and 2 ES-20 2 10gig ports for trunking.
Using ISIS for IGP, and the trunking ports are carried via 15454 and XPonder adapters.
Regards
Jude Bryant
Jude, although i can't think right now of any limitations of service instances vs subifs, the EVC framework still misses some functionality regarding various snmp counters, so subifs are more than welcome in such cases.
ReplyDeleteBtw, i'm waiting for an order of the new ES+ cards which offer even more features. The only thing that worries me is that they need the SRD release.
Sorry for commenting such old post, but it's the only place pointed by google on my keywords:)
ReplyDeleteWe have ES20 card and have tried to enable trafic shaping (and tried policer too)
That one:
interface GigabitEthernet5/0/0
service instance 2999 ethernet
service-policy output TRAFFIC1
The thing is that system allows such config, but tests show that policy-map applied to service instance does not drop/queue any packets. So with 130kbs policer we can have 5mbs.
And same policy-map seems to be working (dropping excess traffic) on normal, not ES20 service instance, interfaces.
dework,
ReplyDeleteIf you could post the whole efp & qos config, i could better understand your issue.
In any case, you can find more information at http://www.cisco.com/en/US/docs/routers/7600/install_config/ES20_config_guide/bald_qos.html#wp1374297