Monday, December 28, 2009

Frame Relay Part 2: encapsulation and inverse arp

Hi all,
here the second part of my frame-relay studies. In the last post we have seen the frame relay switches configuration and some details about lmi.

The topology still the same:




The frame relay switches are already configured, I've just added some DLCIs to introduce some enthropy to enhance our inarp experience ;-)

Let's begin talking about encapsulation. In Frame Relay interfaces the ip, ipv6 and other protocols packets are encapsulated within a L2 frame.
The frame format can vary according to the coosen encapsulation, our Cisco toys support the encapsulation Cisco (enabled by default) or IETF (also referred as RFC1490/RFC2427 ).
Just remember that the frame relay switches doesn't decapsulate the data, they act only as layer 2 switches using DLCI and frame-relay route.

The encapsulation can be specified on the physical interface and per dlci using the frame-relay map command.
eg:

R3(config-if)#do sh run int ser 0/3/0 | beg int
interface Serial0/3/0
ip address 10.0.0.3 255.255.255.0
encapsulation frame-relay IETF
end

Here the encapsulation is specified on the physical interface, so it's valid for each DLCI on that interface. The L2 to L3 mapping is done via inverse-arp, as default.
Another example with the encapsulation specified by dlci

R4#sh run int ser 0/3/0 | beg int
interface Serial0/3/0
ip address 10.0.0.4 255.255.255.0
encapsulation frame-relay
frame-relay map ip 10.0.0.2 402 broadcast
frame-relay map ip 10.0.0.1 401 broadcast IETF
no frame-relay inverse-arp
end

R4#sh frame-relay map
Serial0/3/0 (up): ip 10.0.0.1 dlci 401(0x191,0x6410), static,
broadcast,
IETF, status defined, active
Serial0/3/0 (up): ip 10.0.0.2 dlci 402(0x192,0x6420), static,
broadcast,
CISCO, status defined, active


Here the dlci 402 is using cisco encapsulation, the dlci 401 is using IETF as shown in the sh frame-relay map.

Well, let's talk about inverse-arp, one of the most annoying/exciting features of frame-relay.
The point is: I have a frame-relay interface, eg, R4 with his serial interface configured with an ip address like 10.0.0.4/24. R4 must know how to reach the other routers on his subnet, knowing the ip address, like 10.0.0.2, he must know at which DLCI it belongs.
One method is to map the ip addresses manually, with the frame-relay map ip 10.0.0.2 402 command as in the previous example, the other way is to let R4 "discover" the right dlci through inverse arp.

an example, on R4:
R4# sh run int ser 0/3/0
Building configuration...

Current configuration : 91 bytes
!
interface Serial0/3/0
ip address 10.0.0.4 255.255.255.0
encapsulation frame-relay
end

R4#sh frame-relay pvc | inc DLCI
DLCI = 401, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0
DLCI = 402, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0
DLCI = 403, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0
DLCI = 404, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/3/0
DLCI = 405, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/3/0
DLCI = 406, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/3/0

R4#sh frame-relay map
Serial0/3/0 (up): ip 10.0.0.1 dlci 401(0x191,0x6410), dynamic,
broadcast,, status defined, active
Serial0/3/0 (up): ip 10.0.0.2 dlci 402(0x192,0x6420), dynamic,
broadcast,, status defined, active
Serial0/3/0 (up): ip 10.0.0.3 dlci 403(0x193,0x6430), dynamic,
broadcast,, status defined, active

Here R4 is configured with the ip address and the encapsulation frame relay only, inverse arp is enabled by default, and when the router receives an lmi update message with any dlci in active status, it sends an inverse-arp for that dlci requesting which ip address is reachable through that dlci.
The receiving station maps the requesting router (or ignores it) and then responds with his own ip/ipv6 address.
When receives the response, R4 uses it to form the frame-relay map, as you can see from the command outputs. The inverse-arp learned addresses are "dynamic". (See RFC 2390 - Inverse Address Resolution Protocol )

Sometimes happens that your frame-relay interface learns wrong ip addresses, that doesn't belongs to your frame-relay network, as our R4 has learned R3 ip address... or even that don't have a real ip address, like a 0.0.0.0 entry.
In this case, there are several things to do to correct this kind of mistakes:
(obviously after have removed the cause of that problem, eg a misconfigured interface.
1) shut down the serial interface and perform a "clear frame-relay inarp" and "clear frame-relay counters"
2) in the worst case, save your config and reload the router

To avoid these issues you have to remember that all your DLCIs area assigned by default to the physical interface, so you can use subinterfaces and assign the correct DLCIs according to your topology with the "frame-relay interface-dlci" command, or you can disable manually the inarp for some DLCIs with the "no frame-relay inverse-arp ip" command.

Here the previous example fixed with disabling inverse arp for dlci 403:
R4#sh run int ser 0/3/0 | beg int
interface Serial0/3/0
ip address 10.0.0.4 255.255.255.0
encapsulation frame-relay
no frame-relay inverse-arp IP 403
end

R4#sh frame-relay pvc | inc \ ACT
DLCI = 401, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0
DLCI = 402, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0
DLCI = 403, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0

R4#sh frame-relay map
Serial0/3/0 (up): ip 10.0.0.1 dlci 401(0x191,0x6410), dynamic,
broadcast,
CISCO, status defined, active
Serial0/3/0 (up): ip 10.0.0.2 dlci 402(0x192,0x6420), dynamic,
broadcast,, status defined, active
R4#

This is not a good method, in my opinion, doesn't "protect" against other DLCI eventually configured later.
If you configure a subinterface instead....
R4#sh run int ser0/3/0 | beg int
interface Serial0/3/0
no ip address
encapsulation frame-relay
end

R4#sh run int ser0/3/0.1 | beg int
interface Serial0/3/0.1 multipoint
ip address 10.0.0.4 255.255.255.0
snmp trap link-status
frame-relay interface-dlci 401
frame-relay interface-dlci 402
end

R4#sh frame-relay pvc | inc \ ACT
DLCI = 401, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0.1
DLCI = 402, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0.1
DLCI = 403, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0

R4#sh frame-relay map
Serial0/3/0.1 (up): ip 10.0.0.1 dlci 401(0x191,0x6410), dynamic,
broadcast,, status defined, active
Serial0/3/0.1 (up): ip 10.0.0.2 dlci 402(0x192,0x6420), dynamic,
broadcast,, status defined, active
R4#

you will have inverse-arp enabled only for the assigned dlci.
However, with this configuration, from R4 you can't ping R4 ip address, always due to lack of L3 to L2 mapping.

To avoid any problem like this, you have to disable inverse arp and use static mapping for your DLCIs.
for example:

R4#sh run int ser 0/3/0 | beg int
interface Serial0/3/0
ip address 10.0.0.4 255.255.255.0
encapsulation frame-relay
frame-relay map ip 10.0.0.1 401
frame-relay map ip 10.0.0.2 402
no frame-relay inverse-arp
end

R4#sh frame-relay pvc | inc \ ACT
DLCI = 401, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0
DLCI = 402, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0
DLCI = 403, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0

R4#sh frame-relay map
Serial0/3/0 (up): ip 10.0.0.1 dlci 401(0x191,0x6410), static,
CISCO, status defined, active
Serial0/3/0 (up): ip 10.0.0.2 dlci 402(0x192,0x6420), static,
CISCO, status defined, active

!-- on R2...
R2#sh run int ser 0/2/0:1 | beg int
interface Serial0/2/0:1
ip address 10.0.0.2 255.255.255.0
encapsulation frame-relay
end

R2#sh frame-relay pvc | inc \ ACT
DLCI = 203, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/2/0:1
DLCI = 204, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/2/0:1

R2#sh frame-relay map
Serial0/2/0:1 (up): ip 10.0.0.3 dlci 203(0xCB,0x30B0), dynamic,
broadcast,, status defined, active
Serial0/2/0:1 (up): ip 10.0.0.4 dlci 204(0xCC,0x30C0), dynamic,
broadcast,, status defined, active
R2#

In the example above, inverse arp is disabled on R4, see the "static" entries in the frame-relay map, but note also that R4 still answer to the inverse arp requests made for example by R2, that has inverse arp enabled.

!-- END of Part 2, the next part will be about Frame Relay interface types, pros and cons.

Saturday, December 26, 2009

Frame Relay Part 1: preparing the frame-relay switches

Hi all, I'm starting my CCIE R&S Lab preparation with a "classic" argument and a lot of good proposals for this new year... (first of all: more accuracy on my labs, I'm trying to get my digits!)

So let's take a look to my frame-relay topology and then we can start labbing and understanding how this old-times technology works.



As you can see, it's a 4 routers topology with two frame relay switches, just to refresh how to configure them in nni mode.

Let's begin with some basic configuration tasks and then we can start to explore the various interface modes and some dirty tricks.


1) Frame relay switches configuration
Here we have two switches, so we have to plan how to configure the various DLCIs.
The method I use to configure Frame relay switches is to build by hand a "sh frame-relay route" output on a scratchpaper before to start configuring, so I'll have no pain to forget any dlci when I go to the interfaces. A tip can be to start with the lowest number interfaces and lowest dlci, so you will write in the same order ad they will appear later in your sh frame-relay route
For our topology, the frame-relay route will be:

FR-SW1:
in interface in dlci out interface out dlci
ser 1/0:1 104 ser 2/0:1 111
ser 1/1:1 203 ser 2/0:1 222
ser 1/1:1 204 ser 2/0:1 333
ser 2/0:1 111 ser 1/0:1 104
ser 2/0:1 222 ser 1/1:1 203
ser 2/0:1 333 ser 1/1:1 204

FS-SW2:
in interface in dlci out interface out dlci
ser 1/2 302 ser 4/0:1 222
ser 1/3 401 ser 4/0:1 111
ser 1/3 402 ser 4/0:1 333
ser 4/0:1 111 ser 1/3 401
ser 4/0:1 222 ser 1/2 302
ser 4/0:1 333 ser 1/3 402

As you can see, between the two frame relay switches, you can use different DLCI numbers, just keep in mind the dlci modifications across your network: eg. in 104 -> out 111 -> in 111 -> out 401 .

Ok now let's configure the frame-relay switches:

FR-SW1#conf t

frame-relay switching

interface Serial1/0:1
description to R1
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 104 interface Serial2/0:1 111

interface Serial1/1:1
description to R2
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 203 interface Serial2/0:1 222
frame-relay route 204 interface Serial2/0:1 333

interface Serial2/0:1
description to FR-SW2
no ip address
encapsulation frame-relay
frame-relay intf-type nni
frame-relay route 111 interface Serial1/0:1 104
frame-relay route 222 interface Serial1/1:1 203
frame-relay route 333 interface Serial1/1:1 204
end

FR-SW1#sh frame-relay route
Input Intf Input Dlci Output Intf Output Dlci Status
Serial1/0:1 104 Serial2/0:1 111 inactive
Serial1/1:1 203 Serial2/0:1 222 inactive
Serial1/1:1 204 Serial2/0:1 333 inactive
Serial2/0:1 111 Serial1/0:1 104 inactive
Serial2/0:1 222 Serial1/1:1 203 inactive
Serial2/0:1 333 Serial1/1:1 204 inactive


note the different interface types, configured with the "frame-relay intf-type" command... you have 3 options: dce, dte and nni.
DTE is the default when encapsulation frame-relay is enabled
DCE is used (usually) on frame relay switch on interfaces connecting to the customers (our R1-4 here)
NNI is used (usually) to connect interfaces in network-to-network mode between frame-relay switches
Here I've assumed that the serial cables have DCE connector on frame-relay switch side (always verify with "sh controller | inc (DCE|DTE) " command).
Anyway, the DCE/DTE status configured under the frame-relay circuit has nothing to do with cabling, later we will try to do some dirty tricks just in case the proctors decide to do the virtual circuit assignment with dce interfaces on routers side.

The second Fr-Switch will have:

FR-SW2#conf t

frame-relay switching

interface Serial1/2
description to R3
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 302 interface Serial4/0:1 222

interface Serial1/3
description to R4
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 401 interface Serial4/0:1 111
frame-relay route 402 interface Serial4/0:1 333

interface Serial4/0:1
description to FR-SW1
no ip address
encapsulation frame-relay
frame-relay intf-type nni
frame-relay route 111 interface Serial1/3 401
frame-relay route 222 interface Serial1/2 302
frame-relay route 333 interface Serial1/3 402
end

FW-SW2#sh frame-relay route
Input Intf Input Dlci Output Intf Output Dlci Status
Serial1/2 302 Serial4/0:1 222 inactive
Serial1/3 401 Serial4/0:1 111 inactive
Serial1/3 402 Serial4/0:1 333 inactive
Serial4/0:1 111 Serial1/3 401 inactive
Serial4/0:1 222 Serial1/2 302 inactive
Serial4/0:1 333 Serial1/3 402 inactive


well, our frame-relay route looks exactly as planned.

In our example here, we have left all the default behaviors of our frame-relay interfaces, but when configuring a frame-relay switch we can play with lmi (not with encapsulation, since the frame-relay switch doesn't decapsulate the frame.... , it's a switch ;-) )

FR-SW1#sh frame-relay lmi int ser 1/0:1

LMI Statistics for interface Serial1/0:1 (Frame Relay DCE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Rcvd 281 Num Status msgs Sent 281
Num Update Status Sent 0 Num St Enq. Timeouts 23


Here we have left the Lmi type Cisco, that is the default on DCE intf-type, but we can change it, choosing between cisco | ansi | q933a as required.


FR-SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
FR-SW1(config)#int ser 1/0:1
FR-SW1(config-if)#frame-relay lmi-type ?
cisco
ansi
q933a

FR-SW1(config-if)#frame-relay lmi-type ansi
FR-SW1(config-if)#do sh frame-relay lmi int ser 1/0:1

LMI Statistics for interface Serial1/0:1 (Frame Relay DCE) LMI TYPE = ANSI
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Rcvd 386 Num Status msgs Sent 386
Num Update Status Sent 0 Num St Enq. Timeouts 23
FR-SW1(config-if)#


note: if you have already configured the router attacched to this interface, it's a good idea to shut the serial interface, that's because by default your router (dte) will perform lmi autosense, so if you change the lmi type with the interface up, he will bring it in protocol down shortly due to lmi mismatch (switch has ansi, router thinks to use cisco type)

Another important thing to remember is that LMI is significant only on your local link, so R1 and FR-SW1 can use lmi type ansi and FR-SW2 and R4 can use lmi type cisco, this doesn't affect the virtual circuit status in any way.

About LMI, just remember that you enable LMI as "keepalive" on Serial interfaces, so look at show interface output:

FW-SW2#sh int ser 1/2
Serial1/2 is up, line protocol is down
Hardware is M4T
Description: to R3
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY, crc 16, loopback not set
Keepalive set (10 sec)
LMI enq sent 0, LMI stat recvd 0, LMI upd recvd 0
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0, DCE LMI down
LMI DLCI 1023 LMI type is CISCO frame relay DCE
FR SVC disabled, LAPF state down
[...]


This "keepalive set" is the keepalive time interval, that is the Lmi time interval too. Your router exchanges lmi keepalives with the fr-switch every 10 seconds by default, and requests for a full lmi update every 6x keepalive interval, so 60 secs by default.

To change this default behavior and change the lmi full updates requests, you can:
-change the keepalive interval on both sides (router and Fr-switch)
-change the number of keepalives on router side to request lmi full status updates

frame-relay lmi-n391dte 3 !-- set full status polling counter <1-255>


Also note from the previous output that there is a reserved DLCI number for LMI, Cisco lmi uses DLCI 1023, ansi lmi and q933a uses DLCI 0.

!-- END OF PART 1 : next part will be about Frame-Relay encapsulation and inverse arp

Sunday, December 20, 2009

Happy Holydays

Happy Studying Holydays to all networkers!



I'll pass studing too! ;-)


Marco

Wednesday, December 16, 2009

Back to office: New Fw ... new platform to learn!

Hi all, after an intense study-week today I'm back to office with a "preliminary score report" in my hand (... and can't say nothing about it until confirmed ;-) ).

Anyway, after a strong Cisco exam, and the CCNA CCAI Instructor Course, I was a bit surprised when I see the new firewall waiting on my desk at office.... It's a new Ju(hemhemmmm) a new Juniper SRX-650 !!

the nice thing is that I feel like a ccna using junos, I have to learn cli commands from basics again ! ;-)

Well doesn't matter, here the shots :







Well, this week I'll prepare some general fw policies, next week I'll follow the new Wism and Wcs Server installation, then, after Holydays will be the turn of this firewall.....

Stay tuned!

Marco ;-)

Saturday, December 5, 2009

Today's work in a shot: switch installation in a new building

Hi all,

today was my last working day before holydays.

I'll spend the next 10 days studying on written topics (exam planned on Dec 16th) and trying to become a CCNA instructor (CCNA CCAI course by Europa Networking Bg)

So what's better than finish your week with a simple 4 switches installation?

here are two shots:






The white one is obviuosly not mine (wrong vendor ;) )

Ehehe too few cables here... I'll see what happening when people will move into this new building (not a new spaghetti rack hopefully) ;-)


Marco

Friday, November 27, 2009

Today's work in a shot: initial Lwapp Access Points config




Nice to have 6 radios turned on on my desk ;-)

Today I have prepared 6 x 1242 Lwapp access points (not much config to do... just name and something else).

Marco

Wednesday, November 18, 2009

STP Root and a simple trick

Hi all,
today I was playing with some switches and I realized this strange STP output:

3560-48#sh spann vlan 10

VLAN0010
Spanning tree enabled protocol ieee
Root ID Priority 24586
Address 0015.facf.0000
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 24586 (priority 24576 sys-id-ext 10)
Address 0015.facf.0000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 15

Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/8 Desg FWD 19 128.10 P2p
Fa0/10 Desg FWD 19 128.12 P2p
Fa0/14 Desg FWD 19 128.16 P2p
Fa0/16 Desg FWD 19 128.18 P2p
Fa0/47 Desg LBK 19 128.51 P2p

This switch is the root bridge for Vlan10, but note that port Fa0/47 is in blocking state.

Here the same output after enabling RSTP, nothing changed:

3560-48# sh spanning-tree vlan 10

VLAN0010
Spanning tree enabled protocol rstp
Root ID Priority 24586
Address 0015.facf.0000
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 secstyle="font-family: verdana;"

Bridge ID Priority 24586 (priority 24576 sys-id-ext 10)
Address 0015.facf.0000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300

Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/8 Desg FWD 19 128.10 P2p Peer(STP)
Fa0/10 Desg FWD 19 128.12 P2p Peer(STP)
Fa0/14 Desg FWD 19 128.16 P2p Peer(STP)
Fa0/16 Desg FWD 19 128.18 P2p Peer(STP)
Fa0/47 Back BLK 19 128.51 P2p

3560-48#


Well the question is ... why a STP root bridge has a blocked port?
as you can see from the second output, it's classified as "Backup" ... but here we are the root, so doesn't make it sense a backup port to reach the root...

If you want to know how it's possible ....Click HERE and laugh ;-) [+/-]



3560-48#sh run int fa 0/47
Building configuration...

Current configuration : 147 bytes
!
interface FastEthernet0/47
switchport access vlan 10
switchport mode access
switchport nonegotiate
no keepalive
end


woops and a L1 loopback inserted into fa 0/47 ;-)



With this physical loopback and keepalive disabled, the port goes up and every bpdu sent is also received, so if I have correctly understood, the root bridge is convincted to have an additional port to reach the root ;-)

... I have several Layer 8 problems, I know ;-)))))

Monday, November 9, 2009

BGPGEN: a simple TCL script to generate BGP prefixes

hi all,
during my courses at Europa Networking (BG, Italy) I've always heard Rocco Tessicini talking about a script to generate BGP prefixes on Cisco routers.
Suddently I haven't found one ready to download, so today I've decided to write my own (the simpler, the better)

Here the resulting script:


##################################################################################
## Tclsh BGPGEN SCRIPT v0.3 Beta: Add random BGP prefixes to a process
## Use with care on CISCO routers
## By Marco Rizzi ( http://rizzitech.blogspot.com ) marco.rizzi.com[A_T]gmail.com
## Date Nov 09, 2009
## licensed under a Creative Commons Attribution 3.0 United States License
## ( http://creativecommons.org/licenses/by/3.0/us/ ) ;-)
##################################################################################
### USAGE: BGPGEN (number_of_prefixes_to_gen) (bgp_as_number)

## BE CAREFUL! too much prefixes will consume a lot of router resource!
## DON'T USE ON PRODUCTION SYSTEMS, IT'S ONLY FOR LAB TESTING
## No warranty, provided "AS IS"

## Main procedure
proc BGPGEN {n_prefixes bgp_as} {
## 1) adds a redistribute static command under your bgp process
ios_config "router bgp $bgp_as" "redistribute static"

## 2) creates random static routes to null0 interface from /16 to /24
for {set i 0} {$i <= $n_prefixes} {incr i} {
Gen_rnd_Static
}
}


####################################################################

proc Gen_rnd_Static {} {
## Generate random static routes
## to null0 with variable subnet mask betw 16 and 24 bits

## Network: A.B.C.0 Subnet Mask: 255.255.CM.0
set bits [expr {int(rand()*8)}]
set CM 0
if {$bits == 0} { set CM 0 ; set C 0 }
if {$bits == 1} { set CM 128 ; set C [expr {int(rand()*1)*128}]}
if {$bits == 2} { set CM 192 ; set C [expr {int(rand()*3)*64}]}
if {$bits == 3} { set CM 224 ; set C [expr {int(rand()*7)*32}]}
if {$bits == 4} { set CM 240 ; set C [expr {int(rand()*15)*16}]}
if {$bits == 5} { set CM 248 ; set C [expr {int(rand()*31)*8}]}
if {$bits == 6} { set CM 252 ; set C [expr {int(rand()*63)*4}]}
if {$bits == 7} { set CM 254 ; set C [expr {int(rand()*127)*2}]}
if {$bits == 8} { set CM 255 ; set C [expr {int(rand()*255)}]}

## Create the random network: A.B.C.0
set A [expr {int(rand()*223)}]
## some not bullet-proof control to avoid
## "strange" or private addresses (can be improved ;-) )
if {$A <= 10} { set A [expr {$A + int(rand()*200)}]}
if {$A == 127} { set A [expr {int(rand()*223)}]}
if {$A == 172} { set A [expr {int(rand()*223)}]}
if {$A == 192} { set A [expr {int(rand()*223)}]}

set B [expr {int(rand()*254)}]

## configure the final static
ios_config "ip route $A.$B.$C.0 255.255.$CM.0 null0"

}

################################# END OF SCRIPT ###################################
##
##
### USAGE: BGPGEN (number_of_prefixes_to_gen) (bgp_as_number)
#### enjoy ;-)


Obviously I'm not a good programmer, so it can be improved.

to execute it, simply type tclsh and paste the code, look if there are some errors due to the fast paste, in this case, copy and paste smaller pieces...

then type eg.:
R3(tcl)#BGPGEN 10000 64500

and wait until BGPGEN execution terminates.

on the bgp neighbor you can see the prefixes arriving....
eg:

R2#sh ip bgp summary
BGP router identifier 23.23.23.2, local AS number 65000
BGP table version is 146398, main routing table version 146398
34489 network entries using 4552548 bytes of memory
34489 path entries using 1793428 bytes of memory
2/1 BGP path/bestpath attribute entries using 296 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 6346296 total bytes of memory
BGP activity 90156/55667 prefixes, 90707/56218 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
12.12.12.1 4 65000 3238 794 0 0 0 00:02:46 Active
23.23.23.3 4 64500 855 71 146237 0 0 00:01:49 34489
R2#


as well as you can see errors and experience crashes. ;-)

Any comment and/or feature/improvement is always wellcome!

have phun with your routing tables ;-)
Marco

Friday, November 6, 2009

AUX back-to-back: poor man's connection

Hi all,

today I have focused my attention on the Aux port, the only free I have in my old 2600's lab....

So, first I have found some old docs on Cisco.com explaining clearly how to connect two routers back-to-back using the AUX port:

Connecting Routers Back-to-Back Through the AUX Ports (Document ID: 10365 )

and then was time to try it:

1) use an old rollover RJ-45 cable to connect AUX ports (pins 1-8 to 8-1... as learned in CCNA times)


2) Find the AUX tty number on both sides:

R3#sh line
Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int
* 0 CTY - - - - - 0 0 0/0 -
65 AUX 9600/9600 - - - - - 0 0 0/0 -
66 VTY - - - - - 0 0 0/0 -
67 VTY - - - - - 0 0 0/0 -
68 VTY - - - - - 0 0 0/0 -
69 VTY - - - - - 0 0 0/0 -
70 VTY - - - - - 0 0 0/0 -

Line(s) not in async mode -or- with no hardware support:
1-64



R5#sh line
Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int
* 0 CTY - - - - - 0 0 0/0 -
5 AUX 9600/9600 - - - - - 0 0 0/0 -
6 VTY - - - - - 0 0 0/0 -
7 VTY - - - - - 0 0 0/0 -
8 VTY - - - - - 0 0 0/0 -
9 VTY - - - - - 0 0 0/0 -
10 VTY - - - - - 0 0 0/0 -

Line(s) not in async mode -or- with no hardware support:
1-4

As you can see, different hardware/platform can use different tty numbers for AUX port, here we have tty 65 and tty 5

3) configure the AUX port on both sides:

R5(config)#line aux 0
R5(config-line)#transport input all
R5(config-line)#modem inOut
R5(config-line)#flowcontrol hardware
R5(config-line)#speed 115200 !-- better than 9600...
R5(config-line)#end

!-- same on R3


4) Create and configure the async interfaces (each interface uses the tty number of AUX port as point 2)


R5(config)#int async 5 !-- remember the tty number for AUX?
R5(config-if)#encapsulation ppp
R5(config-if)#async default routing
R5(config-if)#async mode dedicated
R5(config-if)#ip address 10.0.0.5 255.255.255.0
R5(config-if)#end
R5#


R3(config)#int async 65 !-- remember the tty number for AUX?
R3(config-if)#encapsulation ppp
R3(config-if)#async default routing
R3(config-if)#async mode dedicated
R3(config-if)#ip address 10.0.0.3 255.255.255.0
R3(config-if)#end



wait a little and you will see messages like

R5#
*Nov 6 16:58:20.237: %LINK-3-UPDOWN: Interface Async5, changed state to up
*Nov 6 16:58:23.394: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async5, changed state to up
R5#


...Now you have a poor man's additional interface for your lab!
You can ping it and use it for dynamic routing (althrough u can't use it for mpls or other advanced features... ;-) ) (PS: Nov 14, another "informal meeting" aka a beer with Nicola Modena today (CCIE R&S #19119) and he said he used Aux back-to-back connections since a couple of years, and he runs mpls over it! ;-) so I corrected this post (and tryed it with mpls too ;-) )

R2#sh run int async 1 | beg int
interface Async1
ip address 192.168.0.2 255.255.255.0
encapsulation ppp
ip ospf 1 area 0.0.0.0
async dynamic routing
async mode dedicated
mpls ip
routing dynamic
end

R2#sh mpls interfaces detail
Interface Async1:
IP labeling enabled (ldp):
Interface config
LSP Tunnel labeling not enabled
BGP labeling not enabled
MPLS operational
MTU = 1500
R2#



Marco


NOTE: I have found an additional note on Document ID: 5465 (Configuring Dialout using a Modem on the AUX Port )
that say about the AUX speed:

speed 115200
!--- The AUX port on the 2600 supports a speed of 115200.
!--- Note: If you route through the AUX port, each character generates a
!--- processor interrupt. This is an abnormally high load on the CPU,
!--- which can be resolved if you use a lower AUX port speed.

I guess that in a lab environment the cpu usage will be low.

Monday, October 26, 2009

Another spaghetti rack

I was in a building last week, for some troubleshooting tasks.

When I entered the wiring closet to find a switch port for my laptop, it looked like...



one of the best spaghetti rack ever seen!




and here I found my port ;-)

(2nd switch from above, port 0/45...)

Marco

Thursday, October 22, 2009

Tip-of-day: ip access-list resequence

Hi all,

today's trick is access-list resequence.

Consider an access-list with ugly sequence numbers, maybe derived from several configuration changes, eg:


R6# sh access-lists
Extended IP access list test
1 permit tcp any any eq www
2 permit tcp any any eq 443
3 permit tcp any any eq domain
4 permit tcp 172.16.0.0 0.0.255.255 any eq telnet
5 permit tcp 172.16.0.0 0.0.255.255 any eq ssh
6 deny ip any any

R6#sh run | sec access-list
ip access-list extended test
permit tcp any any eq www
permit tcp any any eq 443
permit tcp any any eq domain
permit tcp 172.16.0.0 0.0.255.255 any eq telnet
permit tcp 172.16.0.0 0.0.255.255 any eq 22
deny ip any any


If I have to modify it, the "old times" method was to remove acl from interfaces, delete it, recreate it and then reapply on interfaces ... but this is an extended acl, you can insert and modify statements since they have sequence numbers.

In this case, as you can see, there's no space between sequence numbers, so today's trick is to resequence the acl with the "ip access-list resequence" command.
( see "Refining an IP Access List" )

Let's try it

R6#sh access-lists
Extended IP access list test
1 permit tcp any any eq www
2 permit tcp any any eq 443
3 permit tcp any any eq domain
4 permit tcp 172.16.0.0 0.0.255.255 any eq telnet (394 matches)
5 permit tcp 172.16.0.0 0.0.255.255 any eq 22
6 deny ip any any (24 matches)

R6# conf t
R6(config)#ip access-list resequence test ?
<1-2147483647> Starting Sequence Number

R6(config)#ip access-list resequence test 10 ?
<1-2147483647> Step to increment the sequence number

R6(config)#ip access-list resequence test 10 10 ?
< cr >

R6(config)#ip access-list resequence test 10 10
R6(config)#do sh ip access-lists test
Extended IP access list test
10 permit tcp any any eq www
20 permit tcp any any eq 443
30 permit tcp any any eq domain
40 permit tcp 172.16.0.0 0.0.255.255 any eq telnet (496 matches)
50 permit tcp 172.16.0.0 0.0.255.255 any eq 22
60 deny ip any any (24 matches)
R6(config)#


et voila', named access-list ready to be modified ;-)

Marco

Wednesday, October 14, 2009

Mpls Vpn review

Hi all,
I'm completely busy on studying CCIE R&S written but I want to share a mpls vpn lab for reviewing mpls arguments.

Here is the topology:



Task list for this lab is:
-R1-R2-R3-R4-R5-R6-R7 (ISP) cannot elect any DR/BDR to speed up convergence
-Any OSPF area 0.0.0.0 neighbor fault must be detected within 1 second or less (NOTE: if you use dynamips, this requirement can be skipped or "relaxed"..., the high cpu % utilization will bring up/down your adjacency when you perform some operations like enable mpls...)
-area 0.0.0.0 must be ready for future traffic engineer configurations
-All ISP loopbacks must be reachable by igp
-R1 act as MpBGP Route Reflector
-CE11, CE12 and CE13 belongs to the same organization named "Customer1", they use EIGRP AS 1 for L3-vpn connections
-CE21, CE22 and CE23 belongs to the same organization named "Customer2", they use BGP as 65222 for L3-vpn connections
-BB1 and BB2 are "the internet", they must declare at least 10.000 prefixes with bgp
-R1 must prefer BB1 for odd networks, BB2 for even networks
-Customers must receive only a default route to reach internet for every customer site

I used gns3 with 7200 for ISP and 3640 for customers.


Here the initial configs, just to speed up the lab start: [+/-]




!-------------------------------
!-- R1 initial config

conf t
hostname R1

no ip domain-lookup
line con 0
logging sync
no exec-timeout

int fa 0/0
desc R1 <-> R3
speed 100
duplex full
ip address 172.16.0.4 255.255.255.254
no shut

int fa 1/0
desc R1 <-> R2
speed 100
duplex full
ip address 172.16.0.2 255.255.255.254
no shut

int fa 1/1
desc R1 <-> R4
speed 100
duplex full
ip address 172.16.0.6 255.255.255.254
no shut

int fa 2/0
desc R1 <-> BB1
speed 100
duplex full
ip address 172.31.0.0 255.255.255.254
no shut

int fa 2/1
desc R1 <-> BB2
speed 100
duplex full
ip address 172.31.0.2 255.255.255.254
no shut

int lo 0
ip address 1.1.1.1 255.255.255.255
end

!-- END R1 initial config
!-------------------------------
!-- R2 initial config

conf t
hostname R2

no ip domain-lookup
line con 0
logging sync
no exec-timeout

int fa 0/0
desc R2 <-> R5
ip address 172.16.0.0 255.255.255.254
speed 100
dupl full
no shut

int fa 1/0
desc R2 <-> R1
speed 100
dupl full
ip addr 172.16.0.3 255.255.255.254
no shut

int lo 0
ip address 2.2.2.2 255.255.255.255
end

!-- END R2 initial config
!-------------------------------
!-- R3 initial config

conf t
hostname R3

no ip domain-lookup
line con 0
logging sync
no exec-timeout

int fa 0/0
desc R3 <-> R1
ip address 172.16.0.5 255.255.255.254
speed 100
dupl full
no shut

int fa 1/0
desc R3 <-> R6
speed 100
dupl full
ip addr 172.16.0.10 255.255.255.254
no shut

int lo 0
ip address 3.3.3.3 255.255.255.255
end

!-- END R3 initial config
!-------------------------------
!-- R4 initial config

conf t
hostname R4

no ip domain-lookup
line con 0
logging sync
no exec-timeout

int fa 0/0
desc R4 <-> R7
ip address 172.16.0.8 255.255.255.254
speed 100
dupl full
no shut

int fa 1/0
desc R2 <-> R1
speed 100
dupl full
ip addr 172.16.0.7 255.255.255.254
no shut

int lo 0
ip address 4.4.4.4 255.255.255.255

!-- END R4 initial config
!-------------------------------
!-- R5 initial config

conf t
hostname R5

no ip domain-lookup
line con 0
logging sync
no exec-timeout

int fa 0/0
desc R5 <-> R2
speed 100
dupl full
ip addr 172.16.0.1 255.255.255.254
no shut

int fa 1/0
desc R5 <-> CE21
speed 100
dupl full
ip address 10.21.0.0 255.255.255.254
no shut

int fa 1/1
desc R5 <-> CE11
speed 100
dupl full
ip address 10.11.0.0 255.255.255.254
no shut

int lo 0
ip address 5.5.5.5 255.255.255.255
end

!-- END R5 initial config
!-------------------------------
!-- R6 initial config

conf t
hostname R6

no ip domain-lookup
line con 0
logging sync
no exec-timeout

int fa 0/0
desc R6 <-> R3
ip address 172.16.0.11 255.255.255.254
speed 100
dupl full
no shut

int fa 1/0
desc R6 <-> CE12
speed 100
dupl full
ip addr 10.11.0.4 255.255.255.254
no shut

int fa 1/1
desc R6 <-> CE22
speed 100
dupl full
ip address 10.21.0.4 255.255.255.254
no shut

int lo 0
ip address 6.6.6.6 255.255.255.255
end

!-- END R6 initial config
!-------------------------------
!-- CE11 initial config

conf t
hostname CE11

no ip domain-lookup
line con 0
logging sync
no exec-timeout

int fa 0/0
desc CE11 <-> R5
ip address 10.11.0.1 255.255.255.254
speed 100
dupl full
no shut

int lo 111
ip address 192.168.1.1 255.255.255.0

int lo 112
ip address 172.17.1.1 255.255.255.128
end

!-- END CE11 initial config
!-------------------------------
!-- CE12 initial config

conf t
hostname CE12

no ip domain-lookup
line con 0
logging sync
no exec-timeout

int fa 0/0
desc CE12 <-> R6
ip address 10.11.0.5 255.255.255.254
speed 100
dupl full
no shut

int lo 121
ip address 192.168.2.1 255.255.255.0

int lo 122
ip address 172.17.1.129 255.255.255.128
end

!-- end CE12 initial config
!-------------------------------
!-- CE13 initial config

conf t
hostname CE13

no ip domain-lookup
line con 0
logging sync
no exec-timeout

int fa 0/0
desc CE13 <-> R7
ip address 10.11.0.3 255.255.255.254
speed 100
dupl full
no shut

int lo 131
ip address 192.168.3.1 255.255.255.0

int lo 132
ip address 172.17.2.1 255.255.255.0
end

!-- END CE13 initial config
!-------------------------------
!-- CE21 initial config

conf t
hostname CE21

no ip domain-lookup
line con 0
logging sync
no exec-timeout

int fa 0/0
desc CE21 <-> R5
ip address 10.21.0.1 255.255.255.254
speed 100
dupl full
no shut

int lo 211
ip address 192.168.0.1 255.255.254.0

int lo 212
ip address 172.17.1.1 255.255.252.0
end

!-- END CE21 initial config
!-------------------------------
!-- CE22 initial config

conf t
hostname CE22

no ip domain-lookup
line con 0
logging sync
no exec-timeout

int fa 0/0
desc CE22 <-> R6
ip address 10.21.0.5 255.255.255.254
speed 100
dupl full
no shut

int lo 221
ip address 192.168.2.1 255.255.254.0

int lo 222
ip address 172.17.4.1 255.255.252.0
end

!-- END CE22 initial config
!-------------------------------
!-- CE23 initial config

conf t
hostname CE23

no ip domain-lookup
line con 0
logging sync
no exec-timeout

int fa 0/0
desc CE23 <-> R7
ip address 10.21.0.3 255.255.255.254
speed 100
dupl full
no shut

int lo 231
ip address 192.168.4.1 255.255.254.0

int lo 232
ip address 172.17.8.1 255.255.252.0
end

!-- END CE23 initial config

Thursday, September 17, 2009

Today's work in a shot

Several boxes are waiting me since a week...

today I've unpacked two 4948 and several 2950, here the shots (only one 2950 already out of box)!





And the 4948s with redundant power supply:


Sunday, September 13, 2009

Back from vacations

Hi all, I'm just back from our fabulous vacations... any idea about the location?

Look:




... right! it's San Franciscooooo!!! ;-)

and what's better to take a shot like this when you pass near San Jose? ,-)



ehehe I hope one day to enter the Cisco Headquarter (ah dreaming.... )

Well, the good news is that from Sep. 20 2009 (it's sunday, I know...) I'll start the great CCIE R&S written course in Bergamo (Italy) made by Europa Networking, with Rocco Tessicini as instructor.
So for 5 sundays I'll wake up early to do 170 Km to reach Bergamo and studying the whole day.
I'll try to do the written exam by the end of 2009, so I imagine that my blog will be a little less active, at least with less labs.

Anyway, stay tuned for the most interesting ideas coming from the interaction with Rocco!

byeeee
Marco

Friday, August 14, 2009

WVIC 1MFT-E1 back-to-back for frame relay labs

Hi all,
after my old post "WVIC 1MFT-E1 back-to-back" I've tryed to configure a back-to-back connection between two MFT-E1 in order to use it to emulate a serial connection for frame relay studies.

Obviously, you don't need crossover serial cables, but a crossover Pri cable (RJ-45) as described in the old post ("WVIC 1MFT-E1 back-to-back")
Quick refresh of pins:
1 RX Ring - -> 4 TX Ring -
2 RX Tip + -> 5 TX Tip +
4 TX Ring - -> 1 RX Ring -
5 TX Tip + -> 2 RX Tip +

Well, it was really hard (at least for me) to find how to configure it!

First, let's look on the default config of the MFT E1 controller:


R1#sh run | section controller
controller E1 1/0/0

R1#sh controller e1 1/0/0
E1 1/0/0 is up.
Applique type is Channelized E1 - balanced
No alarms detected.
alarm-trigger is not set
Version info Firmware: 20071129, FPGA: 20, spm_count = 0
Framing is CRC4, Line Code is HDB3, Clock Source is Line.
Data in current interval (89 seconds elapsed):
4 Line Code Violations, 3 Path Code Violations
23 Slip Secs, 0 Fr Loss Secs, 3 Line Err Secs, 0 Degraded Mins
25 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

R1#show diag 1
Slot 1:
[...NM-HDV installed...]

WIC Slot 0:
E1 (1 Port) Multi-Flex Trunk WAN Daughter Card
Hardware revision 1.0 Board revision B0
Serial number 00000000 Part number 800-04475-03
FRU Part Number VWIC-1MFT-E1=

[....]

HDV firmware: Compiled Fri 19-Nov-04 14:23 by michen
HDV memory size 524280 heap free 193977


then, the necessary steps to configure it as a single E1 DATA connection are:
(this config has to be applied on BOTH sides)
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#controller
R1(config)#controller e1 1/0/0
R1(config-controller)#framing crc4 !-- optional, crc4 it's already the default
R1(config-controller)#linecode hdb3 !-- optional, hdb3 it's default too
R1(config-controller)#clock source internal
R1(config-controller)#channel-group 1 timeslots 1-31 speed 64
*Aug 14 19:16:16.119: %CONTROLLER-5-UPDOWN: Controller E1 1/0/0, changed state to up
*Aug 14 19:16:18.119: %LINK-3-UPDOWN: Interface Serial1/0/0:1, changed state to up
*Aug 14 19:16:19.123: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0/0:1, changed state to up

R1#sh run | section controller
controller E1 1/0/0
clock source internal
channel-group 1 timeslots 1-31

R1#sh controllers e1
E1 1/0/0 is up.
Applique type is Channelized E1 - balanced
No alarms detected.
alarm-trigger is not set
Version info Firmware: 20071129, FPGA: 20, spm_count = 0
Framing is CRC4, Line Code is HDB3, Clock Source is Internal.
Data in current interval (619 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
81 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
81 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Total Data (last 4 15 minute intervals):
5 Line Code Violations, 3294 Path Code Violations,
908 Slip Secs, 2 Fr Loss Secs, 3 Line Err Secs, 0 Degraded Mins,
909 Errored Secs, 0 Bursty Err Secs, 2 Severely Err Secs, 24 Unavail Secs

R1#sh run interface serial 1/0/0:1
Building configuration...

Current configuration : 46 bytes
!
interface Serial1/0/0:1
no ip address
end

R1#


As you can see, an interface Serial is created, then, you can use it as a traditional serial interface, bandwidth is 31 channels x 64k = 1984Kbps.

In addition, depending on how many NVRAM is allocated to your HDV (see show diag under "HDV memory size") you can create multiple serial interfaces by reducing the number of channels on channel-group.

eg:

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#controller e1 1/0/0
R1(config-controller)#no channel-group 1 timeslots 1-31
% Not all config may be removed and may reappear after reactivating the logical-interface/sub-interfaces
R1(config-controller)#channel-group 1 timeslots 1-8 speed 64
*Aug 14 19:35:29.475: %LINK-3-UPDOWN: Interface Serial1/0/0:1, changed state to up
*Aug 14 19:35:30.475: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0/0:1, changed state to up
R1(config-controller)#channel-group 2 timeslots 9-16 speed 64
R1(config-controller)#
*Aug 14 19:35:41.303: %LINK-3-UPDOWN: Interface Serial1/0/0:2, changed state to up
*Aug 14 19:35:42.303: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0/0:2, changed state to up

R1#sh run int serial 1/0/0:1 | beg int
interface Serial1/0/0:1
no ip address
end

R1#sh run int serial 1/0/0:2 | beg int
interface Serial1/0/0:2
no ip address
end

R1#sh diag 1 | beg WIC
WIC Slot 0:
E1 (1 Port) Multi-Flex Trunk WAN Daughter Card
Hardware revision 1.0 Board revision B0
Serial number 00000000 Part number 800-04475-03
FRU Part Number VWIC-1MFT-E1=

[...]

HDV firmware: Compiled Fri 19-Nov-04 14:23 by michen
HDV memory size 524280 heap free 625

R1#


note the "HDV memory size 524280 heap free 625", displayed if the MFT is installed into a NM-HDV module, doesn't allow you to create more channel-groups (unless you have channels 17-31 unallocated) because your HDV free memory is insufficent.... it you try this, you'll receive an error message like:

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#controller e1 1/0/0
R1(config-controller)#channel-group 3 timeslots 17-31 speed 64
Channel setup failed!!! s:t:c 1:0:3
HDV slot 1 DRAM size 524280 free 625 need 124992

%Insufficient resources to create channel group
R1(config-controller)#



If the MFT-E1 is installed on a HVic standard slot, the error is similar:


R2(config)#controller e1 0/2/0
R2(config-controller)#channel-group 1 timeslots 1-8 speed 64
*Aug 14 19:37:25.797: %LINK-3-UPDOWN: Interface Serial0/2/0:1, changed state to up
*Aug 14 19:37:26.797: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2/0:1, changed state to up
R2(config-controller)#channel-group 2 timeslots 9-16 speed 64
*Aug 14 19:37:32.937: %LINK-3-UPDOWN: Interface Serial0/2/0:2, changed state to up
*Aug 14 19:37:33.937: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2/0:2, changed state to up
R2(config-controller)#channel-group 3 timeslots 17-24 speed 64
%Channel-groups per port limit exceeded
%Insufficient resources to create channel group


Now we have two serial interfaces on each router, we can use them for frame relay, even with the "trick" of creating two vrfs on one router, to simulate a point-to-point topology, with the router without vrfs acting as fr switch.

eg:
R1#sh run
[...]
!-- only relevant parts displayed...
!
ip vrf one
rd 1:1
!
ip vrf two
rd 2:2
!
controller E1 1/0/0
clock source internal
channel-group 1 timeslots 1-8
channel-group 2 timeslots 9-16
!
interface Serial1/0/0:1
ip vrf forwarding one
ip address 172.16.0.1 255.255.255.0
encapsulation frame-relay
frame-relay interface-dlci 102
!
interface Serial1/0/0:2
ip vrf forwarding two
ip address 172.16.0.2 255.255.255.0
encapsulation frame-relay
frame-relay interface-dlci 201
!
!
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!-- on the other side, only relevant parts
!
R2#sh run
!
frame-relay switching
!
controller E1 1/0/0
clock source internal
channel-group 1 timeslots 1-8
channel-group 2 timeslots 9-16
!
!
interface Serial1/0/0:1
no ip address
encapsulation frame-relay
no frame-relay inverse-arp
frame-relay intf-type dce
clock rate 512000
frame-relay route 102 interface Serial1/0/0:2 201
!
interface Serial1/0/0:2
no ip address
encapsulation frame-relay
no frame-relay inverse-arp
frame-relay intf-type dce
clock rate 512000
frame-relay route 201 interface Serial1/0/0:1 102


let's verify it:
R1#sh ip route | beg Gateway
Gateway of last resort is not set

!--global routing table is completely empty

R1#sh ip route vrf one | beg Gateway
Gateway of last resort is not set

172.16.0.0/24 is subnetted, 1 subnets
C 172.16.0.0 is directly connected, Serial1/0/0:1

R1#sh ip route vrf two | beg Gateway
Gateway of last resort is not set

172.16.0.0/24 is subnetted, 1 subnets
C 172.16.0.0 is directly connected, Serial1/0/0:2

R1#ping vrf one 172.16.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/12/16 ms

R1#ping vrf two 172.16.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/13/16 ms
R1#


Now we can enjoy Frame Relay labs with cheap hand-made Rj-45 cables (but with expensive VWIC MFT-E1 cards ;-) )

Wednesday, August 12, 2009

Summer Lab 2009 vol.1

To prepare for vacations, what's better than a lab?

To refresh routing protocols, here is a new topology, named like a disco compilation ;-)

SummerLab 2009 vol.1



And here is the BGP part...




Happy labbing! ,-)

Wednesday, August 5, 2009

Today's work in a shot

Hi all, today's work included the configuration of two brand new 2960 PoE-24.

Here's the shot on my office desk ;-)


They are really quiet!

Here the final impact, not bad, but without a vertical cabling management system ;-)



Tuesday, August 4, 2009

Configuring Server Load Balancing

Hi all, at my workplace, we're considering the purchase of a load balancer to provide better redundancy and services availability to our customers.
Well, a load balancer with decent performances will cost a lot!
So my attention it's focused on the ip slb feature that it's present on 12.1 and 12.2 Ios.

First read the IOS "Server Load Balancing Feature in IOS Release 12.2(18)SXF" document on cisco site

Second, I'll try it in my lab, with an old 3660, simulating two web servers with routers ;--)

Let's take a look to the testing topology:


As we can read on the document above, there are several mode for slb, depending on what service is hosted on real servers: a simple one is slb for http servers

After configuring basic ip addressing and ip routing for this topology, we can try to assign a virtual server ip address to the slb router:


!-- configure first the real server farm
ip slb serverfarm HTTPSERVERS
nat server !-- notes on nat below...
predictor leastconns
real 10.0.0.2
weight 2
faildetect numconns 3 !-- note: this means something line "3 failed conns from 3 different clients"
inservice
real 10.0.0.3
weight 3
faildetect numconns 3
inservice

!-- then configure the virtual server
ip slb vserver 10.5.5.5
virtual 10.5.5.5 tcp www !-- it balances only for www port
serverfarm HTTPSERVERS !-- associates the real server farm to this virtual server
sticky 180 !-- same client will use the same real server for 180 secs
inservice


SLB_ROUTER#sh ip route 10.5.5.5
Routing entry for 10.5.5.5/32
Known via "static", distance 1, metric 0 (connected)
Redistributing via eigrp 35
Advertised by eigrp 35
Routing Descriptor Blocks:
* 10.5.5.5, via Null0
Route metric is 0, traffic share count is 1

SLB_ROUTER#


Here I used the server NAT feature, so web servers are completely unaware of the load balancer, and they can be several hops away from slb....
If you don't use server NAT, the load balance acts only at L2 level, on MAC addresses, so you have to configure a loopback with the virtual server ip on real servers in order to accept L3 packets with dest address the virtual ip.
A static route pointing to null0 interface is automatically added for each vserver.

Verify if the slb is up and running:

SLB_ROUTER#sh ip slb vservers

slb vserver prot virtual state conns
-------------------------------------------------------------------
10.5.5.5 TCP 10.5.5.5:80 INSERVICE 0

SLB_ROUTER#sh ip slb serverfarms

server farm predictor nat reals bind id
---------------------------------------------------
HTTPSERVERS LEASTCONNS S 2 0

SLB_ROUTER#sh ip slb reals

real server farm weight state conns
-------------------------------------------------------------------
10.0.0.2 HTTPSERVERS 2 OPERATIONAL 0
10.0.0.3 HTTPSERVERS 3 OPERATIONAL 0

The state of real servers is "OPERATIONAL" after a try, or "READY_TO_TEST" before the first connection is received.

On real "servers" I have configured only "ip http server" and the necessary route to reach clients.... let's try from client perspective....


Client#telnet 10.5.5.5 80
Trying 10.5.5.5, 80 ... Open

...and then...

[Connection to 10.5.5.5 closed by foreign host]
Client#

and on the slb router you can see:

SLB_ROUTER#sh ip slb conns

vserver prot client real state nat
-------------------------------------------------------------------------------
10.5.5.5 TCP 172.17.0.25:14455 10.0.0.3 ESTAB S

SLB_ROUTER#sh ip slb sticky

client netmask group real conns
-----------------------------------------------------------------------
172.17.0.25 255.255.255.255 4097 10.0.0.3 1

SLB_ROUTER#sh ip slb reals detail
10.0.0.2, HTTPSERVERS, state = OPERATIONAL
conns = 0, dummy_conns = 0, maxconns = 4294967295
weight = 2, weight(admin) = 2, metric = 0, remainder = 0
reassign = 3, retry = 60
failconn threshold = 3, failconn count = 0
failclient threshold = 2, failclient count = 0
total conns established = 0, total conn failures = 0
server failures = 0

10.0.0.3, HTTPSERVERS, state = OPERATIONAL
conns = 1, dummy_conns = 0, maxconns = 4294967295
weight = 3, weight(admin) = 3, metric = 0, remainder = 1
reassign = 3, retry = 60
failconn threshold = 0, failconn count = 0
failclient threshold = 0, failclient count = 0
total conns established = 2, total conn failures = 0
server failures = 0


Now, if a server fails, what's happening? Let's try to shut down a "server" interface:

Real-Web-Server2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Real-Web-Server2(config)#int eth 0/0
Real-Web-Server2(config-if)#shut
Real-Web-Server2(config-if)#shutdown
Real-Web-Server2(config-if)#end
Real-Web-Server2#


SLB_ROUTER#debug ip slb all
SLB All debugging is on
SLB_ROUTER#
4w3d: SLB_CONN_DEBUG: TCP event= SYN_CLIENT, state= INIT -> SYNCLIENT
4w3d: v_ip= 10.5.5.5:80 ( 3), real= 10.0.0.3, NAT(S)
4w3d: client= 172.17.0.25:21706
4w3d: SLB_CONN_DEBUG: TCP event= SYN_CLIENT, state= SYNCLIENT -> SYNCLIENT
4w3d: v_ip= 10.5.5.5:80 ( 3), real= 10.0.0.3, NAT(S)
4w3d: client= 172.17.0.25:21706
4w3d: SLB_CONN_DEBUG: TCP event= SYN_CLIENT, state= SYNCLIENT -> SYNCLIENT
4w3d: v_ip= 10.5.5.5:80 ( 3), real= 10.0.0.3, NAT(S)
4w3d: client= 172.17.0.25:21706
4w3d: SLB_CONN_DEBUG: TCP event= SYN_CLIENT, state= SYNCLIENT -> SYNCLIENT
4w3d: v_ip= 10.5.5.5:80 ( 3), real= 10.0.0.3, NAT(S)
4w3d: client= 172.17.0.25:21706
4w3d: SLB_REAL_DEBUG: 10.0.0.3 (HTTPSERVERS) event = SLB_CONN_FAIL state= OPERATIONAL -> OPERATIONAL
4w3d: SLB_REAL_DEBUG: 10.0.0.3 (HTTPSERVERS) event = SLB_REAL_FAILURE state= OPERATIONAL -> FAILED
4w3d: SLB_CONN_DEBUG: TCP event= SYNACK_SERVER, state= SYNCLIENT -> ESTAB
4w3d: v_ip= 10.5.5.5:80 ( 3), real= 10.0.0.2, NAT(S)
4w3d: client= 172.17.0.25:21706
4w3d: SLB_CONN_DEBUG: TCP event= DATA_CLIENT, state= ESTAB -> ESTAB
4w3d: v_ip= 10.5.5.5:80 ( 3), real= 10.0.0.2, NAT(S)
4w3d: client= 172.17.0.25:21706
4w3d: SLB_CONN_DEBUG: TCP event= DATA_CLIENT, state= ESTAB -> ESTAB
4w3d: v_ip= 10.5.5.5:80 ( 3), real= 10.0.0.2, NAT(S)
4w3d: client= 172.17.0.25:21706
SLB_ROUTER#
SLB_ROUTER#sh ip slb reals detail
10.0.0.2, HTTPSERVERS, state = OPERATIONAL
conns = 1, dummy_conns = 0, maxconns = 4294967295
weight = 2, weight(admin) = 2, metric = 0, remainder = 1
reassign = 3, retry = 60
failconn threshold = 3, failconn count = 0
failclient threshold = 2, failclient count = 0
total conns established = 3, total conn failures = 0
server failures = 0

10.0.0.3, HTTPSERVERS, state = FAILED
conns = 0, dummy_conns = 0, maxconns = 4294967295
weight = 3, weight(admin) = 3, metric = 0, remainder = 0
reassign = 3, retry = 60
failconn threshold = 0, failconn count = 1
failclient threshold = 0, failclient count = 1
total conns established = 2, total conn failures = 2
server failures = 1

SLB_ROUTER#

!-- after 60 sec the failed server is placed in "READY_TO_TEST" state
SLB_ROUTER#
4w3d: SLB_REAL_DEBUG: 10.0.0.3 (HTTPSERVERS) event = SLB_REAL_TIMEOUT state= FAILED -> READY_TO_TEST
SLB_ROUTER#





As next step I'll test it on my production 6509...

Sunday, July 26, 2009

sunday's tip: Disabling DTP on access ports

Hi all,
this sunday morning I'm changing the spanning-tree mode for some switches (from pvst to rapid-pvst) and I noticed that DTP was enabled on several access ports.

Remember that DTP (Dynamic Trunking Protocol) is used to negotiate trunks between switches, so it's not a good idea to keep it enabled on access ports, especially if access ports are in public places...

This is the configuration I've found:

2950_1#sh ver | inc IOS
IOS (tm) C2950 Software (C2950-I6Q4L2-M), Version 12.1(22)EA4, RELEASE SOFTWARE (fc1)

2950_1#sh run int fa 0/10 | beg int
interface FastEthernet0/10
switchport access vlan 55
spanning-tree portfast

Nothing strange here, the port is working in access mode (see "operational mode" below), but without the "switchport mode access" command, DTP still enabled on port:

2950_1#sh dtp int fa 0/10
DTP information for FastEthernet0/10:
TOS/TAS/TNS: ACCESS/DESIRABLE/ACCESS
TOT/TAT/TNT: NATIVE/802.1Q/802.1Q
Neighbor address 1: 000000000000
Neighbor address 2: 000000000000
Hello timer expiration (sec/state): 11/RUNNING
Access timer expiration (sec/state): never/STOPPED
Negotiation timer expiration (sec/state): never/STOPPED
Multidrop timer expiration (sec/state): never/STOPPED
FSM state: S2:ACCESS
# times multi & trunk 0
Enabled: yes
In STP: no

Statistics
----------
0 packets received (0 good)
0 packets dropped
0 nonegotiate, 0 bad version, 0 domain mismatches,
0 bad TLVs, 0 bad TAS, 0 bad TAT, 0 bad TOT, 0 other
857578 packets output (857578 good)
428789 native, 428789 software encap isl, 0 isl hardware native
0 output errors
0 trunk timeouts
20 link ups, last link up on Fri Feb 27 2009, 13:15:09
19 link downs, last link down on Fri Feb 27 2009, 13:15:07

2950_1#sh int fa 0/10 switchport
Name: Fa0/10
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: static access
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: On
Access Mode VLAN: 55 (Ingresso)
Trunking Native Mode VLAN: 1 (default)
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk private VLANs: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL
Protected: false
Appliance trust: none


So, it can happen that a malicius user see the DTP hellos coming out from that port and try to negotiate a trunk.
To avoid this, let's disable DTP through the static access mode:


2950_1#sh run int fa 0/10 | beg int
interface FastEthernet0/10
switchport access vlan 55
switchport mode access
spanning-tree portfast
end


Now DTP must be disabled, let's check:

2950_1#sh dtp int fa 0/10
DTP information for FastEthernet0/10:
TOS/TAS/TNS: ACCESS/OFF/ACCESS

TOT/TAT/TNT: NATIVE/802.1Q/NATIVE
Neighbor address 1: 000000000000
Neighbor address 2: 000000000000
Hello timer expiration (sec/state): never/STOPPED
Access timer expiration (sec/state): never/STOPPED
Negotiation timer expiration (sec/state): never/STOPPED
Multidrop timer expiration (sec/state): never/STOPPED
FSM state: S1:OFF
# times multi & trunk 0
Enabled: no
In STP: no

Statistics
----------
0 packets received (0 good)
0 packets dropped
0 nonegotiate, 0 bad version, 0 domain mismatches,
0 bad TLVs, 0 bad TAS, 0 bad TAT, 0 bad TOT, 0 other
0 packets output (0 good)
0 native, 0 software encap isl, 0 isl hardware native
0 output errors
0 trunk timeouts
20 link ups, last link up on Fri Feb 27 2009, 13:15:09
20 link downs, last link down on Sun Jul 26 2009, 12:12:22

2950_1#sh int fa 0/10 switchport
Name: Fa0/10
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access

Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 55 (Ingresso)
Trunking Native Mode VLAN: 1 (default)
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk private VLANs: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL
Protected: false
Appliance trust: none


Well done, now the port state is "static access", no more negotiation.

Wednesday, July 15, 2009

Monitoring 6500 switch fabric, trying to understand switching mode

Hi all, last week I had an informal meeting (also called a beer) with Nicola Modena CCIE #19119 (thanks buddy)!

During the long and interesting conversation, he asked me what was the utilization of my 6500s...
I answered someting like "Cpu is under 5%", and he said "well, but traffic isn't process switched, what's about the fabric?"

Good point Nic!

So today I've read the "Configuring a Supervisor Engine 720" section of the Catalyst 6500 Release 12.2SXF and Rebuilds Software Configuration Guide...

...and tryed to understand the various show fabric outputs.

Here is my show module and show fabric:
6509# sh module 
Mod Ports Card Type Model Serial No.
--- ----- -------------------------------------- ------------------ -----------
1 24 CEF720 24 port 1000mb SFP WS-X6724-SFP Serials omitted
2 10 WiSM WLAN Service Module WS-SVC-WISM-1-K9 S..
3 48 CEF720 48 port 10/100/1000mb Ethernet WS-X6748-GE-TX S..
5 2 Supervisor Engine 720 (Active) WS-SUP720-3B S..
6 2 Supervisor Engine 720 (Hot) WS-SUP720-3B S..

Mod MAC addresses Hw Fw Sw Status
--- ---------------------------------- ------ ------------ ------------ -------
1 001b.d4ec.7860 to 001b.d4ec.7877 2.6 12.2(14r)S5 12.2(18)SXF9 Ok
2 001c.5843.7cb0 to 001c.5843.7cbf 2.0 12.2(14r)S5 12.2(18)SXF9 Ok
3 001c.587b.20a0 to 001c.587b.20cf 2.6 12.2(14r)S5 12.2(18)SXF9 Ok
5 0019.e7d3.a2ac to 0019.e7d3.a2af 5.4 8.4(2) 12.2(18)SXF9 Ok
6 001a.2f3b.f80c to 001a.2f3b.f80f 5.4 8.4(2) 12.2(18)SXF9 Ok

Mod Sub-Module Model Serial Hw Status
---- --------------------------- ------------------ ----------- ------- -------
1 Centralized Forwarding Card WS-F6700-CFC S.. 3.1 Ok
2 Centralized Forwarding Card WS-SVC-WISM-1-K9-D S.. 2.0 Ok
3 Centralized Forwarding Card WS-F6700-CFC S.. 3.1 Ok
5 Policy Feature Card 3 WS-F6K-PFC3B S.. 2.3 Ok
5 MSFC3 Daughterboard WS-SUP720 S.. 3.0 Ok
6 Policy Feature Card 3 WS-F6K-PFC3B S.. 2.3 Ok
6 MSFC3 Daughterboard WS-SUP720 S.. 3.0 Ok

Mod Online Diag Status
---- -------------------
1 Pass
2 Pass
3 Pass
5 Pass
6 Pass
6509#
6509#sh fabric
show fabric active:
Active fabric card in slot 5
Backup fabric card in slot 6

show fabric mode:
Global switching mode is Compact
dCEF mode is not enforced for system to operate
Fabric module is not required for system to operate
Modules are allowed to operate in bus mode
Truncated mode is allowed, due to presence of CEF720, Standby supervisor module

Module Slot Switching Mode
1 Crossbar
2 Crossbar
3 Crossbar
5 dCEF
6 Crossbar

show fabric congestion management
:
Fabric clear-block is off.

show fabric status all:
slot channel speed module fabric
status status
1 0 20G OK OK
2 1 N/A OK OK
3 0 20G OK OK
3 1 20G OK OK
5 0 20G OK OK
6 0 20G OK OK

show fabric utilization all:
slot channel speed Ingress % Egress %
1 0 20G 1 1
2 1 8G 0 0
3 0 20G 0 0
3 1 20G 0 1
5 0 20G 0 1
6 0 20G 0 0

show fabric errors all:
Module errors:
slot channel crc hbeat sync DDR sync
1 0 0 0 0 0
2 1 0 0 0 0
3 0 0 0 0 0
3 1 0 0 0 0
5 0 0 0 0 0
6 0 0 0 0 0

Fabric errors:
slot channel sync buffer timeout
1 0 0 0 0
2 1 0 0 0
3 0 0 0 0
3 1 0 0 0
5 0 0 0 0
6 0 0 0 0



This is our core L3, it has two Sup720-3B installed and configured as hot-standby, two switching modules (24 sfp and 48 Rj45) and a (double) Wism installed.
As you can see from show fabric utilization, we're using 1% of the 20Gbps bus capacity for modules 1,3,5....

For a better understanding of the 6500 architecture, read the interesting white paper: Cisco Catalyst 6500 Architecture White Paper
Another interesting resource is: Notes on Cisco Catalyst 6500 Architecture

If I don't have misunderstood, here the "global switching mode" is "Compact", due to the presence of CEF720 switching modules that have a "Crossbar" connection and due to SUP720-3B, so according with the whitepaper: "In this mode of operation, the switch can achieve centralized performance of up to 30Mpps independent of packet size.".

Not bad! We are under-utilizing a lot this platform!

Let's take a look to a distribution L3 switch:

6506#sh module
Mod Ports Card Type Model Serial No.
--- ----- -------------------------------------- ------------------ -----------
1 24 CEF720 24 port 1000mb SFP WS-X6724-SFP Serials omitted
2 24 CEF720 24 port 1000mb SFP WS-X6724-SFP S...
3 48 48 port 10/100/1000mb EtherModule WS-X6148-GE-TX S...
5 2 Supervisor Engine 720 (Active) WS-SUP720-3B S...

Mod MAC addresses Hw Fw Sw Status
--- ---------------------------------- ------ ------------ ------------ -------
1 0021.a0b4.00b0 to 0021.a0b4.00c7 3.3 12.2(18r)S1 12.2(33)SXH4 Ok
2 0021.a07e.fbd8 to 0021.a07e.fbef 3.3 12.2(18r)S1 12.2(33)SXH4 Ok
3 0021.a08c.aa10 to 0021.a08c.aa3f 7.2 7.2(1) 8.7(0.22)BUB Ok
5 0021.1bff.09dc to 0021.1bff.09df 5.7 8.5(2) 12.2(33)SXH4 Ok

Mod Sub-Module Model Serial Hw Status
---- --------------------------- ------------------ ----------- ------- -------
1 Centralized Forwarding Card WS-F6700-CFC S.. 4.1 Ok
2 Centralized Forwarding Card WS-F6700-CFC S.. 4.1 Ok
5 Policy Feature Card 3 WS-F6K-PFC3B S.. 2.4 Ok
5 MSFC3 Daughterboard WS-SUP720 S.. 3.2 Ok

Mod Online Diag Status
---- -------------------
1 Pass
2 Pass
3 Pass
5 Pass

6506#sh fabric
show fabric active:
Active fabric card in slot 5
No backup fabric card in the system

show fabric mode:
Global switching mode is Truncated
dCEF mode is not enforced for system to operate
Fabric module is not required for system to operate
Modules are allowed to operate in bus mode
Truncated mode is allowed, due to presence of CEF720 module

Module Slot Switching Mode
1 Crossbar
2 Crossbar
3 Bus
5 Bus

show fabric congestion management:
Fabric clear-block is off (operational).

show fabric status all:
slot channel speed module fabric hotStandby Standby Standby
status status support module fabric
1 0 20G OK OK Y(not-hot)
2 0 20G OK OK Y(not-hot)
5 0 20G OK OK Y(not-hot)

show fabric utilization all:
slot channel speed Ingress % Egress %
1 0 20G 0 0
2 0 20G 0 0
5 0 20G 0 0

show fabric errors all:
Module errors:
slot channel crc hbeat sync DDR sync
1 0 0 0 0 0
2 0 0 0 0 0
5 0 0 0 0 0

Fabric errors:
slot channel sync buffer timeout
1 0 0 0 0
2 0 0 0 0
5 0 0 0 0


with a quick look to "Ethernet and Gigabit Ethernet Switching modules" I realized that module 3 in this 6506E, 48 port 10/100/1000mb EtherModule (WS-X6148-GE-TX) has only a "BUS" connection, it's a so called "classic line card", that's why the switching mode is "Truncated".

Let's take a look to wikipedia: http://en.wikipedia.org/wiki/Catalyst_6500 simple, nice photo..
6509 from wikipedia