I ended up with a 623, which given the little studying I did, makes me feel pretty good. Let’s just say that I really need to hit multicast pretty hard. So with the right amount of preparation, the written should be relatively simple..I hope.

I need to get back into the game here soon. The little one has somewhat of sleep schedule now, but it just doesn’t necessarily agree with my peak study times! (ie she’s awake around 4am — I’m still operating in zombie mode)

Reading through the success stories on ieoc.com has helped get my motivation going, now it’s just time to do something about it.

Let’s see what happens! I am looking forward to a fresh start again though in a few months. Mad props to all of you who manage to pull off the CCIE while working and having a family! Once we find out what life with a newborn is like, I will be able to get a better idea of the (realistic) amount of time I can devote per day to studying and go from there.

I’ve learned that from the few short weeks I’ve been studying, I need to devote more time to each topic to completely understand it and master it. I started off by creating a pretty rigorous study schedule and found that as time went by, I would rush to finish reading the material just in order to keep up with “my schedule.” I know that I need to have some sort of time line to actually pull this off, but it needs to be realistic and allow me to grasp the material and not just “read it” for the sake of reading it.

I also think that I’ll revert back to my original strategy of studying for the lab, and taking the written sometime during that time. I’ve found that the layer 2 material I studied using a combination lab/reading approach has stuck with me much more than the material that I’ve simply just read through, and not really labbed out.

So, with all of that said…I’m checking out for now. I’ll post my thoughts on the beta written sometime later this week, but aside from that, I’m out until further notice and in final countdown for arrival of Baby Smurf.

Good luck to everyone in their studies!

I think it’s more of the overwhelming amount of information one tries to absorb during this time, versus not enjoying the material. Sure, some of it’s pretty dry, but all in all, I still find most of it enjoyable. It just feels that even thought I’m making good progress (I think…), there’s so much more to absorb, remember, regurgitate, repeat, etc. This material has to become part of who you are, not just a collection of memorized facts stored away for future use.

I think that’s the part I have a hard time with…trying to determine which specific facts about the technology/protocol are important to remember permanently, versus which facts are needed, but easy to correlate with the task/question at hand during the written and lab exams. I know that I understand the concept and how a protocol works, but I worry about not remembering that one random fact.

The more I read about some of the OEQ horror stories, the more I become concerned. I can’t imagine putting in all this time, just to be shot down for 4 lousy questions. Sure, the concept of the OEQ is well-intentioned, but the results seem to be discouraging. I know there are people that still pass, but as time goes on, the OEQ’s weigh heavily on my mind.

I think part of the other issue is that the network I manage on a day to day basis is very small, and most of the CCIE topics are generally not something I can use/implement daily. I’m sure there are many out there in a similar situation, so how do you stay motivated? What gives you that extra kick to keep going? Coffee is having limited success for me at the moment….*sigh*

Friday and Saturday were my weak days, which both tie in to the lack of motivation. I managed to get back into the game on Sunday with a solid 4+ hours, but I would’ve liked to do more.  The past week has been dedicated to spanning tree, and all of its various incarnations. I forgot how much I liked studying spanning tree…or maybe I should say that I’ve come to like spanning tree more as time goes on. This coming week will be focused on VLANs and VTP, along with Etherchannel.

I’m going to try this week to see if I can get my company to cover the cost of ordering the INE CCIE 2.0 study package. The only thing I need to figure out is if they are going to have a CCIE R&S v4 package out soon. I want to dive in and get started, but don’t want to buy the v3 package if its going to be updated soon.

Anyhow, hopefully this week I can stay focused a bit more.  I think I’ve managed to get myself out of the funk that I was in, but we’ll see how the week plays out.

I’ve started using Google tasks to try and keep me on track. So far, I’ve broken down section 1.10 of the R&S v4.0 Written Exam Blueprint and I’ve got a full week scheduled (damn you spanning tree and all of your diabolical offspring). It’s painful to think that there’s 11 main topics to cover!

For those of you that are interested, I’ve started bookmarking sites that I will be using/reading in accordance with the lab topics and have tried to categorize them using the exam topic number (for example – 1.10 is spanning tree). You can view my list here: http://delicious.com/gerren.murphy

Does anyone have any good tips on keeping things straight during their exam prep?

Introduction to QoS

Converged Network Issues Related to QoS

• Acceptable end-to-end delay for VoIP packets ~ 150 to 200 ms
• 4 major challenges/concerns with converged networks
  • Available bandwidth
  • End-to-end delay
  • Delay variation (jitter) – difference in amount of delay
  • Packet loss – usually caused by sudden burst or failures
• Available bandwidth
  • Maximum bandwidth of a path is equal to the bw of the link with the lowest/smallest bw
  • Available bandwidth = MaxBW/Number of Flows
  • Possible remedies include:
    • Increase link bandwidth – not always beneficial for bursty traffic
    • Classify and mark traffic
    • Deploy queuing mechanisms
    • Use compression techniques
      • Link compression
      • TCP header compression
      • RTP header compression
• End-to-end delay
  • 4 types of end-to-end delay
    • Processing – the time it takes for a device to perform all tasks necessary to move packet from ingress interface to egress interface
    • Queuing – time that the packet spends in the output queue
    • Serialization – time it takes to put the bits of frame on the wire
    • Propagation – time it takes for the frame to cross the physical link
• Jitter/Delay Variation
  • For voice and video, packets must be released to the application in the correct order and same rate at which they were released at the source
  • De-jitter buffer compensates for the delay variation using the RTP time stamp on the packets
  • 5 ways of compensating for jitter
    • Increase link bandwidth
    • Prioritize delay-sensitive packets and forward important packets first
    • Re-prioritize packets – usually when a packet leaves a domain
    • L2 payload compression – reduces size of IP packet
    • Use header compression – cRTP – improves the overhead to payload ratio
• Packet Loss
  • Occurs when buffer space is exhausted (output queue) and device ends up dropping incoming packets
  • Interface resets may cause packet loss as well
  • Fragile flows – application flows that don’t use TCP and are more drop sensitive
  • Use show interface command to show interface counters
    • Output drop – number of packets dropped because the output queue was full (aka tail drop)
    • Input queue drop – CPU may be over utilized or input buffer is full
    • Ignore – total number of frames ignored due to lack of buffer space
    • Overrun – shows number of packets dropped when CPU is too busy to allocate buffer space to incoming packets
    • Frame Error – frames with CRC errors, runts, or giants
  • Methods for guarding against packet loss include
    • Increase link bandwidth – results in faster packet departures from interfaces
    • Increase buffer space – large buffer space allows better handling of bursty traffic
    • Provide guaranteed bandwidth – CBWFQ and LLQ can reserve bandwidth for specific traffic classes
    • Perform congestion avoidance – RED and WRED can drop packets before queue fills up
      • Packets can be dropped from specific flows whereas tail drop will drop all packets

Definition of QoS and Three Steps to Implementing It

“QoS is the ability of the network to provide better or special service to a set of users or applications (or both) to the detriment of other users, applications, or both”

• RTP priority queue ensures voice packets are given the right of way (protects voice from data)
• Strict priority queue (in LLQ) limits the bw of the priority queue (protects data from voice)
• Call admission control – prevents voice calls from saturating the link (prevents them from going beyond a specified limit)

Three steps to implement QoS

1. Identify traffic types and their requirements
2. Classify traffic based on the above requirements
3. Define policies for each traffic class

Step 1: Identify Traffic Types and Their Requirements

• Perform a network audit
  • Run audit during the busiest time of day but also at other times as well
• Perform a business audit and determine each application’s importance
  • Consider whether delaying or dropping packets of each application is acceptable
• Define appropriate service levels for each class of traffic

Step 2: Classifying Traffic Based on the Requirements Identified

• The defined classes must be in line with business objectives
• Traffic/applications in the same class must have common requirements
• VoIP traffic is usually given its own class
• Different classes as defined by many case studies include:
  • VoIP – delay and drop is to be minimized
    • Packet loss < 1%
    • End-to-end delay of 150ms
  • Mission-critical
    • Critical business applications
  • Signaling traffic
    • Usually its own class
    • Minimum bandwidth expectations
  • Transactional applications
    • Database driven apps
  • Best effort
    • All unidentified traffic
  • Scavenger
    • All traffic that is to be classified lower than best effort (p2p traffic for example)

Step 3: Defining Policies for Each Class

• Set a max bandwidth limit for each class
• Set a min bandwidth guarantee for each class
• Assign a relative priority level
• Apply congestion management, avoidance, and other QoS techniques to a class

Identifying and Comparing QoS Models

Best effort

• Pros
  • Easily scalable
  • Ease of implementation – none!
• Cons
  • Lack of service guarantee
  • Lack of service differentiation

Integrated Services Model (IntServ) [RFC 1633]

• Pros
  • Explicit end-to-end resource admission control
  • Per-request policy admission control
  • Signaling of dynamic port numbers
• Cons
  • Each flow has continuous signaling resulting in lots of overhead as the number of flows increased
  • Hard to scale because each flow is tracked and maintained
• Often called Hard QoS
• Based on explicit signaling and managing/reserving network resources
• Guarantees bandwidth, delay, and packet loss – predictable service level
• Uses RSVP (resource reservation protocol) – RSVP travels the network and requests bandwidth for the application flow
  • If RSVP succeeds, the application can begin operating
  • If RSVP fails the app cannot begin operating
• Mimics the PSTN model
• In addition to RSPV, enable the following:
  • Admission control – if resources cannot be made available, the application is denied
  • Classification – traffic belonging to an application that has made resource reservations must be classified and recognized by transit routers
  • Policing – measure and monitor applications to ensure they do not exceed resource usage above their profiles
  • Queuing
  • Scheduling – works in conjunction with queuing – this is the relative attention each queue gets if multiple queues are configured – referred to as the scheduling algorithm

Differentiated Services Model (DiffServ) [RFC 2474 2475]

• Pros
  • Highly scalable – able to handle 1000’s of flows
  • Flexible framework to define as many service levels as business demands dictate
• Cons
  • Does not provide an absolute guarantee of service
  • Somewhat complex to configure across many devices
• Based on a per-hop behavior – does not require signaling like IntServ
  • Each device in the network must be programmed to provide a specific level of service for each class of traffic
• Network traffic is classified
• QoS policies enforce differentiated treatment of defined classes
• Classes and policies are based on business requirements
• Often called Soft QoS

QoS Implementation Methods

Legacy command line

• Difficult to maintain consistency across many devices
• Error prone
• Does not completely separate classification from policy definition

Modular QoS CLI (MQC)

• Traffic classification and policy definition are done separately
  • Policies are defined after classes are defined
  • Different policies might reference the same classes
• Greater consistency across devices

Implementing QoS with MQC – 3 Major Steps

1. Define traffic using the class-map command (Case sensitive)
   1. Divides identified traffic into a number of named classes
2. Define QoS policies for traffic classes using policy-map (Case sensitive)
   1. Defines the treatment of defined classes from step 1
   2. Can define QoS policies for up to 256 traffic classes
3. Apply the policies in the inbound or outbound direction using the service-policy command
   1. Defines where the policies are applied


class-map MyVoipMap
match access-group 100


match-any vs. match-all

• In order to bind the packet to the class
  • Match-any – Only one access-list entry needs to be matched
  • Match-all – All entries in an access-list must be matched

policy-map MyPolicyMap ! defines a policy map
class MyVoipMap ! associates MyVoipMap (above) with this policy
priority 256 ! VOIP traffic has bandwidth guarantee of 256Kbps

int s0/0
service-policy output MyPolicyMap ! applies policy map defined above to this interface

AutoQoS

• Analyzes network traffic for as long as you let it run
• Generates traffic classes based on traffic it has processed (Auto QoS Discovery)
• Generates policy maps based on the classes it has defined
• Applies the appropriate policies to an interface
• Simplifies task of QoS configuration
• Prerequisites include:
  • Enable CEF
  • Enable NBAR
  • Verify that the correct bandwidth is configured on the interface

Related AutoQoS Commands

• auto qos voip - first generation of auto QoS – automated generation of QoS commands to get the device ready for voice over IP
• auto discovery qos – must be enabled for the router to discover and analyze network traffic entering the interface using NBAR
• auto qos – router builds class maps based on discovery and applies a policy map on the interface

SDM QoS Wizard

Step 1: Click Configure
Step 2: Click Quality of Service
Step 3: Click Create QoS Policy
Step 4: Click Launch QoS Wizard

Introduction to VoIP Networks

Benefits of Packet Telephony

• More efficient bandwidth usage
• Lower transmission and network costs/expenses
• Improved productivity
• Access to new communication devices

Packet Telephony Components

• Phones
• Gateways – Interconnect with other gateways and allow communication between devices that may not be accessible from the IP network. Also responsible for connecting PBX’s to IP networks
• Multipoint Control Units (MCU) – conference calling device that combines the streams from participants and returns the result to each participant
• Application & Database Servers
• Gatekeepers – these provide call routing and call admission control (CAC) services. Call routing resolves a name or number to an IP address. CAC grants permission for a call setup
• Call Agents – handles call routing, address translation, and call setup
• Video End Points
• Digital Signal Processors – convert analog signals to digital signals using different codes

Analog Interfaces

• FXS (Foreign Exchange Station) – Meant for analog phones, fax machines, and modems. To these devices, the gateway acts like the PSTN CO switch
• FXO (Foreign Exchange Office) – Connects to a regular phone jack to be connected to the PSTN
• E&M – Ear and Mouth (or Earth and Magento) – Generally provide PBX to  PBX analog trunk connectivity

Digital Interfaces

• Provides connection to PSTN CO and PBX switches
  • BRI or T1/E1 interface
• BRI and PRI Interfaces use command channel signaling (CCS) – uses a dedicated D (Delta) channel for signaling
• T1’s can be configured to use CAS – does not use a dedicated D channel (aka “robbed bit signaling” because each CAS channel gives up a few bits to perform signaling)

Stages of a Phone Call

• Three most popular VoIP signaling protocols are:
  • H.323 – ITU standard
  • Media Gateway Control Protocol (MGCP) – IETF standard
  • Session Initiation Protocol (SIP) – IETF standard
• Three stages of a phone call
  • Call setup
  • Call maintenance
  • Call teardown
• Call Setup
  • Destination telephone number must be resolved to an IP address
    • Call request must be sent to this IP
    • Called “call routing”
  • Call admission control (CAC) – determines if enough bandwidth is available
    • If not enough bandwidth, CAC sends message to initiator advising of insufficient resources (fast busy signal)
  • If call routing and CAC succeed, a call request is sent towards destination IP
  • If call is accepted, the following parameters are negotiated:
    • Source and destination IP addresses to be used for the call
    • Source and destination UDP ports that the RTP uses
    • Compression algorithm
• Call Maintenance
  • Collects statistics such as packets exchange, packets lost, delay, and jitter
  • End points can analyze this data and can provide call quality info upon request or they can send it to another device for analysis
• Call Teardown
  • After an end point terminates the call, the call teardown process sends the appropriate notifications to all involved devices to free up resources

Distributed vs. Centralized Call Control

• Distributed Model
  • Multiple devices are involved in setup, maintenance, and teardown, and other aspects of call control
  • H.323 and SIP are considered distributed call control protocols
• Centralized Model
  • Relieves the gateways and endpoints for being responsible for call control tasks
  • MGCP end points not intelligent enough to perform call control tasks and must rely on a CA (call agent)
  • Analog voice digitization, encapsulation into IP, and transport still handled by DSP of the MGCP gateways and end points (basically, the phones and routers handle the “IP” part in “VoIP” – the CA handles the call control)
  • If call is terminated, the CA is notified and advises endpoints to release their resources
  • End points can monitor call quality and notify the CA if quality is unacceptable

Digitizing and Packetizing Voice

Basic Voice Encoding: Converting Analog to Digital

• Four Major Steps
  • Sampling – the periodic capture and recording of voice
    • Result of sampling is called pulse amplitude modulation (PAM) signal
  • Quantization – the process of assigning numeric values to the amplitude of each sample on the PAM signal
  • Encoding – process of representing the quantization result for each PAM in binary
  • Compression (Optional) – reduces the number of bits that must be transmitted per second with the least possible amount of voice quality degradation (always less than 64Kbps)

• Converting Digital Back to Analog
  • Decompression
  • Decoding and filtering
  • Reconstructing analog signal

The Nyquist Theorem

• A signal that is sampled at least 2x the highest frequency of that signal yields enough samples for accurate reconstruction of the signal at the receiving end

Quantization

• The process of assigning numeric values to the amplitude of each of the samples on the PAM signal
• Quantization error (Quantization Noise)– The difference due to “rounding” between the original signal and the signal received at the far end

Compression Bandwidth Requirements and Their Comparative Qualities

• Several ITU compression standards exist and differ based on the following:
  • Bandwidth requirements
  • Quality degradation they cause
  • Delay they introduce
  • CPU overheard due to complexity
• ITU standard for measuring quality of voice codecs is mean opinion score (MOS)
  • Range from 1 (worst) to 5 (best) (subjective)

Digital Signal Processors

• Provide 3 Major Services
  • Voice termination
  • Transcoding – (when 2 parties use different codecs, the DSP converts one codec into the other)
  • Conferencing
    • If all parties use same codec, it’s called a single-mode conference
    • If parties use different codes, it’s called mixed-mode conference
      • The DSP must perform transcoding in this case

Encapsulating Voice Packets

Real-time Transport Protocol

• Uses RTP (real-time transport protocol)
  • Runs over UDP on ports 16,384 to 32,767
  • Adds timestamps to the packets at the source, so that they can be replayed at the same rate as when it left the source
  • Also uses sequence numbers, reordering, and reassembly
• VoIP Packets have the following headers
  • IP @ 20 bytes
  • UDP @ 8 bytes
  • RTP @ 12 bytes
  • Total: 40 bytes (of headers alone)
• DSP usually puts10ms of voice in one package, and puts 2 packages in an IP packet
• Resulting packet size depends on the codec used

Reducing Header Overhead

• Compressed RTP (cRTP) aka RTP Header Compression
• cRTP must be applied on both sides of a link
• Sender and receive agree on a hash value for the 40 bytes of header data and only send the hash value once computed
• If cRTP doesn’t account for the header checksum (UDP checksum) the headers are reduce to 2 bytes
  • If it considers the UDP checksum, the headers are reduce to 4 bytes
• cRTP recommend for slow links only (less than 2Mb bandwidth) – and only if performed in hardware
• cRTP adds delay due to extra calculations needed

Bandwidth Calculations

Consider the following in addition to the codec used

• Packet rate and packetization size
  • Packet rate in packets per second (pps) – inversely proportionate to packetization size
  • Packetization size – amount of voice in each IP packet (Number of 10ms samples)
• IP, UDP, RTP header overhead
• Layer 2 overhead
• Tunneling protocol overhead (GRE, IPSec, L2TP, etc.)

ITU Codec Standards

• G.711 is PCM (pulse code modulation)
  • 8000 samples per second
  • 8 bits per sample
  • 64,000 bits per second (64Kbps)
  • No compression
• G.726 – Adaptive Differential Pulse Code Modulation
  • Sends fewer bits per sample (instead of 8 per sample)
  • Bits describe the change from previous sample
  • 4 bits sent is G.726 r32 (32Kbps)
  • 3 bits sent is G.726 r24 (24Kbps)
  • 2 bits sent is G.726 r16 (16Kbps)
• G.722 – Wideband Speech Encoding Standard
  • Divides signal into 2 sub-bands
  • Encodes each sub-band using a modified ADPCM
  • Bit rates of 64Kbps, 56Kbps, or 48Kbps
• G.727 – Low Delay Exited Linear Prediction
  • Wave shapes of five samples are expressed with 10 bit codes
  • 16Kbps
• G.729 – Conjugate Structure Algebraic Code Exited Linear Prediction
  • Similar to G.727 but uses 10 samples
  • 8Kbps

Data Link Overhead (L2)

• Each L2 technology adds overhead to the overall packet
  • Ethernet – 18 bytes
  • Frame Relay – 6 bytes
  • Multilink PPP – 6 bytes
  • Dot1Q – 22 bytes
• L2 overhead must be considered when calculating total bandwidth for a VoIP call

Security and Tunneling Overhead

• IPSec in tunnel mode adds another 20 byte header
  • Original IP packet is encrypted within another IP packet
• IPSec also adds additional delay due to time taken to decrypt packets
• Must also consider other tunneling protocols for BW calculation

Six Major Steps for Calculating the Total Bandwidth for a VoIP Call

1. Determine the codec and packetization period
2. Determine the link-specific information
   • Is cRTP being used
   • Type of L2 encapsulation
   • Security or tunneling protocols in use
3. Calculate the packetization size (size of the voice payload)
   • (Codec bw in bits x Packetization Period in seconds) / 8 = size of voice payload in bytes)
     • NOTE: Packetization period usually given in ms – must divide by 1000 to arrive at seconds
4. Calculate the total frame size
   • Consider all overhead involved (L2, security, tunneling, etc.)
5. Calculate the packet rate
   • Packet rate = 1 / Packetization period in seconds
6. Calculate total bandwidth
   • Multiply frame size from step 4 (in bits) x packet rate from step 5 = total bandwidth
   • Example: Frame size of 66 bytes x 50 pps = 528 bits x 50 = 26,400 bits or 26.4Kbps

• VAD – saves bandwidth by detecting silence and 1 way audio (Such as music on hold – data only flows in 1 direction)
  • Dependent on:
    • Type of audio
    • Background noise level
    • Other factors such as differences in language and culture
  • Can save up to 35% of bandwidth
  • Heavily depended on above factors – most bw estimates don’t take VAD into consideration

Implementing VoIP Support in an Enterprise Network

Main components consist of:

• Gateway – provide connectivity between analog, digital, and IP devices
• Gatekeeper – H.323 device that provides call routing or CAC
• CUCM – acts as IP PBX
• IP Phones

SRST – survivable remote site telephony

• If WAN or other link to call manager goes down, an SRST enabled device can route those calls over the PSTN
• Provides intra-office calling, hold, and transfer

Cisco Unified Call Manager Functions

• Cisco Call Manager  is call processing software and is the main component of CUCM
  • Supports MGCP, H.323, SIP, and SCCP IP signaling
• Provides the following services
  • Call processing
  • Dial plan administration
  • Signaling and device control
  • Phone feature administration
  • Directory and XML services
  • Programming interface to external applications

Deployment Models

• Single site
• Multisite with centralized call processing
  • CUCM placed at main site
  • All IP devices are under control of CUCM at main site
  • DSP resources can be distributed
  • Signaling and call control go through main site, but intra-site calls stay local (the actual voice traffic)
  • Each site has PSTN connection
  • CAC can deny calls if WAN link is saturated
    • Can reroute those calls through PSTN if needed
• If WAN is down, SRST can reroute calls over PSTN
• Multisite with distributed call processing
  • Each site has its own CUCM
  • All intrasite traffic including call control stays at local site
• Clustering over WAN
  • Servers in a cluster dispersed throughout various sites
  • Servers need to communicate over the WAN for database synch and replication
  • Maximum RTT between sites must be < 40ms

Identifying Voice Commands in IOS Configurations

• Terminology:
  • Dial peer: IOS configuration that links/binds a telephone number to a local POTS interface (FXS) or a remote IP
    • One POTS dial peer and one VoIP dial peer exist

Example (R1 and R2 are connected over an IP network)

R1 Configuration
Dial-peer voice 1 pots ! configure dial-peer 1 as POTS
destination-pattern 11 ! set the dial pattern
port 1/1/1 ! device is on port 1/1/1 (FXS)

Dial-peer voice 2 voip
destination-pattern 22
session target ipv4: 192.168.2.2

R2 Configuration
Dial-peer voice 1 pots
destination-pattern 22
port 2/0/0

Dial-peer voice 2 voip
destination-pattern 11
session target ipv4: 192.168.1.1

Call Admission Control (CAC)

• Limits the number of concurrent calls
• Compliments QoS configurations
• Prevents oversubscription of the WAN by VoIP calls

Stay tuned…

I think that I get caught in up in the people that are posting that they “Got 1000/1000″ — I suppose that there are folks out there that can ace these tests without much effort, but I’ guessing that a lot of people I see posting these kind of messages are brain-dumpers. No disrespect to anyone who has aced a Cisco exam without using dumps of course.

I supposes that I should be proud that I can pass without using dumps, but I would still like to improve my score next tie. Ahhh…oh well, who cares! 3 test down and only ONT to go for my CCNP.

I’ve had that happen twice now, and I’m not sure what the issue is. So, I’m scheduled to take the ISCW tomorrow, and feel very confident on for this exam, but the anxiety of getting there and realizing a few minutes into it that I’m not as ready as I thought, is always frustrating. Very, very frustrating.

Does this happen to anyone else, or is it just me? I know my weak points are as follows:

• PPPoA/E configuration commands
• Some of the IPSec smaller details
• Some parts of AAA, but I’m not sure what!?!

So, I’ll be running through those questions/topics again tonight, and then tomorrow at 1000 is judgement day. If I pass this, it will be 3 down and ONT to go!