Sunday, June 28, 2009

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

Note: The above examples were done on a 7600 with ES+ cards running 12.2(33)SRB IOS.

Sunday, June 21, 2009

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.

Note: The above examples were done on a 7600 with ES+ cards running 12.2(33)SRB IOS.

Thursday, June 4, 2009

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.

Wednesday, June 3, 2009

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.

Tuesday, June 2, 2009

EoMPLS on 7600 : PFC-based, SVI-based, Scalable

With the "recent" addition of the ES/ES+ cards (although some SIP cards might belong in the same category), 7600 can now support 3 types of EoMPLS configurations . Depending on your needs and the available hardware, you will find at least one between them that can help you implement your network design.

PFC-based EoMPLS
This is the most well-known EoMPLS that is configured under a physical interface or subinterface using the xconnect command. Label imposition/disposition is being done by either the SUP's PFC or the ingress module's DFC, so it's supported on all the usual LAN (i.e. 67xx) cards.

You can use it for point-to-point L2 services between single attachment circuits, where you do not require any local switching or mac-address learning. Each local attachment circuit uses a single EoMPLS pseudowire to connect to a single remote attachment circuit.

Local Router


int Gi1/1
xconnect 1.1.1.2 10 encapsulation mpls

int Gi1/2.20
encapsulation dot1q 20
xconnect 2.2.2.2 20 encapsulation mpls


Remote Router

int Gi1/1
xconnect 1.1.1.1 10 encapsulation mpls

int Gi1/2.20
encapsulation dot1q 20
xconnect 2.2.2.1 20 encapsulation mpls


SVI-based EoMPLS
This EoMPLS is configured under a vlan (SVI) interface using also the xconnect command. Label imposition/disposition is being done by the egress module (where the EoMPLS VC points to), so it must be either a SIP or an ES/ES+ based one. Also there is a limitation that you must have a L3 (sub)interface as the egress interface where the EoMPLS VC will pass through.

You can use it for point-to-point L2 services between multiple attachment circuits, where you also require local switching and mac-address learning. It's like a mini VPLS implementation, where multiple local attachment circuits use a single EoMPLS pseudowire to connect to multiple remote attachment circuits.

Local Router

int Gi1/1
switchport
switchport mode access
switchport access vlan 10

int Gi1/2
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allow vlan 10

int Vlan 10
xconnect 1.1.1.2 10 encapsulation mpls


Remote Router

int Gi1/1
switchport
switchport mode access
switchport access vlan 10

int Gi1/2
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allow vlan 10

int Vlan 10
xconnect 1.1.1.1 10 encapsulation mpls


Scalable EoMPLS
This new EoMPLS is configured under an EVC service instance using again the xconnect command. Label imposition/disposition is being done by the ingress module where the service instance is configured, so a module with EVC support (i.e. ES/ES+) is required.

You can use it for point-to-point L2 services between single attachment circuits, just like the PFC-based EoMPLS.

Besides that, when dealing with EVCs you can also configure the xconnect under a vlan (SVI) interface (when the service instance is mapped to a bridge-domain) for point-to-point L2 services between multiple attachment circuits, where you can also enable or disable local L2 connectivity using split-horizon.

Both EoMPLS configurations can be used concurrently on the same physical port, with less global resources (i.e. vlans) used in comparison to the first two EoMPLS types. Keep in mind that you still need a SIP or an ES/ES+ egress module for the SVI-based EoMPLS.

Local Router

int Gi1/1
service instance 10 ethernet
encapsulation dot1q 10
xconnect 1.1.1.2 10 encapsulation mpls
service instance 20 ethernet
encapsulation dot1q 20
rewrite ingress tag pop 1 symmetric
bridge-domain 20

int Vlan 20
xconnect 2.2.2.2 20 encapsulation mpls


Remote Router

int Gi1/1
service instance 10 ethernet
encapsulation dot1q 10
xconnect 1.1.1.1 10 encapsulation mpls
service instance 20 ethernet
encapsulation dot1q 20
rewrite ingress tag pop 1 symmetric
bridge-domain 20

int Vlan 20
xconnect 2.2.2.1 20 encapsulation mpls


Notes:
1) The vlan configured in "encapsulation vlan-id" under the service instance is local significant. The vlan configured in bridge-domain is a global vlan-id and can be different from the first one.

2) Scalable EoMPLS doesn't require global VLAN resources for the EoMPLS xconnect. In PFC-based EoMPLS each (sub)interface requires one global VLAN resource.

3) An attachment circuit (AC) is usually the customer connection to a service provider network (CE-PE). An AC may be a physical or virtual port/circuit and may be any transport technology, i.e. Frame Relay DLCI, ATM PVC, Ethernet VLAN.

 
Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.
Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Greece License.