Tuesday, March 18, 2014

CCDP - ARCH - Command Reference

This article looks to collect together the most frequent commands associated with the CCDP ARCH exam.

The point being that these are easy marks to pick up on the exam when you get a question such as 'Name the command that allows you to [insert task here]'

This list is by no means complete and I'll add further commands as I find them.

OSPF - Originate a default route in to OSPF
    #router ospf 10
        #default-information originate [always]

OSPF - On the ABR filter out all advertised routes accept those listed in the range command
Limits the size of the DB and reduces the flooding internally
    #router ospf 1
         #area 20 range 192.168.200.0 255.255.255.0

OSPF - On the ASBR filter routes sent out externally to those explicitly listed.
    #router ospf 20
         #summary address [prefix] [mask]

OSPF - Tune the OSPF hello timer interval for faster convergence
    #interface f0/0
        #ip ospf hello-interval [seconds]

OSPF - tune SPF timers to increase efficiency
    #conf t
          #timers throttle spf [spf-start] [spf-hold] [spf-max-wait]

OSPF - Increase the reference bandwidth to factor in high speed link such as 10GB ethernet, do this across all links for consistency
    #router ospf 20
          #auto-cost reference-bandwidth 10000 (for 10Gb ethernet links)

EIGRP - Originate a default route in to EIGRP
    #conf t
         #ip default-network [network ip]

EIGRP - configure unequal-cost load balancing
    #router eigrp 1
       #variance 2

BGP -configure neighbor as a Client of the route reflector
    #router bgp 65123
        #neighboor 1.1.1.1 route-reflector-client

IPv6 - enable IPv6 routing for use with RIPng, EIGRP for Ipv, OSPFv3 etc
    #conf t
         #ip v6 unicast-routing

IPv6 - Define a base prefix to use for addressing:
  #conf t
       #ipv6 general-prefix [prefix]

CEF - Eliminate CEF Polarisation where one redundant link ends up being preferred to the other
    #conf t
         #mls ip cef load-sharing

EtherChannel - Use this to ensure all links within an Etherchannel bundle are utilised effectiviely
    #conf t
        #port-channel load-balance src-dst-port

FlexLinks  - Configure a port to act as a resilient backup for FlexLinks. Configure this on the primary link.
    #interface f0/10
       #switchport backup-interface [interface id]

Friday, March 7, 2014

CCDP - ARCH - Well Known Multicast Addresses

In the CCDP ARCH exam there are numerous refereences to Multicast addresses.

This post is to simply catalogue those that are specifically refered to in the various reading materials I've covered.

Address Scope:
  • 224.0.0.0 /4 - Class D reservation
Address type:
  • 224.0.0.0 to 224.0.0.255 - assigned by IANA for services (detailed below)
  • 224.0.1.0 to 224.0.1.255 - Control Block - assigned by IANA for traffic crossing public networks e.g.- NTP 224.0.1.1
  •  224.0.2.0 to 224.0.255.255 - AD-HOC block assigned by IANA for addresses that don't fit the above ranges
  • 224.3.0.0 to 224.4.255.255 - AD-HOC block assigned by IANA for addresses that don't fit the above ranges
  • 233.252.0.0 to 233.255.255.255-  AD-HOC block assigned by IANA for addresses that don't fit the above ranges
  • 232.0.0.0 255.0.0.0 - Source-Specfic Multicast Addresses
  • 233.0.0.0 255.0.0.0 - GLOP addresses - Originally experimental now publically assigned addresses for use by ISPs and any organisation want to ublich content over Multicast
  • 234.0.0.0 255.0.0.0 - Uni-cast Prefix addresses
  • 239.0.0.0 255.0.0.0 - Administratively scoped IPv4 addresses, locally assigned, not globally unique
Well Known Addresses:


  • 224.0.0.1 The All Hosts multicast group addresses all hosts on the same network segment.

  • 224.0.0.2 The All Routers multicast group addresses all routers on the same network segment.

  • 224.0.0.5 The Open Shortest Path First (OSPF) All OSPF Routers address is used to send Hello packets to all OSPF routers on a network segment.

  • 224.0.0.6 The OSPF All Designated Routers ""(DR)"" address is used to send OSPF routing information to designated routers on a network segment.

  • 224.0.0.9 The Routing Information Protocol (RIP) version 2 group address is used to send routing information to all RIP2-aware routers on a network segment.

  • 224.0.0.10 The Enhanced Interior Gateway Routing Protocol (EIGRP) group address is used to send routing information to all EIGRP routers on a network segment.

  • 224.0.0.13 Protocol Independent Multicast (PIM) Version 2

  • 224.0.0.18 Virtual Router Redundancy Protocol (VRRP)

  • 224.0.0.19 - 21 IS-IS over IP

  • 224.0.0.22 Internet Group Management Protocol (IGMP) version 3

  • 224.0.0.102 Hot Standby Router Protocol version 2 (HSRPv2) / Gateway Load Balancing Protocol (GLBP)

  • 224.0.1.1 Network Time Protocol clients listen on this address for protocol messages when operating in multicast mode.

  • 224.0.1.39 The Cisco multicast router AUTO-RP-ANNOUNCE address is used by RP mapping agents to listen for candidate announcements.

  • 224.0.1.40 The Cisco multicast router AUTO-RP-DISCOVERY address is the destination address for messages from the RP mapping agent to discover candidates.

  • 224.0.1.41 H.323 Gatekeeper discovery address

  • 239.255.255.250 Simple Service Discovery Protocol address




  • Tuesday, January 14, 2014

    CCDP - ARCH - Spark's rules for Design

    Last year I passed the CCDA and I'm presently studying for the ARCH exam and during my studies I've noticed common themes in how to approach network design.

    In general I've found that it comes down to making the best of what you've got (unless you're Google and simply commission your own hardware and build your very own private internet - coming to home near you soon...)

    Based on that I've noted the following observations during my studies:

    • Divide and Conquer! - Large flat networks are generally a bad idea, they propagate all the broadcast/multicast traffic to all hosts, make poor use of available network resourse (bandwidth, increase work on routers/firewalls etc),  are difficult to scale, increase the impact of a network event across the environment. Where possible segment it. For example:
      • OSPF - Make use of backbone routers in Area 0 and then use different areas to limit the propagation of Link State Advertisiements. In doing this you reduce the amount bandwidth used up by the OSPF process, you reduce the about of processing load on the routers within each area and the LSA's are limited to each area (reducing the content of the Routing Table). Originate the Default Route from Area 0 and where possible make use of Stub, Totally Stubby and Not-So-Stubby-Areas to reduce LSA/Route propagation.
      • Campus Design - Make good use of Hierarchical designs with a Core, Distribution/ Aggregation, Access Layers. These scale well, limits broadcast domains and make troubleshooting more logical
      • IP Address Assignment - Use contiguous networks and avoid any discontiguous subnets. Contiguous subnets makes address assignment easier (more efficient allocation of address space), troubleshooting easier, you can trace through the network easier, allows for efficient route summarisation and redistribution.
    • Summarise it! - Expanding on the previous point, when advertising routes, where possible advertise summary routes for destinations in a given area/zone. By advertising a summarised route you are reducing the size of routing tables on upstream routers and you then limit the impact of route flaps within the network. If a single link goes down then a route that is advertised as a /30 would need removing from all routers that have a route for this network. If the failed link falls under a /24 route then the upstream routers don't observe the link flap and do not have to re-calculate the shortest path which inturn means that resources on upstream routers are not utlised unneccesarily.
    • Keep It Simple! - At the dead of night that on call network engineer will not thank you for building that convoluted network that makes use of lesser know commands just because it's fancy. Always consider how difficult troubleshooting the proposed solution will be and keep it simple. For example:
      • Avoid OSPF virtual links - an network outage in the transit area could cut off the remote area to area 0
      • Keep access lists consistent - Agree on a naming convention for access lists, object-groups, hosts. Agree on how an access list will be named and how it will be constructed and stick to it. Being consistent will make for a cleaner running-config and will make reading it easier which in turn should make troubleshooting easier
    Now, the point of the rules above is to apply each rule as measure of how to approach exam questions. For any given question can the rules above be applied and the correct answer revealed? (Of course you should know your stuff when it comes to sitting an exam but sometimes you get blind sided by a badly worded question)

    Remember to be methodical and ultimately consider What Would Cisco Do...?

    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


    Monday, October 21, 2013

    So you made a mistake....

    Recently I was making what I thought was a routine change and it backfired in spectacular fashion cutting off my networking kit and preventing customer traffic from reaching our systems.

    From start to finish the incident lasted approximately 13mins but weeks on the repercussions can still be felt. I think its safe to say it wasn't my finest hour.

    I've had time to think on what happened and here I'm writing down my thoughts on what to do in the event that you make a mistake. From the outset can I say that mistakes happen. Whilst every effort should be made to avoid them through education, experience, process and peer support they can happen and how you/the enterprise manages an incident that occurs off the back of a mistake is important.

    In no particular order:
    DO NOT HIDE! - As soon as you realise that an error has occurred then shout! put your hand up, ask for help. As soon as the team is aware that something has happened then many hands can get stuck in figuring out what happend and how to fix it. The longer you sit there trying to hide the issue or simply panicking the longer the issue will take to resolve. Something broke, man-up, find out what it was and fix it.

    My next point is probably the most important thing that can be said:
    NEVER, EVER, EVER LIE! - Being honest and up front on what you did and how you did it is the quickest and easiest way to get to the bottom of the problem and resolve it. If you try to cover it up and make excuses, or out and out lie about what happened then you'll instantly loose the trust of your peers. It will add delay and confusion the incident and will take long to resolve in the long run.

    THERE IS NO PLACE FOR PRIDE - Yes it's embarassing that your actions have caused an visiable outage but you didn't do it maliciously (did you...?). Down the line you may end up being the butt of a few jokes for a few weeks but  in the here and now all that you/your team should care about is correcting the issue. This means being upfront and honest about what you did (see previous point) and the order you did it. Did you have 2 terminal sessions open at once and paste the command to the wrong window? Did you plan your change but accidentally list your sequence of events in an incorrect order? Provide as much information as possible and your colleagues will respect you for being open and honest.

    I guess how ready you feel you are to being open and honest depends on the culture at work. Management often confuse 'Low Risk' with 'No Risk' but being in an environment where you can put your hand up and admit mistakes is importnant. You learn from mistakes. Alright, you should endeavour to avoid them but sometimes thats the way your day pans out.

    If you work in an environment where you feel you can't admit a mistake however small then is that place for you? Failure to admit mistakes leads to blame, dishonesty, a fear of change, and can strangle innovation.

    Avoid them as much as you can but when a mistake does occur fix it and take it as a learning opportunity.


    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