EVC : Flexible Service Mapping

After 2 months of intense network re-designing (mixed with a little bit of vacation days) and following my two previous posts about Flexible Frame Matching and Flexible VLAN Tag Rewrite, i finally found some free time to write a post about the third step in configuring service instances using the EVC framework : Flexible Service Mapping.

Probably the biggest advantage of the EVC framework is the ability to support multiple services per physical port. This means that under a single physical port you can have any of the following mixed together :

- 802.1q trunk
- 802.1q tunnel
- Local connect
- Scalable EoMPLS (EoMPLS xconnect)
- Multipoint Bridging (L2 bridging)
- Multipoint Bridging (VPLS, SVI-based EoMPLS)
- L3 termination

Besides all of the above, by using the EVC framework you can combine multiple different services from different physical ports, i.e. when using multipoint bridging (aka bridge-domains), in order to put them into the same virtual circuit.



Local connect is a L2 point-to-point service between two service instances on the same system. The service instances can by under the same port (hair-pinning) or under different ports. In contrast with the traditional L2 bridging, this one doesn't use any MAC learning and it's solely between 2 points. Also Local Connect doesn't require any global VLAN resource.

In order to have the following two service instances connect to each other by a L2 point-to-point service, you need first to remove their difference, which is the outer tag (you can also remove both tags).

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10 second-dot1q 100
  rewrite ingress tag pop 1 symmetric

interface Gi1/2
 service instance 20 ethernet
  encapsulation dot1q 20 second-dot1q 100
  rewrite ingress tag pop 1 symmetric

! EVC-LC-10-20 is just a name for this point-to-point connection
connect EVC-LC-10-20 Gi1/1 10 Gi1/2 20

Note : You can use the same service instance number under different physical ports.

In order to have the following two service instances be connected by Local Connect, you don't need any VLAN tag rewrite, because they both have the same vlans.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10-20

interface Gi1/2
 service instance 20 ethernet
  encapsulation dot1q 10-20

connect EVC-LC-10-20 Gi1/1 10 Gi1/2 20

In order to have the following two service instances be connected by Local Connect, you can either translate the vlan on one of them, or remove the tags on both of them.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  rewrite ingress tag translate 1-to-1 dot1q 20 symmetric

interface Gi1/2
 service instance 20 ethernet
  encapsulation dot1q 20

connect EVC-LC-10-20 Gi1/1 10 Gi1/2 20

Scalable EoMPLS or EoMPLS xconnect is a L2 point-to-point service between two service instances on different systems. Like Local Connect it doesn't use any MAC learning and it's solely between 2 points. It also doesn't require any global VLAN resource (this applies to scalable EoMPLS only; for SVI-based EoMPLS check VPLS below).

You can have any VLAN tag rewrite configuration under the service instances, as long as you keep in mind the following :

a) If both sides are EVC based, then you need to have common VLAN tag rewrite configurations on both sides
b) If one side is not EVC based, then depending on whether it's a physical interface or a subinterface, you'll probably need to remove one tag from the EVC side (subinterfaces remove tags by default)

Note : By default, VC type 5 is used for EoMPLS. In case VC type 4 is negotiated and used, an additional tag will be added after the VLAN tag rewrite configuration and before the data gets EoMPLS encapsulated.

7600-1

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  xconnect 1.1.1.2 10 encapsulation mpls

7600-2

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  xconnect 1.1.1.1 10 encapsulation mpls

Note : Have a look at Scalable EoMPLS for additional information.

Multipoint Bridging uses the concept of bridge-domains. Bridge-domain (BD) is like a traditional L2 broadcast domain where MAC-based forwarding is used for communication between participants (i'll try to write a new post with more details about bridge-domains). Bridge-domains use global VLAN resources.

In the following example, three service instances are put into the same bridge-domain by translating the tags where necessary.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  rewrite ingress tag translate 1-to-1 dot1q 20 symmetric
  bridge-domain 20

interface Gi1/2
 service instance 20 ethernet
  encapsulation dot1q 20
  bridge-domain 20

interface Gi1/3
 service instance 30 ethernet
  encapsulation dot1q 30
  rewrite ingress tag translate 1-to-1 dot1q 20 symmetric
  bridge-domain 20

The bridge-domain ID represents the global VLAN used in the system. Extra care needs to taken in case of L2 trunk/tunnel ports participating in a bridge-domain :

a) L2 trunk ports remove automatically the tag on ingress and add it automatically on egress. Equivalent EVC ports need that to be done manually by using the appropriate rewrite actions.
b) L2 tunnel ports add a new tag on ingress and remove it on egress. Equivalent EVC ports do not need any similar rewrite actions, because by default bridge-domains add a new tag on top of the already existing one.

In the following example two ports (a L2 trunk port and an EVC port) are put into the same bridge-domain (Vlan 20). Tag 10 needs to be removed from the EVC port before it joins bridge-domain 20.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  rewrite ingress tag pop 1 symmetric
  bridge-domain 20

interface Gi2/1
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 20
 switchport mode trunk

In the following example two ports (a L2 tunnel port and an EVC port) are put into the same bridge-domain (Vlan 20). On the EVC port, tag 20 is added on top of tag 10 in order to have the incoming frames join bridge-domain 20.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  bridge-domain 20

interface Gi2/1
 switchport access vlan 20
 switchport mode dot1q-tunnel

VPLS or SVI-based EoMPLS can be accomplished by configuring xconnect under a SVI. This SVI is the same as the one defined by the bridge-domain ID.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10-20
  bridge-domain 30

interface Gi1/2
 service instance 10 ethernet
  encapsulation dot1q 10-20
  bridge-domain 30

interface Vlan 30
  xconnect 1.1.1.2 10 encapsulation mpls

By adding "split-horizon" after the bridge-domain ID in both service instances, there can be no L2 communication between them.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10-20
  bridge-domain 30 split-horizon

interface Gi1/2
 service instance 10 ethernet
  encapsulation dot1q 10-20
  bridge-domain 30 split-horizon

interface Vlan 30
  xconnect 1.1.1.2 10 encapsulation mpls

By adding an additional tag through a rewrite action in both service instances, you can differentiate them, while they are being transfered through the same VC.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10-20
  rewrite ingress tag push dot1q 21 symmetric
  bridge-domain 30 split-horizon

interface Gi1/2
 service instance 10 ethernet
  encapsulation dot1q 10-20
  rewrite ingress tag push dot1q 22 symmetric
  bridge-domain 30 split-horizon

interface Vlan 30
  xconnect 1.1.1.2 10 encapsulation mpls

SVI-based EoMPLS can be considered like a VPLS, where there is only one VC pointing to one neighbor.

Note : Have a look at SVI-based EoMPLS for additional information.

For L3 termination you have the usual two options : use subinterfaces or use bridge-domains (just like switchports) and SVIs. ES/ES+ and SIP-400 cards support termination of double-tagged traffic too.

Keep in mind the following :

a) you must remove all tags before terminating L3 traffic
b) you must use matching rules based on unique single or double tags (no vlan ranges are supported, although they might be accepted)

This is an example using a bridge-domain and the equivalent SVI:

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  rewrite ingress tag pop 1 symmetric
  bridge-domain 40

interface Gi1/2
 service instance 10 ethernet
  encapsulation dot1q 20 second-dot1q 30
  rewrite ingress tag pop 2 symmetric
  bridge-domain 40

interface Vlan 40
  ip address 1.1.1.1 255.255.255.0

This is an example using subinterfaces:

interface Gi1/1.10
 encapsulation dot1q 10
 ip address 1.1.1.1 255.255.255.0

interface Gi1/1.20
 encapsulation dot1q 20 second-dot1q 30
 ip address 1.1.1.1 255.255.255.0

Note : ES cards have a major limitation : single-tagged vlans configured under a subinterface are global significant. On the other hand, double-tagged vlans are local significant. On the ES+ and SIP-400 cards, both single-tagged and double-tagged vlans are local significant.

EVC : Flexible VLAN Tag Rewrite

Following the previous post about Flexible Frame Matching, this new post describes the second major step in configuring service instances using the EVC framework : Flexible VLAN Tag Rewrite.

Each service instance can change the existing VLAN tag to be a new VLAN tag by adding, removing, or translating one or two VLAN tags. Flexible VLAN tag rewrite includes 3 main operations :

1) pop (remove an existing tag)
2) push (add a new tag)
3) translate (change one or two tags to another one or two tags) - this can be seen as a combination of pop and push operations

Theoretically, any existing combination of one or two VLAN tags can be changed to any new combination of one or two VLAN tags by just using a simple (as soon as you get the idea) line of configuration. Practically, there are some limitations what you'll see below.

These are the relevant CLI options under the service instance (you need first to have configured flexible frame matching for these to appear) :

7600(config-if-srv)#rewrite ingress tag ?
  pop        Pop the tag
  push       Rewrite Operation of push
  translate  Translate Tag

Pop operation

7600(config-if-srv)#rewrite ingress tag pop ?
  1  Pop the outermost tag
  2  Pop two outermost tags

! remove one tag
7600(config-if-srv)#rewrite ingress tag pop 1 ?
  symmetric  Tag egress packets as specified in encapsulation
  <cr>

! remove two tags
7600(config-if-srv)#rewrite ingress tag pop 2 ?
  symmetric  Tag egress packets as specified in encapsulation
  <cr>

Push operation

7600(config-if-srv)#rewrite ingress tag push ?
  dot1q  Push dot1q tag

! add one tag
7600(config-if-srv)#rewrite ingress tag push dot1q ?
  <1-4094>  VLAN id

7600(config-if-srv)#rewrite ingress tag push dot1q 20 ?
  second-dot1q  Push second dot1q tag
  symmetric     Tag egress packets as specified in encapsulation
  <cr>

! add two tags
7600(config-if-srv)#rewrite ingress tag push dot1q 20 second-dot1q ?
  <1-4094>  VLAN id

7600(config-if-srv)#rewrite ingress tag push dot1q 20 second-dot1q 30 ?
  symmetric  Tag egress packets as specified in encapsulation
  <cr>

Translate operation

7600(config-if-srv)#rewrite ingress tag translate ?
  1-to-1  Translate 1-to-1
  1-to-2  Translate 1-to-2
  2-to-1  Translate 2-to-1
  2-to-2  Translate 2-to-2

! remove one tag and add one new tag
7600(config-if-srv)#rewrite ingress tag translate 1-to-1 dot1q 20 ?
  symmetric  Tag egress packets as specified in encapsulation
  <cr>

! remove one tag and add two new tags
7600(config-if-srv)#rewrite ingress tag translate 1-to-2 dot1q 20 second-dot1q 30 ?
  symmetric  Tag egress packets as specified in encapsulation
  <cr>

! remove two tags and add one new tag
7600(config-if-srv)#rewrite ingress tag translate 2-to-1 dot1q 20 ?
  symmetric  Tag egress packets as specified in encapsulation
  <cr>

! remove two tags and add two new tags
7600(config-if-srv)#rewrite ingress tag translate 2-to-2 dot1q 20 second-dot1q 30 ?
  symmetric  Tag egress packets as specified in encapsulation
  <cr>

Examples

interface GigabitEthernet1/2
!
 service instance 10 ethernet
  encapsulation dot1q 10
  ! remove one tag (10) on ingress
  ! add one tag (10) on egress
  rewrite ingress tag pop 1 symmetric
 !
 service instance 20 ethernet
  encapsulation dot1q 10 second-dot1q 20
  ! remove two tags (10/20) on ingress
  ! add two tags (10/20) on egress
  rewrite ingress tag pop 2 symmetric
 !
 service instance 30 ethernet
  encapsulation dot1q 30
  ! add one tag (300) on ingress
  ! remove one tag (300) on egress (if the resulting frame doesn't match tag 30, it's dropped)
  rewrite ingress tag push dot1q 300 symmetric
 !
 service instance 40 ethernet
  encapsulation dot1q 40
  ! add two tags (400/410) on ingress
  ! remove two tags (400/410) on egress (if the resulting frame doesn't match tag 40, it's dropped)
  rewrite ingress tag push dot1q 400 second-dot1q 410 symmetric
 !
 service instance 50 ethernet
  encapsulation dot1q 50 second-dot1q 1-4094
  ! remove one tag (50) and add one new tag (500) on ingress
  ! remove one tag (500) and add one new tag (50) on egress
  ! the inner tags (1-4094) remain unchanged
  rewrite ingress tag translate 1-to-1 dot1q 500 symmetric
 !
 service instance 60 ethernet
  encapsulation dot1q 60
  ! remove one tag (60) and add two new tags (600/610) on ingress
  ! remove two tags (600/610) and add one new tag (60) on egress
  rewrite ingress tag translate 1-to-2 dot1q 600 second-dot1q 610 symmetric
 !
 service instance 70 ethernet
  encapsulation dot1q 70 second-dot1q 100
  ! remove two tags (70/100) and add one new tag (700) on ingress
  ! remove one tag (700) and add two new tags (70/100) on egress
  rewrite ingress tag translate 2-to-1 dot1q 700 symmetric
 !
 service instance 80 ethernet
  encapsulation dot1q 80 second-dot1q 200
  ! remove two tags (80/200) and add two new tags (800/810) on ingress
  ! remove two tags (800/810) and add two new tags (80/200) on egress
  rewrite ingress tag translate 2-to-2 dot1q 800 second-dot1q 810 symmetric

There are some important things to keep in mind when configuring Flexible VLAN Tag Rewrite.

1) You have to use the "symmetric" keyword, although the CLI might not give you this impression:

7600(config-if-srv)#rewrite ingress tag pop 1 ?
  symmetric  Tag egress packets as specified in encapsulation
  <cr>

7600(config-if-srv)#rewrite ingress tag pop 1
Configuration not accepted by the platform
7600(config-if-srv)#rewrite ingress tag pop 1 symmetric
7600(config-if-srv)#

Generally rewrite configurations should always be symmetric. Whatever rewrites are on the ingress direction, you should have the reverse rewrites on the egress direction for the same service instance configuration. So, if you pop the outer VLAN tag on ingress direction, then you need to push the original outer VLAN tag back on the egress direction for that same service instance. All this is done automatically by the system when using the "symmetric" keyword. Have a look at the examples included above and check the comments to see what operations are happening on ingress and egress.

2) Due to the mandatory symmetry, some operations can only be applied to a unique tag matching service instance (so they are not supported for VLAN range configurations) or cannot be applied at all.

i.e.
You cannot translate a range of vlans

7600(config-if-srv)#encapsulation dot1q 10 - 20
7600(config-if-srv)#rewrite ingress tag translate 1-to-1 dot1q 30 symmetric
 Encapsulation change is not logically valid.

You cannot pop a range of vlans

7600(config-if-srv)#encapsulation dot1q 10 second-dot1q 20,30
7600(config-if-srv)#rewrite ingress tag pop 2 symmetric
 Encapsulation change is not logically valid.

If supposedly you could do the above, how could the opposite be done? i.e. if the system removed the tags from frames matching inner vlans 20,30 on the ingress, how would the system know on which frames to add 20 and on which to add 30 on the egress?

Of course you can push a new vlan over a range of vlans.

7600(config-if-srv)#encapsulation dot1q 10-20
7600(config-if-srv)#rewrite ingress tag push dot1q 30 symmetric

You can only push one or two tags for "encapsulation untagged" and "encapsulation default". No pop or translate operations are supported.

As a rule you can think of "you cannot pop or translate something that is not specifically defined as a single unit". Just imagine what would happen in the opposite direction and everything should become clear.

Keep in mind that some configurations might be accepted, but they won't work.

3) You cannot have more than one VLAN tag rewrite configuration under a single service instance. That means you can have either none or one. If there is no VLAN tag rewrite configuration, the existing VLAN tag(s) will be kept unchanged. If you need more than one, you might want to try to create more service instances using more specific frame matching criteria on each one. The translate operation might also seem useful in such conditions.

4) You need to be extra careful when using Flexible VLAN Tag Rewrite and Bridge Domains. Flooded (broadcast/multicast/unknown unicast) packets will get dropped by the service instances that do not agree on the egress tag. Although all service instances under a common bridge domain will get the flooded frame, there is an internal validation mechanism that checks whether the result of egress rewrite (based on the opposite of ingress rewrite) will allow the flooded frame to pass. The push operations under the examples show this behavior.

5) To have an EVC based port act like a L2 802.1q trunk port, you need to remove the outer tag manually and then put it under a bridge domain. On normal L2 switchports this is done automatically by the system.

So this

interface Gi1/1
 switchport
 switchport mode trunk
 switchport trunk allowed vlan 10

is equivalent to this

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  rewrite ingress tag pop 1 symmetric
  bridge-domain 10

EVC : Flexible Frame Matching

EVC stands for Ethernet Virtual Connection and in Cisco's platforms it's used to represent Cisco's software architecture to address Carrier Ethernet Services. In MEF (Metro Ethernet Forum) terminology EVC means "Ethernet Virtual Connection/Circuit", but here EVC represents also the whole Carrier Ethernet software infrastructure developed by Cisco.

EVC has many advantages (which i will try to describe in future posts), one of them being the Flexible Frame Matching. Flexible Frame Matching is a functionality that allows each service instance to match frames with either a unique single vlan, or a list/range of vlans. It can also match single/double tagged frames, untagged frames, or everything else that belongs to the default category.

Flexible Frame Matching is the first major step after configuring a service instance. This is the complete idea:

1) Service Instance definition (create the service instance)
2) Flexible frame matching (configure what frames need to be matched based on vlan match criteria)
3) Flexible VLAN tag rewrite (configure the action to do on the matched frames' vlan tags)
4) Flexible Service Mapping (map the service instance to a service)
5) Extra service features (apply some extra features on the service instance, i.e. QoS)

The middle 3 most important steps can also be described as:

a) Frame matching
b) Frame rewrite
c) Frame forwarding

Example

interface Gi1/1
 ! Service Instance definition
 ! ID is local port significant
 service instance 10 ethernet
  ! Flexible frame matching
  encapsulation dot1q 10 second-dot1q 20
  ! Flexible VLAN tag rewrite
  rewrite ingress tag pop 1 symmetric 
  ! Service Mapping
  xconnect 10.10.10.10 100 encapsulation mpls 
  ! Extra service features
  service-policy input TEST-INPUT-POLICY

The current EVC implementation supports matching only on vlan tags, but in future we may see matching on other L2 fields too, since the hardware is quite capable.

These are the current supported vlan matching configurations:

• Single tagged frames, where match criteria can be a single vlan, a list/range of vlans, or any vlan (1-4094)

encapsulation dot1q <vlan-id>
encapsulation dot1q <vlan-id>, <vlan-id>
encapsulation dot1q <vlan-id> - <vlan-id>
encapsulation dot1q any

• Double tagged frames, where first VLAN tag can be only single (software limitation), while second VLAN tag can be single, list/range, or any

encapsulation dot1q <vlan-id> second-dot1q <vlan-id>
encapsulation dot1q <vlan-id> second-dot1q <vlan-id>, <vlan-id>
encapsulation dot1q <vlan-id> second-dot1q <vlan-id> - <vlan-id>
encapsulation dot1q <vlan-id> second-dot1q any

• Untagged frames, where all untagged frames are matched

encapsulation untagged

• Default tag frames, where all tagged/untagged frames that are not matched by other more specific service instances are matched

encapsulation default

Examples

interface Gi1/1
!
 service instance 10
  ! single tagged frames with a specific tag
  encapsulation dot1q 10
!
 service instance 20
  ! single tagged frames with multiple tags
  encapsulation dot1q 20,22,24,26-28
!
 service instance 30
  ! single tagged frames with any tag
  encapsulation dot1q any
!
 service instance 40
  ! frames with a specific single outer tag and specific single inner tag
  encapsulation dot1q 10 second-dot1q 20
!
 service instance 50
  ! frames with a specific single outer tag and multiple inner tags
  encapsulation dot1q 10 second-dot1q 20,22,24,26-28
!
 service instance 60
  ! frames with a specific single outer tag and any inner tag
  encapsulation dot1q 10 second-dot1q any
!
 service instance 70
  ! frames without a tag
  encapsulation untagged
!
 service instance 80
  ! frames that do not match under any other service instance
  encapsulation default

There are some important things to keep in mind when configuring Flexible Frame Matching.

1) When you have multiple vlan match criteria configured under different service instances of a single physical interface, the most specific is the one that wins (it's like the longest match rule used in the routing table). So the order of service instances under an interface doesn't have the same effect like the classes in MQC. This is because frame matching is done by hardware using the linecard's TCAM table, where each frame matching configuration gets converted to 1 or more TCAM entries (vlan lists/ranges in matching criteria are the most TCAM consuming configurations). The number of 16000 service instances per ES20 module is based on the assumption that each service instance uses a single TCAM entry.

2) When you don't get any match according to the above longest match rule, matching is done according to a looser match algorithm, where a single tag configuration matches all frames that have a common outer tag (regardless of the number of inner tags) and a double tag configuration matches all frames that have common the first 2 tags (regardless of the number of 2+ inner tags; btw, i'm planning of doing a triple-tag test soon).

Example

interface G1/1
 service instance 10 ethernet
  encapsulation dot1q 10
 service instance 20 ethernet
  encapsulation dot1q 10 second-dot1q 20
 service instance 30 ethernet
  encapsulation default

On the above configuration:

10/20 will be matched by service instance 20 (both tags matched)
10/30 will be matched by service instance 10 (outer tag matched)
20/30 will be matched by service instance 30 (no tag matched)

"encapsulation dot1q 10" matches "10", "10/20", "10/30" and so on.
"encapsulation dot1q 10 second-dot1q 20" matches "10/20", "10/20/30", "10/20/40" and so on.

Debugging SUP720 booting process

On Tuesday i had an rommon issue with a RSP720 in a 7600. One of the things i tried on a spare SUP720 (i didn't have any spare RSP720) in order to check for possible solutions, was to remove the NVRAM battery for a while and then reinsert it. As it proved out, i found a nice way to "debug" the booting process. Probably config-register changed to a factory default value (different than the usual 0x2102), causing all these messages to be displayed on console.

System Bootstrap, Version 8.4(2) Release
Copyright (c) 1994-2005 by cisco Systems, Inc.

Testing lower main memory - data equals address
Testing lower main memory - checkerboard
Testing lower main memory - inverse checkerboard
Clearing lower memory for cache initialization
Clearing bss
Clearing autoboot state machine
melody_present_reg: 1st read w/ 0xffff
melody_present_reg: 2nd read w/ 0xffff, reversed: 0x0
melody_present_reg: 1st read w/ 0xffff
melody_present_reg: 2nd read w/ 0xffff, reversed: 0x0
Bootdisk adapter not detected, use bootflash instead.

Reading monitor variables from NVRAM
Reset reason for CPU board 0xffff , BaseBoard 0x280ffff, display 0x20000System Reset by Software.

Enabling interrupts
Initializing TLB
Initializing cache
Initializing required TLB entries
Initializing main memory
Sizing NVRAM
Initializing PCMCIA controller
Exiting init
Cat6k-Sup720/SP processor with 1048576 Kbytes of main memory



rommon 1 > boot disk0:c7600s72033-advipservicesk9-mz.122-33.SRD2.bin
Loading image, please wait ...

Stack pointer       : 0x8FFFFF80
monstack            : 0x800FFFC0
monra               : 0xBFC26794
edata : 0x801097A0
magic : 0xFEEDFACE
memsize             : 0x10000000
uncomp_size         : 0x07EC9400
comp_size           : 0x07EC9400
comp_checksum       : 0xEC6D779E
uncomp_checksum     : 0xEC6D779E
CZIP_MEM_BASE       : 0x80000000
_end       : 0x8010CC40

Self extracting the image...
IOS compressed src copy is     : 0x801097B4

czip + IOS tar size is :0x00B2BB2C

czip + IOS Tar image is now :0x801099B4

cptr is now :0x8010CD40
IOS compressed dest copy is     : 0x8010CD40
 [OK]
image_entry :0x80100000
image_entry :0x80100000
__start : 0x80100000
tar_avail_size is now :0x0739D600
Tar image address is             : 0x80C38940
tar_size is           : 0x0739D200
cpu type                   : 0x00000019
uncomp_size                : 0x07EC9400
monstack                   : 0x800FFFC0

image_info.entry_point   = 0x80100000
image_info.section_count = 0x00000005
image_info.monstack      = 0x800FFFC0
image_info.monra         = 0xBFC26794
image_info.param0        = 0x00000002
image_info.param1        = 0x00000000
image_info.param2        = 0x800068D8
image_info.param3        = 0x80100000
image_info.reg_k0        = 0x80C38940
image_info.reg_k1        = 0x0739D200
Section Index = 0x00000000
    source    = 0x8010CE5C
    dest      = 0x80100000
    bytes     = 0x00010000
Section Index = 0x00000001
    source    = 0x8011CE5C
    dest      = 0x80110000
    bytes     = 0x00001940
Section Index = 0x00000002
    source    = 0x8011E79C
    dest      = 0x80111940
    bytes     = 0x00000020
Section Index = 0x00000003
    source    = 0x8011E7BC
    dest      = 0x80111960
    bytes     = 0x00B1A094
Section Index = 0x00000004
    source    = 0x80C38850
    dest      = 0x80C2B9F4
    bytes     = 0x00000000
reg_v0: 0x00000000
reg_k0: 0x80C38940
reg_k1: 0x0739D200
tar_start: 0x00000000
tar_size: 0x00000000
 Tar image address is             : 0x80C38940
tar size is :0x009CD42A
 Tar magic : ustar Tar filename : C2LC memsize             : 0x10000000
Tar gid         : 035231Tar uncomp_size         : 0x009CD42A
Tar mtime         : 11205304144 Tar username          : ciiTar comp_checksum       : 0x00001200
Tar group name    : buildTar prefix    : tar_size  in czip         : 0x0739D200
Stack pointer       : 0x8FFFFF80
monstack            : 0x800FFFC0
monra               : 0xBFC26794
edata : 0x80111960
magic : 0xFEEDFACE
memsize             : 0x10000000
uncomp_size         : 0x0209842C
comp_size           : 0x00B1A07F
comp_checksum       : 0x8FE686D4
uncomp_checksum     : 0xB44EFA0C
Compressed IOS src copy is     : 0x80111974
tar_dest is :0x88C5A600
tar_size is :0x0739D200
Compressed IOS dest copy is     : 0x88140580
Tar src before IOS decompression is     : 0x80C38940
Tar dest before IOS decompression is     : 0x88C5A600
compressed IOS  src is     : 0x88140580
IOS uncompressed dest copy is     : 0x8013D3E0
Self decompressing the image : ####################################################################################
####################################################################################
# [OK]
e_shoff :
0x0209829C
e_flags : 0x10001001
e_phnum :
0x00000001
Source elf_hdr->e_shnum = 0x0000000A
Setting up to copy ELF section 0x00000001
 to image_info section 0x00000000
 sh_name = 0x0000000B
 sh_type = 0x00000001
 sh_flags = 0x00000007
 sh_addr = 0x80100000
 sh_offset = 0x00000060
 sh_size = 0x01CA8000
 sh_link = 0x00000000
 sh_info = 0x00000000
 sh_addralign = 0x00000008
 sh_entsize = 0x00000000
Setting up to copy ELF section 0x00000002
 to image_info section 0x00000001
 sh_name = 0x00000011
 sh_type = 0x00000001
 sh_flags = 0x00000003
 sh_addr = 0x81DA8000
 sh_offset = 0x01CA8060
 sh_size = 0x002A46E0
 sh_link = 0x00000000
 sh_info = 0x00000000
 sh_addralign = 0x00000008
 sh_entsize = 0x00000000
Setting up to copy ELF section 0x00000003
 to image_info section 0x00000002
 sh_name = 0x00000017
 sh_type = 0x00000001
 sh_flags = 0x00000003
 sh_addr = 0x8204C6E0
 sh_offset = 0x01F4C740
 sh_size = 0x00040ECC
 sh_link = 0x00000000
 sh_info = 0x00000000
 sh_addralign = 0x00000004
 sh_entsize = 0x00000000
Setting up to copy ELF section 0x00000004
 to image_info section 0x00000003
 sh_name = 0x00000024
 sh_type = 0x00000001
 sh_flags = 0x10000003
 sh_addr = 0x8208D5AC
 sh_offset = 0x01F8D60C
 sh_size = 0x00004034
 sh_link = 0x00000000
 sh_info = 0x00000000
 sh_addralign = 0x00000010
 sh_entsize = 0x00000000
 sh_type = 0x00000008
 sh_flags = 0x10000003
 sh_addr = 0x820915E0
 sh_offset = 0x01F91640
 sh_size = 0x000009E0
 sh_type = 0x00000008
 sh_flags = 0x00000003
 sh_addr = 0x82091FC0
 sh_offset = 0x01F91640
 sh_size = 0x021EB140
tar file start = 0x8428A070
cpu type                   : 0x00000019
uncomp_size                : 0x0209842C
monstack                   : 0x800FFFC0
image_info.entry_point   = 0x80100000
image_info.section_count = 0x00000005
image_info.monstack      = 0x800FFFC0
image_info.monra         = 0xBFC26794
image_info.param0        = 0x00000002
image_info.param1        = 0x00000000
image_info.param2        = 0x800068D8
image_info.param3        = 0x80100000
image_info.reg_k0        = 0x8428A070
image_info.reg_k1        = 0x0739D200
Section Index = 0x00000000
    source    = 0x8013D440
    dest      = 0x80100000
    bytes     = 0x01CA8000
Section Index = 0x00000001
    source    = 0x81DE5440
    dest      = 0x81DACF70
    bytes     = 0x002A46E0
Section Index = 0x00000002
    source    = 0x82089B20
    dest      = 0x82051650
    bytes     = 0x00040ECC
Section Index = 0x00000003
    source    = 0x820CA9EC
    dest      = 0x8209251C
    bytes     = 0x00004034
Section Index = 0x00000004
    source    = 0x88C5A600
    dest      = 0x8428A070
    bytes     = 0x0739D200

data_size  in czip         : 0x00008000

bss end of IOS is         : 0x84282070

              Restricted Rights Legend

Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software - Restricted
Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.

           cisco Systems, Inc.
           170 West Tasman Drive
           San Jose, California 95134-1706



Cisco IOS Software, c7600s72033_sp Software (c7600s72033_sp-ADVIPSERVICESK9-M), Version 12.2(33)SRD2, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Thu 21-May-09 09:55 by prod_rel_team
Image text-base: 0x401012B8, data-base: 0x41DACF70


*Jan  1 00:00:11.983: %SYS-SP-3-LOGGER_FLUSHING: System pausing to ensure console debugging output.

*Jan  1 00:00:09.523: %PFREDUN-6-ACTIVE: Initializing as ACTIVE processor

*Jan  1 00:00:11.983: %OIR-SP-6-CONSOLE: Changing console ownership to route processor



System Bootstrap, Version 12.2(17r)SX5, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 2006 by cisco Systems, Inc.
Cat6k-Sup720/RP platform with 1048576 Kbytes of main memory

Download Start
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Download Completed! Booting the image.
Self decompressing the image : ####################################################################################
####################################################################################
####################################################################################
####################################################################################
######## [OK]

              Restricted Rights Legend

Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software - Restricted
Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.

           cisco Systems, Inc.
           170 West Tasman Drive
           San Jose, California 95134-1706



Cisco IOS Software, c7600s72033_rp Software (c7600s72033_rp-ADVIPSERVICESK9-M), Version 12.2(33)SRD2, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Thu 21-May-09 09:42 by prod_rel_team
Image text-base: 0x401012B8, data-base: 0x4412DDF0


This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

cisco CISCO7609 (R7000) processor (revision 1.2) with 983008K/65536K bytes of memory.
Processor board ID XXX
SR71000 CPU at 600Mhz, Implementation 0x504, Rev 1.2, 512KB L2 Cache
Last reset from s/w reset
1 Virtual Ethernet interface
76 Gigabit Ethernet interfaces
4 Ten Gigabit Ethernet interfaces
1917K bytes of non-volatile configuration memory.
8192K bytes of packet buffer memory.



Press RETURN to get started!

Setting the config-register back to 0x2102 stopped the above messages from being displayed while booting. You have to re-upgrade (or re-enable) the rommon too.

VLAN resource vs VLAN significance

These are two terms that get used quite often when talking about hardware switching platforms (i.e. 6500/7600).

As you all know, VLAN is a virtual LAN defined initially for L2 bridging. One VLAN represents a broadcast domain and packet forwarding within the same VLAN is based on mac-address learning. Another name for this is multipoint bridging (you'll meet that term quite frequently in ES/ES+ setups).

VLANs are also used in the 802.1q ethernet encapsulation method. Services like L2 point-to-point are usually using this functionality. Such services, as EoMPLS xconnect or local-connect (more on that on another post about ES/ES+), do not require a VLAN for bridging, but they might require a vlan as a packet encapsulation method.

Actually you might differentiate the above 2 VLAN types like below:

system VLAN or global VLAN : used for L2 bridging
port VLAN or access VLAN : used for L2 point-to-point services (do not confuse it with the vlan-id used under switchports in access mode)

Global VLAN resource is per system and is limited to 4094 (0 & 4095 are reserved) on 6500s/7600s (you can use "sh platform hardware capacity vlan" to check this).
Access VLAN resource is per linecard and is limited to 16000 on the ES/ES+ cards (probably lower on some SIPs), which equals the number of service instances supported.

L3 services are a different story. Each physical/logical L3 interface requires a global VLAN resource (use "sh vlan internal usage" to find these). An exception on this are the PPP and ISG sessions (supported on SIP-400 cards).

Bridge-domains require also a global VLAN resource each. A bridge-domain, which is used in the ES/ES+ cards, is like a traditional L2 bridging instance, where many physical or logical ports connect to. What is interesting about this, is the ability to have L2 interworking between normal switchports, EVC service instances, ATM/FR PVCs/DLCIs, EoMPLS/VPLS VCs, etc.

Regarding the VLAN significance, there are also 2 VLAN types here:

per system or global significant : when a vlan-id must be unique across the whole system
per port or local significant : when a vlan-id can be the same across different ports

Although it might seem a little bit confusing, VLAN resource is somewhat independent of VLAN significance. i.e. in a case of a L3 subinterface, you always require a global VLAN resource, regardless of the linecard used. But whether you'll have local VLAN significance or not depends on the linecard itself.

SIP-400 and ES/ES+ cards support local VLAN significance, but keep in mind that the "older" ES cards do not support it when using single-tagged subinterfaces.