Wednesday, December 11, 2013

CCDP - ARCH - Route filtering

Filter routes inbound to a router via a 'distribute-list' cmd to prevent inbound rutes from being learned.

Filter routes outbound to a neighbour via a 'redistribute [protocol] [process number] route-map FILTER' cmd and a deny statement on the FILTER route-map to stop routes from being advertised towards a neighbour.

CCDP - ARCH - Migrate Routing Protocols By Manipulating the AD

High level steps to move from one RP to another by manipulating the AD:
1) Configure the new RP and manually set the AD to be Higher (and therefore less preferred) than the current RP
2) Configure all devices as necessary and then check the topology using appropriate show commands
3) Ensure the new RP has all the required routes in its database
4) Either by increasing the AD on the current RP or by reducing the AD on the New RP change the AD so that the new RP is the preferred RP to use
5) Use show commands to ensure that the new RP is populating the routing table correctly (there shouldn't be any routes learned via the old protocol - if there are some then troubleshoot accordingly)
6) Remove the old RP from the routers
7) Move to normal running

Thursday, November 14, 2013

CCDP - ARCH - UDLD (UniDirectional Link Detection):


  • 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


Tuesday, November 12, 2013

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


Wednesday, October 16, 2013

Well Known Ports

The full range of available ports is 0 - 65536 and can be used dynamically by any application however in general ports 0 - 1024 are pre-defined and 'well known' which is to say 22 is always ssh, 80 is http and so on.

Port NumberDescription
1TCP Port Service Multiplexer (TCPMUX)
5Remote Job Entry (RJE)
7ECHO
18Message Send Protocol (MSP)
20FTP -- Data
21FTP -- Control
22SSH Remote Login Protocol
23Telnet
25Simple Mail Transfer Protocol (SMTP)
29MSG ICP
37
39
Time
RIP
42Host Name Server (Nameserv)
43WhoIs
49Login Host Protocol (Login)
53
67
68
Domain Name System (DNS)
bootps
bootpc
69Trivial File Transfer Protocol (TFTP)
70Gopher Services
79Finger
80
88
101
102
HTTP
Kerberos
Hostname
iso-tsap
103
107
X.400 Standard
rtelnet
108SNA Gateway Access Server
109POP2
110
111
113
POP3
sunrpc
auth
115
117
Simple File Transfer Protocol (SFTP)
uucp-path
118SQL Services
119
123
Newsgroup (NNTP)
NTP - Network Time Protocol
137NetBIOS Name Service
139NetBIOS Datagram Service
143Interim Mail Access Protocol (IMAP)
150NetBIOS Session Service
156SQL Server
161SNMP
179Border Gateway Protocol (BGP)
190Gateway Access Control Protocol (GACP)
194Internet Relay Chat (IRC)
197Directory Location Service (DLS)
389Lightweight Directory Access Protocol (LDAP)
396Novell Netware over IP
443HTTPS
444Simple Network Paging Protocol (SNPP)
445Microsoft-DS
458Apple QuickTime
546DHCP Client
547DHCP Server
563SNEWS
569MSN
1080Socks

Wednesday, October 2, 2013

Output Characters from PING

This table is taken from the following Cisco article:
Understanding PING and Traceroute Commands

The table below lists the possible output characters from the ping facility:
CharacterDescription
!Each exclamation point indicates receipt of a reply.
.Each period indicates the network server timed out while waiting for a reply.
UA destination unreachable error PDU was received.
QSource quench (destination too busy).
MCould not fragment.
?Unknown packet type.
&Packet lifetime exceeded.

And I just want to log this here for quick reference. Thanks

Monday, September 30, 2013

Download a Packet Capture from an ASA

Firstly run your capture:
1) create an access list that will match the packets you are interested in seeing e.g:
    #access-list TESTCAP extended permit tcp 10.10.10.0 255.255.255.0 host 10.10.10.254 eq ldap

2) Create the capture on your ASA:
   #capture TESTCAP access-list TESTCAP interface INSIDE

Let that run then once you have collected enough data (use sh capture TESTCAP to view the capture ) transfer the capture file (pcap) to your local machine to view in a packet analyser programme such as WireShark:
1) Download and install a TFTP server programe (I used Solarwinds TFTP server) and then start the server.
2) From the firewall concerned run change to the System Context then run the following :
    #changeto context system
    #copy /pcap capture:[ContextName]/TESTCAP tftp:
    You will be asked for the destination IP - this will be your laptop IP that is running TFTP
    Note - [ContextName] should be the name of the context that the capture is running on.
3) Check the TFTP-root folder on your local machine to verify the transfer was successful.
4) Open WireShark then open the pcap file from there.

Friday, September 6, 2013

View the Pre-Shared Key on an IPsec VPN tunnel-group

When troubleshooting VPN connectivity issues a common problem is a mis-matched pre-shared key.

When you add a pre-shared key to a tunnel-group if you issue a #sh run the output hides the key with a simple *. e.g:

tunnel-group 10.10.10.10 ipsec-attributes
 pre-shared-key *
 isakmp keepalive threshold 15 retry 2

To confirm precisely what has been applied (and therefore help confirm if both ends of your tunnel have the same key) use the following command:
 #more system:running-config

tunnel-group 10.10.10.10 ipsec-attributes
 pre-shared-key AbCdEfG192837645
 isakmp keepalive threshold 15 retry 2


Upgrade the IOS on a Cisco Catalyst 3750 switch

Steps to conduct an upgrade of the IOS are as follows:

  1. Download the new image from www.cisco.com using a suitable account
  2. Install a TFTP server such as SolarWinds TFTP Server (other TFTP programs are available)
  3. Boot the switch and apply an IP address to the VLAN1 interface
  4. Apply an IP in the same subnet to your PC/Laptop LAN port and cable up using a CAT5 straight through
  5. Ping both sides to confirm connectivity
  6. Copy the downloaded BIN image to the TFTP-Root folder you'll find on the C:drive
  7. Start the TFTP Server on the PC/Laptop
  8. On the switch back up the current image to your PC/Laptop #copy Flash:/[filename.bin] tftp
  9. Enter the required remote host IP and confirm the destination file name when prompted
  10. Allow the current file to copy over to the PC/Laptop
  11. Once complete delete the original from the switch to create space for the new image #delete /recursive Flash:/[filename.bin]
  12. Next copy the new image from the PC/Lpatop to the switch #copy tftp: flash:
  13. Enter the remote host details and file name then confirm
  14. Allow the file to copy
  15. Set the new BIN as the system boot image #boot system flash:/[filename.bin]
  16. write this #wr
  17. Reload



Verify the image in use via - #sh ver

It's your problem..No! it's yours!

What do you do when your firewall is receiving TCP resets from the customer yet the customer insists that they are not generating the packets from their side?

This is one that has been the focus of alot of attention this week. We could see that our VPN tunnel was being actively terminated from the customer side yet the customer stated that they weren't seeing any issues and there were no log entries on their side to suggest a problem.

In cases like these it's easy to assume that the customer is a) hiding something or b) an idiot. Thankfully after alot of consideration we settled on c) we were both right.

The cause of this issue was revealed when the customer supplied a trace route from their VPN firewall to our router on the edge of the network. Working systematically we simply ran a ping to each hop back to the customer and observed the results. The connection between us and our ISP was fine, no packet loss, and this confirmed to us that our side was good. We kept  pinging each hop in turn until Bingo! Packet Loss!

A quick search across the internet registrar websites (RIPE, AfriNIC, LACNIC, ARIN, APNIC) showed that the offending network belonged to the customers ISP. The peer between the ISP and the next hop to be precise. Once this had been established it was then easy to establish that the ISP had a case already open to investigate the peer issues and the activity we had been observing was part of it.

The result was that because packet loss was occurring, our side of the VPN kept resending tcp packets waiting for SYN ACK's that were never going to arrive (some did). The customer would get some of the resent TCP packets but because from their point of view the tunnel was up their firewall was ignoring the SYNs. Our firewall would then try again. The buffers on the customer firewall would fill up and aTCP reset would be generated because of this (note that the TCP reset was not related to the customer's active VPN Tunnel - hence they were stating that the TCP resets we were seeing were not being generated from their side of the VPN) and the process would start over again.

The morale of the story. This tale may well seem a tad dull but I have a point (really). It's about listening, it's easy to dismiss the other party as failing to listen, incompetent, inexperienced, or what have you and equally it's easy to assume that the issue is not on your network but with out thorough investigation and methodically investigating the path of the network, issues can be easily missed and assumptions be made. This in turn leads to misunderstanding and delay.

Listening. Another tool in the network engineer's toolkit.

Lesson learned...


Tuesday, September 3, 2013

VPN - QM FSM error and PFS

We're busy attempting to bring up a site to site IPSec tunnel to Cisco router from our ASA.

Phase1 is completing but Phase2 fails with a 'QM FSM Error'.

This very unhelpful error message results from PFS not matching at either end. Either set it or don't set but if you have one end configured and the other not then you'll get an error like the one above.

Check the config on both ends of your VPN and either add PFS or remove by entering the following:
[no] crypto map VPNCONNECTION set pfs [group1 | group2 | group 5 ]

Notes:
  • PFS must match at either end
  • The default action on an ASA is to be off
  • If you just enter 'set pfs' and don't define a group then group1 is offered by default and group1/group2 is accepted
  • If you set the group then the same group must be returned by the remote peer.


Cisco CCDA - Done!

At the start of August I returned to the site of my last attempt and faced the Cisco CCDA once again.

This time I have re-read the OCG, read more from the Cisco Design Zone -
http://www.cisco.com/en/US/netsol/ns982/networking_solutions_program_home.html

I had also reviewed all the exam material I had and not take the results for granted (as I did last time).

What I found with my resit was that is was SOOOOOO much harder! really hard. I'm mean difficult hard. Hard.

Cisco must have a large pool of questions on this exam as I only spotted one question on the entire exam that I recognised from my first attempt and the rest were very detailed and narrow on the topic selection. As it is, I took my time, paced my self as best I could and finished with about 5 minutes to spare. last time I done a good chunk of the exam in the first 15 minutes.

I passed with a reasonable (not brilliant) mark and I'm just grateful I'm now looking at my new certificate on the desk partition in front of me.

My advise for the exam is truely go in depth. As much as you can, learn the detail, and ensure you know the 'Key Topic' sections of OCG of by heart. It's a tough exam but lays the foundation for the ARCH exam so I guess it has to be.

I'm picking the books up in October and hope to have my CCDP by Christmas. Lets see shall we...

Monday, July 15, 2013

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...



Thursday, June 20, 2013

Troubleshooting IPSec Phase2 issues

Problem - '#sh crypto ipsec sa' shows packets are being encrypted outbound but no packets are being decrypted inbound.

  Check the following: 

  •     Crypto ACL at either end is a mirror of each other. Use host to host /32 addresses don't use subnets
  •     Check routing at remote end is in place with correct exit interface
  •     If traffic passes through a Firewall towards the VPN terminating peer check that NAT Traversal is in place - apply:

             policy-map global_policy
                 class inspection_default
                      inspect ipsec-pass-thru

  •     Check that port 500/4500/ah/esp are permitted on outbound acls to the remote end. Look at ACL's.
  •     Check that 'sysopt connection permit-vpn' is applied to permit IPSEC protocols to by pass ACLs that are applied to the tunnel interface

Thursday, June 13, 2013

Off Topic - Spark's Laws

I decided I'd write down some of my musings. Nothing structured just observations from family life, work life and life in general.

Here you go:

Spark's Laws

#1 - Always tell the truth, that way you never have to remember anything
#2 - The smaller the child the bigger the splash they can make in the pool
#3 - The smaller the child the bigger the poo you have to clean up
#4 - If everyone did their job right first time, every time we could all have Fridays off.
#5 - You have to pay tax. Get over it.
#6 - The public can't handle the truth. - The truth is war is not nice but at times necessary to stand up for freedom. Taxes are not nice but pay for everything around you.
#7 - The media can't handle the truth. - They expect politicians to be honest but when one is honest and says 'Yes, I made a mistake' they hound them until they are forced to resign, instead of allowing them to learn, improve and move on. Is it any wonder Politicians lie? (and sports personalities for that matter)
#8 - Nature is cruel. Civilization, technology, and education does not change that.
#9 - Project deadlines are simply the date at which the project gets signed off, renamed, restarted and the PM gets their bonus regardless of what is achieved
#10 - If you want a project to run smoothly. Show the PM where the coffee machine is, close the door, and continue as normal.
#11 - The earlier in a project life cycle you implement your build the higher the certainty you'll have to back it out and rebuild it with 'new, unexpected' requirements that should have been captured right at the start.
#12 - The job's not done until you've finished the documentation.
#13 - In business, once you start copying the competition you've lost.

I'll add more as I think of them.

Cheers.