- Used where there are fibre links between switches (but can also be applied to Copper interfaces)
- Interface could be seen as Up/Up but due to a mismatch on the tx/rx pairs the comms become unidirectional
- UDLD Normal mode error-disabled the end that detected the unidirectional state - default mode
- UDLD Agressive mode disables both ends - set it with the [agressive] switch
- Uses 15 sec hello timer
- Can be applied globally or on the interface
Wednesday, November 14, 2012
CCDP - ARCH - UDLD (UniDirectional Link Detection):
Monday, November 12, 2012
CCDP - ARCH - STP tools
The following tools can be used to manage STP and L2 switching loops:
- PortFast: applied to a port connecting to an end user/host. Transitions the ports straight to forwarding
- UplinkFast: Offers L2 link load balancing, up to 5 secs convergence time once a link fails
- BackboneFast: Invoked when an inferor BPDU is received on a root port or blocked port. Reduces convergence times after an indirect failure.
- Loop Guard: Stops a bridging loop by preventing an Alternate port or Root port becoming a Designated port.
- Root Guard: Protects the Root switch by preventing other switches from taking the Root role.
- BPDU Guard: Apply to PortFast enabled ports. If the port recieves a BPDU the port gets shutdown
- UDLD (UniDirectional Link Detection): Detects when one-way connection exists on a copper/fibre link. Interface moves to a shutdown state and an alarm is triggered.
- Bridge Assurance: If a port that should receive BPDU's suddenly stops receiving them the port is moved to an 'Inconsistant' state and shutdown. Prevents potential loops
Sunday, July 15, 2012
Thoughts on the CCDA exam...
I sat the CCDA exam the other day and was stunned to find that I hadn't passed it. Sitting here now I'm still little confused if I'm honest. The exam consists of 55 questions to be completed in 75 minutes which is plenty of time. I finished with 15 minutes go and that was after I made myself slow down.
Thinking on I'm trying to remember the style of questions I faced and to be honest I'm struggling to remember specifics. I'm not going to challenge the NDA you sign so all I say is that standard of question is no more technically challenging than the level you get in the Office Cert Guide by Bruno and Jordan. I can think of one area however I probably did fall down on. The test papers.
In the Offical Cert Guide and on the Cisco Learning Network there are practice question that you can try. When ever I did them I passed with flying colours. In the practice exams I did 3 attempts and pass them all by a good margin so I felt I was ready. At no point during the exam did I feel that it was getting the better of me and I think there were only 2 questions where I felt I needed to guess. As a result I was actually shocked when it said I hadn't met the grade.
I'm about to reschedule the exam for a few weeks time and today I reviewed the Offical Cert Guide and compared it to the Exam Topics list off the Cisco Learning Network. The main thing that lept out to me was that while the Exam topics are set out one way, the Offical Cert Guide is set out in a different structure. As a result it's not immediately clear how the study material relates to the exam objectives.
I'm going to spend this week comparing and contrasting the material I have and will ramp up the exam practice. Finally I'll be reviewing (again) Enterprise Architecture, and Network Services.
Onwards and upwards...
Thinking on I'm trying to remember the style of questions I faced and to be honest I'm struggling to remember specifics. I'm not going to challenge the NDA you sign so all I say is that standard of question is no more technically challenging than the level you get in the Office Cert Guide by Bruno and Jordan. I can think of one area however I probably did fall down on. The test papers.
In the Offical Cert Guide and on the Cisco Learning Network there are practice question that you can try. When ever I did them I passed with flying colours. In the practice exams I did 3 attempts and pass them all by a good margin so I felt I was ready. At no point during the exam did I feel that it was getting the better of me and I think there were only 2 questions where I felt I needed to guess. As a result I was actually shocked when it said I hadn't met the grade.
I'm about to reschedule the exam for a few weeks time and today I reviewed the Offical Cert Guide and compared it to the Exam Topics list off the Cisco Learning Network. The main thing that lept out to me was that while the Exam topics are set out one way, the Offical Cert Guide is set out in a different structure. As a result it's not immediately clear how the study material relates to the exam objectives.
I'm going to spend this week comparing and contrasting the material I have and will ramp up the exam practice. Finally I'll be reviewing (again) Enterprise Architecture, and Network Services.
Onwards and upwards...
Thursday, June 28, 2012
Password recovery on a Cisco ME3400 Switch
Continuing my notes on password recovery on various bits of kit. Today's task was an ME3400 Switch.
Perform the following steps to regain access to your switch:
Perform the following steps to regain access to your switch:
- Power up the switch and send the Break sequence (dependant on the system you are working from) to access Password Recovery
- Load the helper files: switch#load_helper
- Next, verify the name of your config file: switch#dir
- Rename said config file: switch#rename flash:config.txt flash:config.txt.old
- Reboot the system: switch#boot
- Next you'll be prompt to enter the auto config process. Enter No
- Enter the PRIV EXEC mode: switch>en
- Rename your config file: switch#rename flash:config.txt.old flash:config.txt
- Copy the config in the Memory: switch#copy flash:config.txt system:running-config
- Next change your passwords as you see fit
- Last part is to check the state of your interfaces. You may need to #no shut your appropriate ports.
Monday, June 25, 2012
CCNP - ENTERPRISE - Duplex Mismatch
Right, not done any posts for a while so here we go with a note on Duplex Mismatches...
A Duplex Mismatch occurs when 2 devices are directly connected with different duplex modes. One end might be set to auto whilst the other could be set mannually to Full Duplex.
The situation is usually the result of manual configuration of an interface and the result can cause a number of effects on the network.
The most common situation for a duplex mismatch is the example above, one end set to auto (negotiate) and the other set to Full Duplex. With one end trying to negotiate whilst the other end is not the result is that the negotiation fails and the interface fails back to Ethernet standards and sets it's self to half duplex. This default action when negotiation fails allows for older hubs to be in operation in the network.
With one end now automatically set to Half Duplex and the other end manually set to Full Duplex you get the duplex mismatch.
The activity observed on the network can be varied. For example a duplex mismatch will not affect PING as the single packets are sent at 1 second intervals and therefore the link can process the traffic with out any issue being observed. Telnet will be seen as slow but you should still be able to run your session.
The main issue you will see is when both ends of the link attempt to send traffic at the same time. The end set Full Duplex can sendand receive data at the same time. No problems there, however, the end set to Half Duplex will not receive any data because it is busy sending first. The combination will result in packets from the Full Duplex end being lost whilst packets from the Half Duplex end will be slow or lost as that end perceives a collision is occurring and will run CSMA/CD.
As packets are now being lost TCP attempts to perform error recovery and retransmit the packets. This will fail as well due to the mismatch in place.
In the Full Duplex end you will see Frame Check Sequence errors and/or runt frames as packets are lost in transit.
The key to the operation to configure both ends the same. Use only Auto OR Full.
Resolution:
Simply change the setting on one end of the link to match the configuration of the other end.
A Duplex Mismatch occurs when 2 devices are directly connected with different duplex modes. One end might be set to auto whilst the other could be set mannually to Full Duplex.
The situation is usually the result of manual configuration of an interface and the result can cause a number of effects on the network.
The most common situation for a duplex mismatch is the example above, one end set to auto (negotiate) and the other set to Full Duplex. With one end trying to negotiate whilst the other end is not the result is that the negotiation fails and the interface fails back to Ethernet standards and sets it's self to half duplex. This default action when negotiation fails allows for older hubs to be in operation in the network.
With one end now automatically set to Half Duplex and the other end manually set to Full Duplex you get the duplex mismatch.
The activity observed on the network can be varied. For example a duplex mismatch will not affect PING as the single packets are sent at 1 second intervals and therefore the link can process the traffic with out any issue being observed. Telnet will be seen as slow but you should still be able to run your session.
The main issue you will see is when both ends of the link attempt to send traffic at the same time. The end set Full Duplex can sendand receive data at the same time. No problems there, however, the end set to Half Duplex will not receive any data because it is busy sending first. The combination will result in packets from the Full Duplex end being lost whilst packets from the Half Duplex end will be slow or lost as that end perceives a collision is occurring and will run CSMA/CD.
As packets are now being lost TCP attempts to perform error recovery and retransmit the packets. This will fail as well due to the mismatch in place.
In the Full Duplex end you will see Frame Check Sequence errors and/or runt frames as packets are lost in transit.
The key to the operation to configure both ends the same. Use only Auto OR Full.
Resolution:
Simply change the setting on one end of the link to match the configuration of the other end.
Tuesday, March 13, 2012
Off topic - HR: The Spark Way
Have you got to perform a company restructure? need reduce head count? not sure where to start in your vast empire? Never fear the patented Spark method is here to help!
Step one : Obtain a list of all employees in the company and make sure their Job title is included.
Step two : Tell an educated but uninformed individual the job title of the first employee in the list and ask them to describe what that person does
Step three : If the first word out of the individual's mouth is 'Err???....???' then that person can be chopped :o)
Step four : Repeat for all employees and you'll have your list of jobs that can be culled.
Marvellous! :o)
Step one : Obtain a list of all employees in the company and make sure their Job title is included.
Step two : Tell an educated but uninformed individual the job title of the first employee in the list and ask them to describe what that person does
Step three : If the first word out of the individual's mouth is 'Err???....???' then that person can be chopped :o)
Step four : Repeat for all employees and you'll have your list of jobs that can be culled.
Marvellous! :o)
Monday, January 23, 2012
Upgrade IOS on an ASR-1002F
Steps to upgrade IOS on an ARS-1002F are as follows:
- Copy your IOS .bin file to a USB stick and connect it to USB0 on the front of the ASR
- Connect the power and press 'Escape' on startup to access ROMMON
- At the prompt do > boot usb0:
- The router will boot using the ASR image you have on the USB
- Once booted do #copy usb0:asr10~7q.bin bootflash:
- Confirm the location and the .bin file will transfer
- Next, set the system to boot from bootflash - #boot system flash bootflash:asr10~7q.bin
- Next set the config-register to ensure it boots properly - (config)#config-register 0x2102
- Write this - #wr mem
- Finally reload the asr and ensure it boots correctly - #reload
Friday, January 20, 2012
Password Recovery on a Catalyst 3750-E
Password recovery on a Catalyst 3750-E
- Press and hold the Mode button on the front of the system then connect the power
- Continue holding until the SYS LED blinks from green, to amber, to green, then turns solid green.
- Release Mode and you should have a prompt for – switch:
- Do – switch: flash_init
- Next do – switch: dir flash:
- Next do - switch: rename flash:config.text flash:config.old
- Next do – switch: boot
- Once the system reboots you can either save the blank config and work from a clean install #wr mem
- Or, recover the old config and reset the password:
- Then do - #copy flash:config.text system:running-config
- Change all the passwords and apply an appropriate user account:
(config)#enable secret [password]
(config)#username Trevor password [password]
(config)#line con 0
password
[password]
login
(config)#line vty 0 4
password
[password]
login
- Finally save the config and reload -
#wr mem
#reload
Password Recovery on a Cisco 5580
Steps to reset a password on a Cisco ASA 5580
- Boot the system and press escape as the system loads
- At ROMMON set confreg to 0x41 - >confreg 0x41
- then reload >boot
- When prompted type 'No' to by pass the auto configuration steps.
- Once at the command prompt copy the start-up config to running config:
(config)#copy start run
- Next change the password to on of your choice:
(config)#password [password]
(config)#enable password [password]
- Add a user account with priv 15 access:
(config)#username Trevor password [password] priv 15
- Change the configuration register back to the correct one:
(config)#config-register 0x1
- Finally write this and then reload:
#wr mem
#reload
- Test and you should be good.
Wednesday, November 30, 2011
Extend your LAN across multiple sites using L2TPv3 Tunnels
We have a situation where we want to move a number of servers from our office to our data centre. In order for our networking monitoring to remain active we need to be able to present the same subnet at both locations as though they were on a local LAN.
To achieve this we've implemented L2TPv3 Tunnels (L2 tunnel) using Pseudo-wires on routers at each location.
This article is to document the steps taken to implement the solution so I have record it should I want to do this again.
First off a few definitions courtesy of Wikipedia.org:
L2TPv3 -Layer 2 Tunneling Protocol Version 3 is an IETF standard related to L2TP that can be used as an alternative protocol to Multiprotocol Label Switching (MPLS) for encapsulation of multiprotocol Layer 2 communications traffic over IP networks. Like L2TP, L2TPv3 provides a ‘pseudo-wire’ service, but scaled to fit carrier requirements.
Pseudo-wire - a pseudowire (or pseudo-wire) is an emulation of a point-to-point connection over a packet-switching network. The service being carried over the "wire" may be Asynchronous Transfer Mode (ATM), Frame Relay, Ethernet or Time-division multiplexing (TDM) while the packet network may be Multi-protocol label switching (MPLS), Internet Protocol (IPv4 or IPv6), or Layer 2 Tunneling Protocol Version 3 (L2TPv3).
You will need:
You are going to configure the tunnel on routers R3 and R4 with the tunnel configuration applied to the LAN side port on each router. The source of the tunnel will be a loopback interface on each router, so this needs to be routable.
Step 1 - Configure your routers for general connectivity. Apply a /32 address to Lo0, apply a public IP to your WAN side interface and leave the LAN side interface with out an IP.
Step 2 - Configure your routing. How ever you choose to configure your routing (EIGRP, OSPF, Static) you need to ensure R3 can ping Lo0 on R4 and visa versa.
Step 3 - Define your L2TPv3 'class' - used to configure connection parameters such as authentication and hello timers. Configure it on each router as follow:
R3#conf t
R3(config)# l2tp-class networkstV3class
R3(config)#authentication
R3(config)#password N3tw0rkStud1es
+++
R4#conf t
R4(config)# l2tp-class networkstV3class
R4(config)#authentication
R4(config)#password N3tw0rkStud1es
Step 4 - Next apply this to a Pseudo-Wire and define your Lo0 interface as the source of the L2TPv3 tunnel:
R3(config)#pseudowire-class NETWORKST-PW
R3(config-pw-class)#encapsulation l2tpv3
R3(config-pw-class)#protocol l2tpv3 networkstV3class
R3(config-pw-class)#ip local interface loopback0
+++
R4(config)#pseudowire-class NETWORKST-PW
R4(config-pw-class)#encapsulation l2tpv3
R4(config-pw-class)#protocol l2tpv3 networkstV3class
R4(config-pw-class)#ip local interface loopback0
Step 5 - Finally apply the pseudo-wire to the interface that connects to your LAN:
R3(config)#int f0/1
R3(config-if)#xconnect 40.40.40.40 1 pw-class NETWORKST-PW
- the xconnect cmd associates the interface f0/1 to the remote peer's pseudo-wire located at 40.40.40.40
- the figure 1 is a virtual circuit ID and needs to match at both ends.
R4(config)#int f0/1
R4(config-if)#xconnect 30.30.30.30 1 pw-class NETWORKST-PW
Step 6 - Verify the configuration, use the following command to verify the tunnel is up:
R3#sh l2tun tunnel all
%No active L2F tunnels
L2TP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 60290 is up, remote id is 28046, 1 active sessions
Tunnel state is established, time since change 20:14:20
Tunnel transport is IP (115)
Remote tunnel name is R4
Internet Address 40.40.40.40, port 0
Local tunnel name is R3
Internet Address 30.30.30.30, port 0
Tunnel domain unknown
VPDN group for tunnel is not available
L2TP class for tunnel is l2tp_default_class
271913 packets sent, 31678 received
36256510 bytes sent, 2837214 received
Last clearing of "show vpdn" counters never
Control Ns 1216, Nr 1218
Local RWS 1200 (default), Remote RWS 1200 (max)
Tunnel PMTU checking disabled
Retransmission time 1, max 1 seconds
Unsent queuesize 0, max 0
Resend queuesize 0, max 1
Total resends 0, ZLB ACKs sent 1217
Current nosession queue check 0 of 5
Retransmit time distribution: 0 0 0 0 0 0 0 0 0
Sessions disconnected due to lack of resources 0
%No active PPTP tunnels
- here you are really looking at Packet sent and received. Should you find that either is zero then trouble shoot accordingly. Look at physical connectivity and routing.
Once you have active tunnels connect the LAN side interface to a switch on the same VLAN as your office LAN then connect your servers.
To achieve this we've implemented L2TPv3 Tunnels (L2 tunnel) using Pseudo-wires on routers at each location.
This article is to document the steps taken to implement the solution so I have record it should I want to do this again.
First off a few definitions courtesy of Wikipedia.org:
L2TPv3 -Layer 2 Tunneling Protocol Version 3 is an IETF standard related to L2TP that can be used as an alternative protocol to Multiprotocol Label Switching (MPLS) for encapsulation of multiprotocol Layer 2 communications traffic over IP networks. Like L2TP, L2TPv3 provides a ‘pseudo-wire’ service, but scaled to fit carrier requirements.
Pseudo-wire - a pseudowire (or pseudo-wire) is an emulation of a point-to-point connection over a packet-switching network. The service being carried over the "wire" may be Asynchronous Transfer Mode (ATM), Frame Relay, Ethernet or Time-division multiplexing (TDM) while the packet network may be Multi-protocol label switching (MPLS), Internet Protocol (IPv4 or IPv6), or Layer 2 Tunneling Protocol Version 3 (L2TPv3).
You will need:
- 2 routers capable of configuring L2tpv3 and Pseudo-wires, in our case we used Cisco 1841 routers running IOS:c1841-spservicesk9-mz.124-17b.bin
- Loopback interfaces on each router configured with an IP address (/32) that is routable to. These are the source IP's in your config so make sure you can ping them from each side before you start with the L2TPv3 tunnel config.
You are going to configure the tunnel on routers R3 and R4 with the tunnel configuration applied to the LAN side port on each router. The source of the tunnel will be a loopback interface on each router, so this needs to be routable.
Step 1 - Configure your routers for general connectivity. Apply a /32 address to Lo0, apply a public IP to your WAN side interface and leave the LAN side interface with out an IP.
Step 2 - Configure your routing. How ever you choose to configure your routing (EIGRP, OSPF, Static) you need to ensure R3 can ping Lo0 on R4 and visa versa.
Step 3 - Define your L2TPv3 'class' - used to configure connection parameters such as authentication and hello timers. Configure it on each router as follow:
R3#conf t
R3(config)# l2tp-class networkstV3class
R3(config)#authentication
R3(config)#password N3tw0rkStud1es
+++
R4#conf t
R4(config)# l2tp-class networkstV3class
R4(config)#authentication
R4(config)#password N3tw0rkStud1es
Step 4 - Next apply this to a Pseudo-Wire and define your Lo0 interface as the source of the L2TPv3 tunnel:
R3(config)#pseudowire-class NETWORKST-PW
R3(config-pw-class)#encapsulation l2tpv3
R3(config-pw-class)#protocol l2tpv3 networkstV3class
R3(config-pw-class)#ip local interface loopback0
+++
R4(config)#pseudowire-class NETWORKST-PW
R4(config-pw-class)#encapsulation l2tpv3
R4(config-pw-class)#protocol l2tpv3 networkstV3class
R4(config-pw-class)#ip local interface loopback0
Step 5 - Finally apply the pseudo-wire to the interface that connects to your LAN:
R3(config)#int f0/1
R3(config-if)#xconnect 40.40.40.40 1 pw-class NETWORKST-PW
- the xconnect cmd associates the interface f0/1 to the remote peer's pseudo-wire located at 40.40.40.40
- the figure 1 is a virtual circuit ID and needs to match at both ends.
R4(config)#int f0/1
R4(config-if)#xconnect 30.30.30.30 1 pw-class NETWORKST-PW
Step 6 - Verify the configuration, use the following command to verify the tunnel is up:
R3#sh l2tun tunnel all
%No active L2F tunnels
L2TP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 60290 is up, remote id is 28046, 1 active sessions
Tunnel state is established, time since change 20:14:20
Tunnel transport is IP (115)
Remote tunnel name is R4
Internet Address 40.40.40.40, port 0
Local tunnel name is R3
Internet Address 30.30.30.30, port 0
Tunnel domain unknown
VPDN group for tunnel is not available
L2TP class for tunnel is l2tp_default_class
271913 packets sent, 31678 received
36256510 bytes sent, 2837214 received
Last clearing of "show vpdn" counters never
Control Ns 1216, Nr 1218
Local RWS 1200 (default), Remote RWS 1200 (max)
Tunnel PMTU checking disabled
Retransmission time 1, max 1 seconds
Unsent queuesize 0, max 0
Resend queuesize 0, max 1
Total resends 0, ZLB ACKs sent 1217
Current nosession queue check 0 of 5
Retransmit time distribution: 0 0 0 0 0 0 0 0 0
Sessions disconnected due to lack of resources 0
%No active PPTP tunnels
- here you are really looking at Packet sent and received. Should you find that either is zero then trouble shoot accordingly. Look at physical connectivity and routing.
Once you have active tunnels connect the LAN side interface to a switch on the same VLAN as your office LAN then connect your servers.
Subscribe to:
Posts (Atom)
