Thursday, January 28, 2010

Hardware Problem NM-4 A/S

I've been having a nagging problem on my R3 NM-4 A/S Serial module. The frame relay connections s1/0 s1/1 would work sometimes, then not much. The s1/2, and S1/3 were working.

I was wondering if it was a problem with my frame switch, or with the NM 4 A/s for the last few days, and tonight i have my answer.

I ran the debug serial interface on R3, and on r1, R2 to see what was happening with each interface configured as HDLC links.

I noticed R1 and R2 both continuosly going up and down but my Side would show up when it was transitioning between states.

On R3, my side was never showing up, and I notice transmission hang errors on the S1/2, S1/3.

I did sh controllers on S1/0, S1/1 (frame relay interfaces) and S1/1 and S1/2, and I saw Transmit Hangs on all of them. Debug output below for one of the interfaces:


Rack3R3#sh controllers s1/1
CD2430 Slot 1, Port 1, Controller 0, Channel 1, Revision 19
Channel mode is synchronous serial
idb 0x6454ABC0, buffer size 1524, V.35 DTE cable

Global registers
rpilr 0x2, rir 0x3, risr 0x0, rfoc 0x0, rdr 0x2
tpilr 0x1, tir 0x3, tisr 0x60, tftc 0x0, tdr 0x4
mpilr 0x3, mir 0x3, misr 0xE0
bercnt 0xFF, stk 0x0
Per-channel registers for channel 1
Option registers
0x02 0x00 0x42 0xE7 0xE0 0x00 0x00
Command and status registers
cmr 0xC0, ccr 0x00, csr 0xCC, msvr-rts 0xF1, msvr-dtr 0xF1
Clock option registers
rcor 0x06, rbpr 0x01, tcor 0xC8, tbpr 0x01
Interrupt registers
ier 0x89, livr 0x04, licr 0x04
DMA buffer status 0x00
DMA receive registers
arbaddr 0x7BC74E4, arbcnt 1548, arbsts 0x1
brbaddr 0x7BC6E64, brbcnt 1548, brbsts 0x1
rcbaddr 0x7BC74E4
DMA transmit registers
atbaddr 0x7A00AD4, atbcnt 14, atbsts 0x0
btbaddr 0x7A00994, btbcnt 13, btbsts 0x0
tcbaddr 0x7A00C21
Special character registers
schr1 0x00, schr2 0x00, schr3 0x00, schr4 0x00
scrl 0x0, scrh 0x0, lnxt 0xF1
Driver context information
Context structure 0x6454CEE4, Register table 0x3C800400
Serial Interface Control 5:1 Register (0x3C800806) is 0x0
Adaptor Flags 0x0
Serial Modem Control Register (0x3C800808) is 0x18
Receive static buffer 0x6445D4FC
Receive particle buffers 0x6454D5C0, 0x6454D580
Transmit DMA buffers 0x0, 0x0, 0x0, 0x0
Transmit packet with particles 0x0, first word is 0x0
Interrupt rates (per second) transmit 0, receive 0, modem 0
True fast-switched packets 0
Semi fast-switched packets 0
Transmitter hang count 300
Residual indication count 0
Bus error count 0
Aborted short frames count 0
CRC short frames count 42
Tx DMA low threshold count 0
Error counters
CTS deassertion failures 0
Nested interrupt errors transmit 0, receive 0, modem 0



So..!!. I ordered another NM-4 A/S from Ebay. I hope to get it soon so I can resume labbing.

IP Routing Labs

Over the last few days I have done the first 6 IP routing labs. I have been taking my time with these labs as while not to complicated, its great to run debugs and watch the behavior of different protocols.

Tonight I did my first lab where I learned about the IP SLA Feature. The task has Router 4 connected to Router 1 Loopback via a FastEthernet interface VLAN146, and Frame-relay connection. R4 has 2 static routes, one out FastE VLAN 146 with the default admin static route distance of 1, and a route to R1 Loopback via Frame-relay with admin distance of 2. The goal is to ensure IP reachability to the R1 Loopback if the Fastethernet route to R1 goes down. I created IP SLA echo to send echo request every 5 seconds, and then a enhanced tracking object to track that SLA. I then configured the static ip route with the Tracing Object. Configuration below, followed by the testing. *****NOTE I enabled debug ip routing so we could see the route automatically being added or deleted depending on if R1's ethernet interface was up. Also note, not many pings missed, Im sure if I lowered the IP SLA timer to send pings ever Second instead of every 5 seconds I can limit the packet loss even more.


ip sla 1
icmp-echo 155.3.146.1
frequency 5
ip sla schedule 1 life forever start-time now
!
!track 1 ip sla 1 reachability

ip route 150.3.1.0 255.255.255.0 FastEthernet0/1 track 1



Below is the test!

Rack3R1(config-if)#shut
Rack3R1(config-if)#
CCIE-Console>4
[Resuming connection 4 to R4 ... ]
.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
.....
%TRACKING-5-STATE: 1 ip sla 1 reachability Up->Down
RT: del 150.3.1.0/24 via 0.0.0.0, static metric [1/0]
RT: delete subnet route to 150.3.1.0/24
RT: NET-RED 150.3.1.0/24
RT: add 150.3.1.0/24 via 155.3.0.1, static metric [2/0]
RT: NET-RED 150.3.1.0/24.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!
CCIE-Console>1
[Resuming connection 1 to R1 ... ]

*Mar 2 03:01:56.027: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar 2 03:01:57.027: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
Rack3R1(config-if)#
Rack3R1(config-if)#no shut
Rack3R1(config-if)#
CCIE-Console>4
[Resuming connection 4 to R4 ... ]
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
%TRACKING-5-STATE: 1 ip sla 1 reachability Down->Up!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
RT: closer admin distance for 150.3.1.0, flushing 1 routes
RT: add 150.3.1.0/24 via 0.0.0.0, static metric [1/0]
RT: NET-RED 150.3.1.0/24!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.
Success rate is 99 percent (5651/5659), round-trip min/avg/max = 1/8/144 ms

Wednesday, January 20, 2010

Finished Volume 1 Switching Labs

Last night I finished the Volume 1 version 5 switching labs. I was able to complete the PPP Chap authentication using local authorization as well as the aaa ppp chap authentication using tacacs/radius - with failover to local authentication if those dont work. I learned quite a bit on this as I havent worked much with AAA.

Next was PPoE, and to be honest this was quite a pain in the a**. I don't think I completely was able to gain a full understanding of this. I need to go back and read some more and come back to this lab at a later time.

This morning on the way to work I read about IP Routing from the CCIE 4.0 Certification study guide. I took answered the practice questions and got most of them correct. I will supplement the reading by watching over the Internetwork expert Advanced class on demand on this topic, and then start the Volume 1 IP Routing lab workbook tonight when I get home. So far from what I can see so far, I need to get a really detailed grasp on frame-relay interface types, and how they behave with InArp etc, and then the OER/PfR(performance routing) This is entirely new to the lab blue print so I want to make sure I get alot of lab time in on this topic.

Monday, January 18, 2010

More Volume 1 Version 5 labs

Today I was able to complete quite a few labs. I did take my time to understand how the technology worked for each of them. I guess thats why It took me about 7 hours to do all of them. That is along time, but I do think it will pay off huge for me when I start doing the full scale labs.

First Lab was MST Root bridge election, followed by more MST(Load balancing using cost, load balancing with port-priority.) Configuring this was pretty similar to manipulating 802.1d spanning tree. Of course the major differences being that RSTP is enabled by default with MST and the other difference being you can map multiple VLAN MSTP processes to 1 instance, or multiple instances.

Next lab was configuring a protected port. I never new about this option on switches. Basically it acts as a stripped down version of Private VLAN's. The major difference is, the protected port feature is only locally significant on that switch, it can't span multiple switches like private vlan's can. So lets say you have two devices connected to 2 different ports on the same switch and you don't want them to talk to each other. All you have to do is configure each of those switchports with the switchport protected command. Of course like always, make sure they are unable to ping each other after the feature is enabled.

Next on the lab list today was Storm-control. Basically you can configure the switchport to limit the amount of unicast, multicast, or broadcast traffic it receives either by PPS(packets per second) or BPS(bits per second)

Next on the list today was static CAM entries. One of the requirements of the lab was cool and I learned something once again, YAY!! -- progress. The scenario had R1, R4, and R6 connected via VLAN 146. It wanted you to configure a static CAM entry so that traffic destined to the FastEthernet port of R4 was dropped. At first I was like what the hell, how is that possible. After searching through the command reference I found that when adding the static cam entry, you are able to enter the drop command. For example ( mac address-table static mac-addr VLAN 1 drop. So now traffic coming from R4 trying to communicate to R1 or R6 will be dropped or anyone communicating to R4 will drop as well.

Next were SPAN, and RSPAN. You would use this mainly to monitor traffic on certain interfaces or VLAN's, and send that traffic to another local switchport (SPAN), or a remote switchport (RSPAN). With RSPAN, you also need to configure a RSPAN Vlan transport Vlan. To do this configure your VLAN i.e VLAN 500, then inside of the VLAN configuration stipulate (remote-span). Of course this VLAN needs to exist on the switch you want to monitor traffic from and the switch you want to send the traffic to. So if your in VTP Transparent, statically configure on each switch, if VTP server, do it on the server.Pretty straightforward configuration.

The next lab was configuring switchports for both switchport access VLAN, and switchport voice vlan. No need to comment on anything here, basic stuff.

Next lab was where I learned something again. It was focused on Cisco IP Phone QoS Trust, and CoS Extend. The lab requirement wanted to configure the switchport to trust QoS Markings coming from a cisco-phone. That was pretty straigtforward (mls qos trust cisco-phone) or something like that, I dont have the command reference open hehe. Lastly, it wanted you to set the CoS of the data coming from the extended port on the Cisco phone. I think the command was something like switchport priority extend cos 1. Of course you need to tell the switchport to trust cos, and enable mls qos globally.

Next was flexlinks. Flexlink config is pretty straightforward. You configure a switchport and tell it what port will be its backup interface should it go down. You can also configure preemption to force the active port to be used if it comes back online.

Next was Fallback bridging. This was pretty straightforward as well. The lab wanted you to configure R1 and R4 with IPv4 and IPv6 addresses. Both routers were connected to the same Switch. They wanted you to configure IP addresses on the switch to be in the same Broadcast domain as R1 and R4 with Layer 3 SVI's. Also, it requested to enable RIP on all devices for these addresses. Then, after looking at the DOC CD for this all that was needed was to go configure each device in the same bridge group. Then Pings from R1 to R4 via IPv6 addresses were successful.

Last but not least, was Private VLAN's. I took a little while on this one becase I forgot how to associate the VLAN's. Also, I Forgot you need to be in VTP transparent mode. When configuring this and your layer 2 network extends multiple switches, its takes a little bit to configure each switch with all the private vlans. So the basic idea is you can segregate different hosts/devices and only allow communication in a few different ways. So there are a few different port types in Private VLAN config. The 1st is Promiscuous port, which is able to talk to every port. The 2nd is community port. The community port is able to talk to any devices in that same exact community VLAN.For example, if device A is in VLAN 1000 and device B is configure as a community port in VLAN 2000, they will not be able to talk, However they will be able to talk to the promiscuous port. If device A and Device B are in the same community VLAN lets say VLAN 1000, then they can talk. The last port is the Isolated port. When a port is configured as a isolated port it can only talk to the promiscuous port, and nothing else.


I only have PPP with PAP/CHAP, and PPOE left on the switching labs left in the Volume 1 Switching lab. After that I might focus on IP Routing tech labs.

Sunday, January 17, 2010

Volume 1 Version 5 Switching Labs

This weekend I have been going through some of the switching labs. Alot of the switching im quite comfortable with so I didnt want to waste any time. Today I focused on 802.1Q tunneling, and setting up Port-channel using PagP over a 802.1q tunnel. That was kind of interesting.

Next I worked on something as simple as root guard. I configured Switch 1 as the spanning-tree root for all VLAN's. I then configured the trunk links to Switch 2 and Switch 3 with the spanning-tree guard root command. So, this way if another switch connected in our layer 2 network starts advertising a BPDU claiming they are the root for one of the VLAN's it will put our port in a root inconsistent state for that VLAN's that the switch is claiming they are root for. So to test this functionality, I configured switch 4 as with a spanning-tree priority 0 for VLAN 1, and 10. Sure enough as soon as I did that, Switch 1 received that BPDU. When I issued the command show spanning-tree detail I saw that VLAN 1 and VLAN 10 were Root inconsistent. Next to further Verify VLAN 1, and 10 were in root inconsistent I configured SVI's on Switch 1 and 2 for VLAN 1. I tried pinging between the two and was unable to even though the interfaces were up/up. I configured SVI's on switch 1 and switch 2 for VLAN 138 (which did not receive a superior BPDU and was not in the root inconsistent state and was able to ping. Next I told Switch 4 not to be root for VLAN's 1 and 10. Switch one immediately noticed this, and came out of the root inconsistent states.

I just wanted to see how the L2 network would behave when this occured. I also noticed, that when the VLAN's were root inconsistent on SW1, SW2 and SW3 believed SW4 was Root for those VLAN's. Interesting!!

Monday, January 11, 2010

BGP Routing table view

I have struggled with learning how to use regular expressions. These are useful when creating ip as-path access-lists to filter or permit traffic from certain BGP AS's.

After watching a Internetwork expert Class on Demand, I learned there is a tool anyone can telnet to. Basically you can just telnet to route-views.routeviews.org. You can get a current view of the size of the current full internet routing table as seen below:

route-views.oregon-ix.net>sh ip bgp sum
BGP router identifier 128.223.51.103, local AS number 6447
BGP table version is 4872374, main routing table version 4872374
328870 network entries using 43410840 bytes of memory
10002703 path entries using 520140556 bytes of memory
1661334/58620 BGP path/bestpath attribute entries using 279104112 bytes of memory
1437779 BGP AS-PATH entries using 55658958 bytes of memory
21404 BGP community entries using 1369574 bytes of memory
60 BGP extended community entries using 7574 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 899691614 total bytes of memory
Dampening enabled. 1853 history paths, 4492 dampened paths
BGP activity 404599/70395 prefixes, 18008013/7986902 paths, scan interval 60 secs

Thats a whole lot of routes!

equipment racked and cabled


This weekend I spent quite a few hours getting my equipment racked. Once that was finished I was able to get the rack cabled .according to the internetwork expert version 4 topology.
Last night I watched some internetwork expert class on demand videos on advanced redistribution and quality of service. Here is a picture of my rack

Wednesday, January 6, 2010

Equipment tested

Last night after I got home from a long day's work I decided I wanted to test out all of the interfaces on some of the hardware receiced.

So far, all of the FastEthernet interfaces on all 3 of my 1841 routers work, and 5 of the WIC 1T-'s are working within these routers without any issues. Next, I tested the two 3550's. I connected a crossover cable to each of the ports and the links/trunks came up with no issues. Now all I need to do is upgrade the code of the 3550 to a EMI image, test the 3560's ports and uprade their images, then finish racking and cabling everything and my rack will be good to go.