L3/L2 Networks

Cisco 3750 – know your weapon

2012-02-02T18:36:00.000-05:00

from The Roving Network Engineer's blog.. by Dan Hughes

Cisco 3750 – know your weapon:
There’s been a lot of talk about reliability and performance issues on 3750 stacks recently. Usually complaining by me when one has let me down it has to be said.. Greg started a good conversation at http://etherealmind.com/zen-stackable-chassis-switches/ , but there have been many since. So I thought I’d pitch in, as I a love/hate relationship with stackable switches. Like many commentators, I see a terribly high failure rate (especially on the older 3750G range, which don’t seem to be aging well), but I think part of the problem comes from expectation, and that’s where I have to agree with Greg’s article.

It is what it is, don’t pretend it isn’t.

I used to work for a Cisco partner, and I remember having conversations with sales people/SE’s when handed a project that went along the lines of :

ME: Why are using  here? It's not going to give them the reliability they expect..
SE: The customer didn't want to pay for .
ME: That's fine, do they understand the choice they just made?
SE: mutter mutter cough cough

So a 3750 stack isn’t a chassis. It just isn’t. It’s not as reliable. You DO get issues with stack cables, and switches going split brained. I don’t believe the 3750 is different to any other brand here. If uptime is important to you, you don’t have to avoid stacks, just factor this into your design.

3750 Design factors

1) Two 3560 (or whatever) 24 port switches are more reliable than a 3750-24 stack. Why – well the KISS principal really. Quite simply, there are more things to go wrong in a stack – in both software and hardware. If there are more things to go wrong, it’s probably going to go wrong more often.

2) More complex failure scenarios A standalone switch will generally work or fail. If it fails, you swap it out. If you care about the devices plugged into it, you’ll put a second teamed interface into another switch, which will almost certainly keep running. If you’ve lots of devices, then lots of simple switches, well standardized, will give simple failure scenarios, limited blast radius, and easy restores. Stacks can be funny – one switch may show up as down, but when you remove it the whole stack reloads. I’ve replaced ‘down’ switches, only to find it’s the one which claims to be working which is actually faulty. These days, when I’ve a problem with one member I always swap the whole stack, and troubleshoot later. It get’s service back quicker.

2) Connecting your servers to 2 switches in a stack is NOT redundancy. Unfortunately with 3750 stacks, people think it’s perfectly reasonable to connect the two NICs of their servers into two halves of a stack. Yes, you have redundancy for a power failure, but that’s about all. If you need to do a code upgrade, or the stack becomes ‘split brained’, you lose the server.

3) Split brain? WTF? This is the term used to describe the scenario where a stack no longer thinks it a stack, but a number of separate switches. Often, in simple L2 deployments, it doesn’t matter too much, as the dataplane keeps working. If you’re doing anything remotely clever on the control plane (e.g. L3 routing, or any kind of security features) you’re in trouble. Also, if they become completely separated, then depending on your uplink design you could end up stopping devices talking to each other, or black holing inbound traffic. This is one of the most common problems I see on 3750 stacks in the wild – and it can actually be quite hard to spot without plenty of effort on your monitoring systems.

2) Performance – If I hear ‘well a stack has better performance for my busy server LAN than connecting switches together’ I’ll scream. It’s true in a way of course, a 32Gbs stack between two switches is better performing than a single (or multiple) 1gbs link. And it’s free. When you’re really that price conscious, I get it.

However, if you’re saying that your switch needs more than the 4x1Gbs uplinks that come on most of the gigabit models (which is 6:1 contention on a 24 port, or 12:1 on the 48 port gigabit models), you need to be looking at 10Gbs uplinks. There’s no point avoiding paying for 10Gb, having good performance in the stack, but still being stuck with 1Gbs out of the stack. It might do you for the moment, but the day will come soon enough when you have to replace the switches because the uplink isn’t up to it. Buying the 10Gbs models now and getting a good long life from them will be cheaper than buying 1Gbs models now, and 10Gbs models in a couple of years.

If you buy the 10Gbs models, you now have 20Gbs out of the switch (so that’s nearly 1:1 on a 24 port Gb switch, or 2.5:1 on a 48 port), which is really good contention. You are never going to be bandwidth limited in this design, even if you’re sending lots of traffic between devices on the LAN.

3) Stacks are not fabrics : the other performance point that people forget, is the 32Gbs ring is shared between all members. It is a ring – not a fabric. How it’s utilized depends on what is talking to what, so if you have more than 2 members you’re splitting your bandwidth up drastically, and in large stacks you can find very poor connectivity between certain members because the stack has certain busy talkers – it’s not even. Compare to a chassis switch, where even the 4500E has 24Gbs per line card to and from the supervisor. If a port on card 3 wants to send lots of traffic to a port on card 4, this is not affected by two other cards talking to each other. In the stack model, it depends what other traffic is going on the link between the two talkers.

Are stacks ever good?

Yes of course they are, as long as you understand the limitations. For example, as a cheap method of connecting lots of low bandwidth devices, that can tolerate the occasional failure, while simplifying configuration management, they’re great! If you need performance or reliability though, make sure you’ve planned for the failure scenarios!

Multiple DMVPNs on a Single Hub

2012-01-08T22:18:00.000-05:00

from PacketLife.net Blog by Jeremy Stretch

Multiple DMVPNs on a Single Hub:
I've touched on the fundamentals of DMVPN before, but today I'm going to expand upon my previous discussion and experiment with configuring multiple DMVPN clouds on a single pair of redundant headend routers. The scenario we'll use is that of a service provider offering DMVPN connectivity to two unrelated customers: Both customers need connectivity among their own sites and to the ISP, but must not be able to communicate with one another. Accordingly, each customer must use its own unique pre-shared key for authentication.

Our overall topology looks like this:

The 172.16.0.0/20 space represents public address space; in a real-world deployment, these would typically be effectively random public IP addresses.

The two ISP headend routers connect the four sites, two per customer, to the ISP network. Each headend router has two loopback interfaces (addressed out of 172.16.0.0/24) to which the DMVPN tunnels will be terminated. Per Cisco's DMVPN design guide, each customer will have two redundant DMVPN tunnels, one to each headend router. This adds up to a total of four DMVPN networks. Beware: this lab might get a little muddy, but I'll do my best to keep things clear.

Continue reading · 2 comments

The Configuration of DHCP Snooping

2011-12-28T11:32:00.001-05:00

from CCIE Blog by Anthony Sequeira

The Configuration of DHCP Snooping:
9 out of 10 network administrators agree – Rogue DHCP Servers suck! Stop them with this powerful, straightforward capability on Cisco Catalyst switches. This post assumes you understand the theory behind this security feature as taught in Cisco CCNP curriculums. Need a refresher – click right here.

Let us examine the configuration on a Cat 3560. First, enable the feature globally:

Cat4(config)#ip dhcp snooping

Next, configure the feature on the VLAN you are interested in protecting:

Cat2(config)#ip dhcp snooping vlan 10

In order to instruct the DHCP snooping feature that you have a legitimate DHCP server out of the Fa0/23 interface, mark the port as trusted:

Cat2(config)#int fa0/23
Cat2(config-if)#ip dhcp snooping trust

Verification? It could not be easier! How about:

Cat2#show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
10
DHCP snooping is operational on following VLANs:
10
DHCP snooping is configured on the following L3 Interfaces:
Insertion of option 82 is enabled
circuit-id format: vlan-mod-port
remote-id format: MAC
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Verification of giaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:
Interface                    Trusted     Rate limit (pps)
------------------------     -------     ----------------
FastEthernet0/23             yes         unlimited

Here we are ensuring that the feature is enabled, configured for the appropriate VLAN, and that the feature is operational on the correct VLAN. Finally, ensure the correct interface is trusted.

Are you called upon to do something outside the scope of this basic configuration in your lab exam? Well then it is time to hit the documentation on this feature. Follow this path to acquire it:

Cisco.com – Support – Switches – 3560 – Configuration Guides - Catalyst 3560 Software Configuration Guide, Release 12.2(58)SE – Configuring DHCP Features and IP Source Guard

Anthony Sequeira CCIE, CCSI

Twitter: @compsolv

Facebook: http://www.facebook.com/compsolv

Print Friendly

Common Approaches to Network Intrusion Prevention Systems

2011-12-22T12:00:00.000-05:00

by Anthony Sequeira

Common Approaches to Network Intrusion Prevention Systems:
As we gear up for a series by reader request on Network Intrusion Prevention Systems (IPS) here at blog.ipexpert.com, a great starting point is to examine the overall approaches to IPS devices that are used by network vendors today. We begin with the technological approaches that Cisco employs, and then we move outward from there in our list below.

- Signature-based – Cisco’s approach to Intrusion Prevention and Intrusion Detection Systems (IDS) is primarily a signature-based approach. They use this as the main technology in the IPS devices themselves, as well as the IOS-based IPS approaches within Cisco routers. Since this is the main approach used by Cisco and this is a Cisco-biased blog, we will dedicate the most amount of time to this approach.

Signatures are rules that describe a pattern of network traffic that is consistent with particular forms of security breaches and attacks. For example, Web servers might be attacked frequently by specially designed URLs that are sent against the server. A signature can be written that matches the particular attack in order to guard against it. Notice that in order to be effective, signatures examine both packet headers and packet payloads.

Notice that the signature-based approach to IPS has a relatively low false positive rate, even upon initial deployment prior to tuning. False positives refer to an alarm on the IPS being triggered when the actual traffic was benign and safe. The false positive rate is so low because you are relying upon the expertise of the engineers at Cisco that have designed the signature database. In fact, another huge advantage to the signature-based approach is the overall ease with which you can implement the security mechanism in your network.

Challenges to this approach include the fact that your IPS is only as good as it is updated. If you have not updated the signature database in over a year, you are vulnerable to the new attacks that have been created in the last 12 months.

- Anomaly-based – what is an anomaly? It is something that is outside the “norm”. This approach to IPS has the system alert us about network traffic that is outside the “normal” behavior that is typical to our environment. As you might guess, the big challenge with this approach is defining what is normal. I have struggled with this in my own personality for years!

IPS devices will typically try to accomplish anomaly-based approaches in two ways. Statistical anomaly detection (or network behavior analysis) seeks to observe traffic over a time period and build a statistical profile of “normal”. The protocol verification approach observes the network traffic and ensures that it matches known standards-based behaviors.

While this approach to IPS might seem very exciting because it could catch an attack that has not yet been defined in a signature, it does suffer in that it requires much administrator intervention and monitoring in order to interpret the many false positives that could result.

Cisco relies on this approach for things like worm prevention in their Network IPS devices.

- Policy-based - with a policy-based approach, a network administrator will configure an approved traffic policy and the device can alert or prevent traffic that is outside of that designed policy. For the most part, Cisco abandons this approach with its Network-based IPS devices as it would place a tremendous burden on the admins of the organization to design the correct policies. We certainly have our hands full with these types of considerations on the perimeter firewalls of the organization already.

- Honey Pot – with this approach, the IPS device is a trap! It is crafted to impersonate as many vulnerable network devices as possible and attract the attackers like a honey pot would to a swarm of bees. This allows the administrator to gain valuable information about the attackers, and to distract them against their ultimate targets. Cisco does not employ this approach in their IPS/IDS devices.

Now that we understand common approaches to Network Intrusion Prevention (and the particular technologies that Cisco is biased toward), we can examine Cisco Network IPS in greater detail in upcoming posts.

Anthony Sequeira CCIE, CCSI

Twitter: @compsolv

Facebook: http://www.facebook.com/compsolv

Print Friendly

Bidirectional Forwarding Detection (BFD) in the CCIE R&S Written

2011-12-04T10:47:00.000-05:00

Article by Anthony Sequeira...

Bidirectional Forwarding Detection (BFD) in the CCIE R&S Written:
Sometimes Cisco written exams can throw a bit of a curve ball at students when it comes to the questions that can creep into the overall pool of queries. One way in which this can happen is when Cisco asks about a technology or two that is not supported on the current equipment that Cisco is using in the practical lab exam for the same track. Currently we know that for the Version 4.0 of the CCIE R&S exam, Cisco features the following:

1841 series routers – IOS 12.4(T) – Advanced Enterprise Services

3825 series routers – IOS 12.4(T) – Advanced Enterprise Services

Catalyst 3560 Series switches running IOS version 12.2 – Advanced IP Services

Correctly so, students tend to study for the written exam against the backdrop of these Cisco devices and Operating Systems. That is a fine idea, but let us be sure to be ready for some features here and there there are not in the scope of our lab equipment.

In this post, I want to discuss Bidirectional Forwarding Detection (BFD) as this feature could very well find its way into a Cisco written exam on the subject of Routing and Switching. This technology is found on Cisco 6500/7600 series routers, as well as 12000 series and Carrier Routing System (CRS-1 Routers).

What is the point of this technology? Like so many protocols and techniques in modern Cisco networking, Bidirectional Forwarding Detection seeks to speed up routing protocol convergence. How does BFD seek to accomplish this? BFD focuses on the ultra-fast detection of node or link failures in the routing infrastructure.

What is the typical approach for the detection of a link or node failure? It is for some type of Hello or Keepalive mechanism to be used at Layer 3. In fact, we have seen these typical mechanisms attempt to evolve by permitting the use of sub-second intervals, as opposed to the long standing multi-second intervals that worked just fine in non mission critical data networks.

BFD operates in a similar fashion, except the fast link hellos are accomplished at Layer 2 instead of the traditional Layer 3. Why is this so exciting? It is not just the fact that there can be blindingly speedy detection of a failure, but also the fact that the CPU impact of the BFD process ends up being much less compared to other Layer 3 fast hello approaches. In testing accomplished by Cisco Systems, network devices running 100 concurrent BFD sessions experienced an increase in CPU utilization of a mere 2%.

For Bidirectional Forwarding Detection to operate correctly in your network environment, you obviously need to use the Cisco Feature Navigator (cisco.com/go/fn) and ensure that you are running the correct hardware and software version for full feature support. This feature does indeed require the cooperation of your Layer 3 protocols, and the great news is that Cisco implementations of EIGRP, IS-IS, and BGP, as well as such important support protocols like HSRP all support Bidirectional Forwarding Detection now.

Thanks for reading this blog post here at blog.ipexpert.com, and should you encounter this Cisco technology in your written, you are now MORE than ready for it! Continue to enjoy those studies!

Anthony Sequeira CCIE, CCSI

Twitter: @compsolv

Facebook: http://www.facebook.com/compsolv

Understanding LoopGuard for the CCIE Written Exam

2011-12-01T18:18:00.000-05:00

Article by Anthony Sequeira...

Understanding LoopGuard:
We know that a Layer 2 loop can be devastating to the network. The STP Toolkit feature of LoopGuard is there to help ensure this condition never occurs. How does it do this? It prevents a port from going to a forwarding state in the event of a loss of BPDUs received. The idea behind this feature is that we will sacrifice the ability of the network to “self heal” and converge around a failure to ensure that the network never incorrectly converges and creates a loop.

For example, in the event of a duplex mismatch, BPDUs might not show up on a port, even though there is intermittent connectivity that could still produce a loop. LoopGuard ensures the loop condition does not happen by placing a port that would have converged into forwarding into a loop inconsistent state. This is a blocking port state, and the admin is alerted via a system message. Should an admin correct the duplex mismatch and BPDUs be received properly – the loop inconsistent port state can be dynamically resolved.

Now a big point of issue here for the written exam is the LoopGuard feature and its “overlap” with another STP-related feature – Unidirectional Link Detection or UDLD. You see LoopGuard can indeed protect against a loop caused by a unidirectional link just as UDLD can. So how do you know when to recommend one over the other? Here is what you need to keep in mind…UDLD is better at catching unidirectional conditions on links as a result of miswiring, while LoopGuard is better at preventing links caused by an overall much wider variety of circumstances. For example, LoopGuard could prevent the loop as a result of the CPU being too busy to catch and process the BPDUs that are being received.

In the official Cisco documentation, Cisco points out some key differences between UDLD and LoopGuard that I want you to be aware of:

LoopGaurd works per VLAN; UDLD does not

UDLD cannot auto recover without taking advantage of the Error Disable Recovery feature

UDLD cannot catch loops from non-wiring issues

LoopGaurd is not as good at catching miswiring issues

In an upcoming blog post here, we will go into more detail for you on UDLD.

Anthony Sequeira CCIE, CCSI

Twitter: @compsolv

Facebook: http://www.facebook.com/compsolv

Gigamon and the Great Pumpkin

2011-11-03T17:29:00.000-04:00

from Router Jockey by Tony Mattke

Gigamon and the Great Pumpkin:

I could’ve just as easily called this article Gigamon… fixing problems you didn’t know about or Why Gigamon scares the crap out of me — but I wont, because they already did! But what I will say, is that Gigamon has become a very interesting product to me…

Gigamon’s product line-up mainly consists of optical fiber and electrical copper taps for network connections, and a series of aggregation taps with the capability to filter traffic being tapped and aggregated. Now, why do I find this interesting? Well, it all goes hand in hand with why your enterprise or ISP may be interested in their products…

Do you run an IDS? If you’re not, should you? I’m guess the answer to one of those is a resounding yes. Well, how are you going to get the data to your IDS? A hub? No, I didn’t think so. Well, how about a SPAN session? Oh, your span session is flaky, or it can’t monitor enough source interfaces? Maybe you just want to filter some of the traffic out. Well, now you need Gigamon’s help. Buy yourself a TAP and feed that into one of their VUE products where you can aggregate and filter the data down to your IDS. Say you want to make a second copy of that traffic, well guess what? You can do that too!

At the high end of the spectrum their GigaVUE-HD8 supports a massive 96 10Gb Ethernet ports with a whopping 1Tbps non-blocking backplane. You may of also noticed that this device is actually the name sake of this post… the Great Pumpkin. As impressive as this is, they also certainly offer smaller devices aimed towards the enterprise market like the GigaVUE-212 which still offers 8xGigE or SFP, 2x10Gb SFP+ ports, and you can add an additional 4xSFP ports via an expansion module..

If you’re still curious about how they work, or what they do, check out this great video on their Flow Mapping technology. It really shows just how powerful their system is and how well it would work in most any scenario you could come up with.

So why does Gigamon scare some people? Well, it may be their bright orange chasssis, or it could be the fact that our government has gone all big brother while trying to protect us from the crazies of the world… (not that I really blame them) It stands to reason with Gigamon’s own Gigamon Federal twitter account, you don’t have to wonder who some of their largest customers are. But honestly, you’re either going to be scared to death of them, or think that Gigamon is the greatest product that you never knew existed.

Tech Field Day Disclaimer

Gigamon was a sponsoring vendor for Network Field Day 2 and as such they my travel expenses were indirectly paid in part by them. They also gave me top notch swag… However, I was not paid to write about them, nor was I asked to give them special consideration. Any opinion expressed by me is mine and mine alone.

L2 or L3 switching in campus networks?

2011-10-31T17:30:00.001-04:00

Here's a blog post written by Ivan Pepelnjak which I found very interesting....

Michael sent me an interesting question:

I work in a rather large enterprise facing a campus network redesign. I am in favor of using a routed access for floor LANs, and make Ethernet segments rather small (L3 switching on access devices). My colleagues seem to like L2 switching to VSS (distribution layer for the floor LANs). OSPF is in use currently in the backbone as the sole routing protocol. So basically I need some additional pros and cons for VSS vs Routed Access. :-)

The follow-up questions confirmed he has L3-capable switches in the access layer connected with redundant links to a pair of Cat6500s:

What are the options?

There are two fundamental designs Michael could use:
Layer-3 switching (also known as routing) in the access layer. VLANs would be terminated at the access-layer switch (no user-to-switch redundancy, thus no HSRP), the links between access and distribution layer would be P2P L3 links (routed interfaces) and every single switch would participate in the OSPF routing.

Layer-2 switching (also known as bridging) in the access layer. VLANs would be terminated at the distribution layer; the access layer switches would run as pure bridges. Half of the uplinks would be blocked due to the spanning tree limitations, unless you aggregate them with multi-chassis link aggregation (MLAG), which requires VSS on the Cat6500. You would still run STP with MLAG to prevent forwarding loops due to configuration or wiring errors.

When you configure VSS on Cat6500s, they appear as a single IP device, so yet again you don’t need HSRP.

Which one is better?

Both designs have minor benefits and drawbacks. For example, L3 design is more complex and has larger OSPF areas, L2 design requires VSS on Cat6500. The major showstopper is usually the requirement for multiple security zones (for example, users in different departments or guest VLANs).
You might be lucky enough and satisfy the security requirements by installing packet filters in every access VLANs, but more often than not you have to implement path separation throughout the network – for example, the guest VLAN traffic should stay separated from internal traffic.
The proper L3 solution to path separation is full-blown MPLS/VPN with label-based forwarding in the L3 part of the network ... but HP seems to be the only vendor with MPLS/VPN support on low-end A-series switches.
Without MPLS/VPN you’re left with the Multi-VRF kludge (assuming your access layer switch support VRFs – not all do), where you have to create numerous P2P L3 interfaces (using VLANs) between access and core switches. Do I have to mention you have to run a separate copy of OSPF in each VRF instance?

Obviously the MultiVRF-based path separation doesn’t scale, so it might be easier to go with the L2 design: terminate VLANs on the Cat6500, where you can use centralized packet filters, VRFs and even MPLS/VPN if you need to retain the path separation across the network core.

Have I missed something?

What are your thoughts? Would you prefer L2 or L3 switching in access network? Do you believe in “route where you must, bridge where you can” or in “route as much as possible”? Write a comment!

Any relevant webinars?

Sure. Enterprise MPLS/VPN Deployment webinar (recording) describes the path separation challenges and the potential solutions – MultiVRF and MPLS/VPN with label-based forwarding. You’ll also learn about VRF-aware NAT and DHCP (just in case you need them in your network). And if you’re interested in a wider range of topics, you might find the yearly subscription cost effective.

And what are those crazy diagrams?

Greg Ferro has persuaded me that iPad-based drawing has a future. I bought a proper pen (doing it with your fingers will get you a kindergarten-grade results), Penultimate software (nothing to do with Penultimate Hop Popping) and started experimenting. Who know, I just might learn how to do good napkin drawings.

Cisco Live 2011 Here I come!!

2011-05-18T19:10:00.000-04:00

Where do I go from here?

2011-01-18T12:17:00.000-05:00

A comment I made in my previous post, there was nothing on the lab that looked foreign to me, brings me to the title of this post “Where do I go from here”? I feel very good, despite the fail, after taking the exam because I know I'm not too far from attaining those sought after digits (CCIE numbers).
My plan is to revisit all the core topics and make sure I attain an expert knowledge/understanding of the topics. As for the fringe topics like SNMP, NTP, EEM, etc... I also plan on revisiting with the intentions of getting a strong understanding.
The mentioned plans seems obvious but because of the lack of in-depth understanding of the topics I found myself wasting time trying to recall commands and also looking up commands on the doc site.
I am wasting no time in preparing for my next attempt, hopefully April or May, so it's back to the books!

D-day came and went...

2011-01-16T09:54:00.000-05:00

Well, I took the exam Friday the 14th, 2011 and I don't expect those digits on this go around. I knew going in that I wasn't feeling 100% but I did come out feel good about myself; there was nothing on the exam that I wasn't familiar with. What did get me was not being strong enough on the topics, in other words, I spent to much time trying to recall commands and lookups on the doc site. I know what I need to do and what I need to focus on, I'm thinking about go back sometime in April or May.

A comment on the overall lab: I've seen the video of the new format but that didn't prepare me for the initial several minutes of hell, I spent to much time trying to get used to the web format and managing all those damn windows on one screen.

Back to work!

Current status...

2010-10-24T09:19:00.000-04:00

I have not attempted the lab yet, why? I have taken a new position and I've been getting situated on that front;however, I have been studying diligently. I've been putting in at least four hours a night during the week and as much as I can fit in on the weekends.
I have scheduled and paid for the lab, January 14th 2011 is "D" day!
I'm currently focusing on speed, I want to be able to know the majority
of this stuff cold. I'm kind of weak on QoS so I'm working on that but
the core stuff like IGP's, EGP, Switching I feel pretty confident about.

Back to labbing...

Demo of The New CCIE Paperless Lab Format

2010-07-08T13:26:00.000-04:00

And here we are...July!

2010-07-01T16:27:00.000-04:00

So, am I ready to take on the lab?

Well up to this point I've been going through the first lab of the volume 2 workbook and I've really started to notice how much I've learned. I've been able to read through the tasks and point out the possible issues and solutions, very encouraging!
One the flip side, I've found that some of the technologies that I covered in the beginning I'm having trouble recalling. My solution to that is during the weekdays I will work in full labs (vol II) and weekends I will dedicate to revisiting individual technologies (vol I).

To answer the question above, though I feel comfortable, there are a few things I need to improve on speed being the main one and also my methodology to the lab itself. I will continue to work hard and barring any unforeseen issues/events, I'm planning to take the lab towards the end of the month...Let's see.

July is around the corner

2010-06-04T09:11:00.001-04:00

As I enter the first week of June I feel this sense of urgency. "Why," you ask? Well, July is the month I have targeted on my calendar to take the CCIE Routing & Switching exam. Though I've been studying for eleven months straight, not counting the nine months it took me to prepare for the written exam, I feel as I'm missing something. I often see questions like "How does one know when one is ready?" and the common answer I see is "when you pass the exam"....Gee thanks!

Taking a step back and looking at all the ground I have covered and the amount of knowledge I have gained makes me so much more excited and motivated to slay the dragon (CCIE Lab).
Currently I'm wrapping up the Security labs and at the same time going over IPv6 technology, at my current pace I should moving on to the volume II labs in the next week or so and also trying some mock labs to gauge myself.

It's time to hit the books and I will do my best to continue updating this journal chronicling my journey.

Debug output collection

2010-04-02T23:11:00.000-04:00

When you work with a remote rack by using an access-server (e.g. 25xx) with the async lines connected to the console ports of the pod’s routers, you effectively have only one terminal window opened. Using ctrl-Shift-6-x you can quickly switch between terminal lines; however, if you need to monitor “debug” command output on one terminal line, while performing some activity on the other you may face some difficulties.

For example, when you enable debug crypto isakmp on one router, and then switch to the other router, to generate packets with ping command, you may lose some of the debugging output, while switching back to the original router. Two obvious ways to resolve this issue exist: first one – open multiple terminal windows; next one – use logging buffered command to collect the debug logs into logging buffer. The third, not so well-known way to cope with the issue, is to use service telnet-zeroidle command on the access server.

What this command does, is announces TCP receive window with the value of zero for “idle” (currently non-active) connections. How does this work? When a TCP “server” is told that the other side’s TCP receive window is zero, the server starts buffering data to be send, until the other side “un-shrinks” the window again. Now, since all sessions from an access-server are effectively reverse-telnet connections to the access-server itself, by advertising TCP window value of zero, we make access-server buffer router’s console output (e.g. from debug commands), until the respective session becomes active again. In effect, with service telnet-zeroidle enabled, you may start, say, debug crypto isakmp on one router, switch to other, type ping x.x.x.x, then get back to the original router just to grab all the debug output at once – without any loss! Just make sure, your large debugging output runs fit into TCP xmit buffer, and don’t be scared by flood of output when you get back to an idle connection!

By INE Petr Lapukhov, CCIE #16379

TCL scripting tutorial

2010-04-02T22:01:00.001-04:00

MPLS Ping and Traceroute

2010-03-22T13:49:00.001-04:00

MPLS Ping and Traceroute

Posted using ShareThis

Some Favorite CCIE R/S Lab Verification Commands

2010-03-22T13:47:00.001-04:00

Some Favorite CCIE R/S Lab Verification Commands

Posted using ShareThis

I'm still in the trenches

2010-03-17T15:02:00.000-04:00

I know, I know...I haven't been keeping my promise; keeping this blog up to date on where I'm at with the studies. Well, currently I'm going through the INE Vol1 labs for MPLS. I've picked up very fast on this subject especially when I started to lab the scenario up. I should be done with MPLS in the next couple of days and then on to either IPv6 or security.
My lab date is still scheduled for the 2nd of July and I'm planning on sticking to it. I figure that at the rate that I'm going I should be done with all the vol1 labs by the end of April and begin vol2 which are full blown labs. I have a lot of work left to do!

This is AWESOME!!!

2010-03-05T21:07:00.003-05:00

Happy NEW YEARS!

2010-01-03T12:26:00.000-05:00

I know a bit late but Happy New Years! anyway...

This new year is going to be a great one, I can feel it in my bones, I'll have my CCIE number and I have a couple of other things (which I care not to mention) I want to accomplish in this new year.

As for the CCIE, I have just completed the BGP vol 1 labs and about to start the Multicasting vol 1 labs.
Which then leaves me with IPv6, QoS (this one is HUGE), Security, Systems Management, MPLS and finally IP Services. These remaining labs are pretty short with the exception noted above, the QoS section has roughly 80 tasks while the others average about 30 tasks.

I very excited, I'm learning and having fun doing it. I can not wait to hit the Vol 2 labs and get all these technologies tossed into a network jambalaya. For now I'm going to take a little break watch some football and start Multicasting this evening.....Laterz!

BGP Scan-time

2010-01-03T07:51:00.002-05:00

BGP monitors the next hop of installed routes to verify next-hop reachability and to select, install, and validate the BGP best path. By default, the BGP scanner is used to poll the RIB for this information every 60 seconds. During the 60 second time period between scan cycles, Interior Gateway Protocol (IGP) instability or other network failures can cause black holes and routing loops to temporarily form.

BGP scan process is also responsible for the checks to determine whether the conditional advertisement should or should not advertise the conditional route. It also checks whether route dampening information needs to be updated.

See: http://www.cisco.com/en/US/docs/ios/iproute/configuration/guide/irp_bgp_adv_features_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1056233
And: http://www.cisco.com/en/US/docs/ios/12_0t/12_0t7/feature/guide/VPN_EN.html#wp1045721

The History of the internet in a Nutshell

2009-11-16T17:21:00.001-05:00

Probably one of the first network diagrams...

Pretty cool article/time line of the creation of the internet...

Quick update.

2009-11-01T18:47:00.003-05:00

It's now November and I have to say I am happy with my progress. I'm hoping to take the lab sometime March or April, there is a whole lot of work to do.
At this point I'm half way through the OSPF Vol1 v5 labs. I'm pretty comfortable with OSPF, I've worked for several years in an OSPF only shop, and I have been able to move quickly through the tasks. I plan on finishing off OSPF tonight and moving onto everybody's favorite BGP!

Stay tuned...

Happy Halloween

2009-10-31T20:03:00.002-04:00

These guys from Internetwork Expert are hilarious...

Try JibJab Sendables® eCards today!

EIGRP Route Leaking

2009-10-12T11:10:00.000-04:00

Per the Cisco doc...

Configuring an EIGRP Summary Address to Leak a Component Route
There might be times when you have summarized routes, but you want a particular route to be advertised. The benefit of route leaking (advertising a route) is that the leaked route is more specific than a summarized route and is therefore the preferred route. Perform this task to leak an EIGRP route that would otherwise be suppressed by a summary route.

Behavior if EIGRP Route Leaking Is Configured Incompletely
The following default behavior occurs if the ip summary-address eigrp command is configured using the leak-map keyword and either the route map or access list is not configured:

•If the leak-map keyword is configured to reference a nonexistent route map, the configuration of this keyword has no effect. The summary address is advertised, but all component routes are suppressed.

•If the leak-map keyword is configured, but the access list does not exist or the route map does not reference the access list, the summary address and all component routes are sent.

Example:

Router B

interface serial 1
ip address 10.1.3.4 255.0.0.0
ip summary-address eigrp 3 10.1.2.0 255.255.254.0 leak-map LEAK-10-1-0
!
router eigrp 3
network 10.1.0.0 0.0.255.255
no auto-summary
!
access-list 2 permit 10.1.3.0 255.255.255.0
route-map LEAK-10-1-0 permit
match ip address 2

Router C
interface serial 1
ip address 10.1.3.5 255.0.0.0
ip summary-address eigrp 3 10.1.2.0 255.255.254.0
!
router eigrp 3
network 10.1.0.0 0.0.255.255
no auto-summary

I tested this feature and I've made a notes on other times where this might be useful during the lab, say during the lab a task is posed "Configure a summary route and also allow the component routes". One way to meet the requirement is to configure a leak map referencing a route map with no access list, this will allow the summary and the more specific routes.

Where have you been?

2009-10-01T17:45:00.000-04:00

Studying of course!

I'm glad to say I've been moving along, slowly but effectively with my studies.
The first challenge was trying to find my way through all the materials and come up with a study plan/strategy, which I'm glad to say I overcame and also got into a rhythm. I focus on a particular technology, say Switching, I watch all the class on demand videos and then do the labs. If at any point I feel "iffy" on something, I hit the Cisco doc site or the books on that topic.

I've completed the Internetwork Expert vol I v4.1 and v5 Bridging and Switching and Frame-Relay sections. The majority of the labs have been easy, some tasks I had to stop and look up the technology in the Cisco documentation site. I try to use the doc site as much as possible and the books as an alternate.

I'm currently going through the RIP v5 labs, having completed the v4.1 labs, and I'm almost done with those. The v5 labs are definitely challenging compared to the v4.1. I love the vol I labs because of their specific technology focus.

I've been averaging about six hours of study time and to be honest I don't even notice, being focused and all.

I should be done with the RIP stuff soon and then hello EIGRP....

Adios for now.

Route Table Profiling

2009-09-10T17:19:00.000-04:00

Very nice article written by Joe Harris, CCIE#6200, on a hidden gem - not so hidden anymore - A router command to enable the monitoring of route table fluctuations. Read on....Route Table Profiling.

Cisco's built in TDR

2009-09-05T10:14:00.000-04:00

Now this is cool!

While browsing a blog - which I frequently visit, PacketLife, - I came across a very intresting posting. On certain Cisco switch models (3560/3750, and some 4500 and 6500 modules) there is an embedded TDR on each interface. Check it out; Cisco's built in TDR.

INE

2009-08-27T15:21:00.001-04:00

INE’s New CCIE R&S v4.0 Topology

Posted using ShareThis

Some Favorite CCIE R/S Lab Verification Commands

2009-08-23T08:53:00.002-04:00

Some Favorite CCIE R/S Lab Verification Commands

What to expect on CCIE lab day.

2009-08-06T16:48:00.008-04:00

The honeymoon is over.

2009-07-31T11:48:00.003-04:00

I guess the honeymoon is over for me; I passed the CCIE R&S written exam on the 27th of July. Now it's back to working on the lab which I scheduled for the 11th of December.

I did promise my wife to lay off the books for two weeks, but hey! I'm off today and my wife is working. I'm home all alone, not exactly alone I have my four month old son with me and he's sleeping, and routers look so cold...I think I might just turn them on just to warm them up... :-)

AT&T 1993 "You Will" Ads

2009-07-28T17:10:00.004-04:00

Growing up watching these commercials had a definite impact in my career choice.

Using the New Microsoft Network Monitor (netmon) 3.3 with Network Experts

2009-07-27T18:30:00.003-04:00

Using the New Microsoft Network Monitor (netmon) 3.3 with Network Experts

This is pretty cool. I'll be trying it out on my home lab.

On to the lab!

2009-07-27T17:39:00.001-04:00

I passed the CCIE Routing and Switch (350-001) written exam, I got a 951 with 790 being the minimum passing score. I felt that the exam was somewhat easy, allot of the question were basic ones, ones that a CCNP should have no problems answering. I was expecting the questions to be more involved or tricky, though there were some tricky ones because of how the questions and answers were worded. I think I did better than I expected because I got flooded with OSPF question; OSPF is one of my strongest subjects with Multicasting being another.This exam was definitely easier than the old written exam I took back in 2006.

Well, as it is usually said...Now the real work begins!

Written exam has been scheduled!

2009-07-25T08:27:00.000-04:00

After nine months of studying, review, studying, and more review I am finally scheduled to take the CCIE R&S written exam on the 27th of July 2009. I'm continuing my review on certain topics I feel comfortable with but not 100%, for example Security, MPLS, and IPv6. I've been using the following books for my reviews.

At this moment I am finishing up Cisco Router Firewall Security written by Richard A. Deal, so far it's been an easy read.
The MPLS book I've read before, when I took the R&S written exam three years ago, I plan on just skimming through this one.
The same goes for the IPv6 book, I have not read it but I am familiar with it from my previous studies so I will be skimming this one also.

Back to the studies...

Good luck John

2009-07-20T09:21:00.002-04:00

I want to wish John good luck he is making his first, and hopefully his last, attempt at the Routing and Switching lab exam at RTP.
Take time to go over to his blog a wish him luck....http://ccieiecc.wordpress.com/

My home lab.

2009-07-09T15:39:00.003-04:00

I am still alive.

2009-07-09T15:38:00.000-04:00

I've pretty much have had my head stuck in a book for the past several weeks preparing for the CCIE R&S written exam. I'm nearing the last couple of topics I need to cover before registering for the exam; Multicasting, Security, MPLS, and IPv6.

I feel pretty good about my understanding of the topics covered on the current blueprint v3.1. I decided to go through the whole CCIE R&S exam certification guide and make sure I’ve covered all the bases; the last thing I want to do is blow $350.00 bucks because I missed something or because I was overly confident.

I purchased the Internetwork Expert CCIE R&S end to end materials and I’ve been mixing the reading with lab work. It definitely helps solidify the theory on how the protocols work.

I’m thinking of scheduling the written exam for the 31^st of July 9, 2009, by then I should have gone through all the topics and reviewed any topics I felt sketchy on….

We shall see.

Managing the VLAN.dat file

2009-01-24T09:49:00.002-05:00

I was reading this months edition of Cisco's Technical Services Newsletter and I came to an article about managing the VLAN.dat file which was pretty informative. The following are some notes that I took...

-VLAN or VTP configuration changes in CatOS are written to NVRAM immediately after a change is made. In contrast, Cisco IOS software does not save configuration changes to NVRAM unless you issue the copy run start command.

-VTP client and server systems require VTP updates from other VTP servers to be immediately saved in NVRAM without user intervention. The VTP update requirements are met by the default CatOS operation, but the Cisco IOS software update model requires an alternative update operation. For this, a VLAN database was introduced to Cisco IOS software for Catalyst switches as a method to immediately save VTP updates for VTP clients and servers. This VLAN database is in the form of a separate file in NVRAM called the vlan.dat file.

-During boot up, the switch compares the content in the vlan.dat file and the configuration in startup-config to determine if it should use the configuration in vlan.dat or startup-config. When you save VTP mode, domain name, and VLAN configurations in the switch startup configuration file and reboot the switch, the VTP and VLAN configurations are selected by these conditions:

If both the VLAN database and the configuration file show the VTP mode as transparent and the VTP domain names match, the VLAN database is ignored. The VTP and VLAN configurations in the startup configuration file are used. The VLAN database revision number remains unchanged in the VLAN database.
If the startup VTP mode is server mode, or the startup VTP mode or domain names do not match the VLAN database, VTP mode and VLAN configuration for the first 1005 VLANs are selected by VLAN database information, such as the vlan.dat file. VLANs greater than 1005 are configured from the switch configuration file.

-By default, the VLAN database file name is vlan.dat.

-You can use the vtp file <filename> command to rename the file. You cannot use the vtp file command to load a new database. You can use it only to rename the file in which the existing database is stored.

This example shows how to specify the IFS file system file where the VTP configuration is stored:

Switch(config)#vtp file vtpconfig

Setting device to store VLAN database at filename vtpconfig.
Switch(config)#

The vlan.dat stored in NVRAM alone can be accessed by the switch. The vlan.dat file can be copied from its location for backup purposes. The memory location name where the vlan.dat file is stored varies from device to device. Refer to the respective product documentation before you issue the copy command.

In Cisco Catalyst 6500/6000 series switches, it is const_nvram:. Similarily for Catalyst 4500/4000 switches, it is cat4000_flash:. In Cisco Catalyst 29xx series and Cisco Catalyst 35xx, 3750 series, it is referred to as flash:.

C6509-2#dir const_nvram:
Directory of const_nvram:/
1 -rwx 856 <no date> vlan.dat
129004 bytes total (128148 bytes free)

-If a saved vlan.dat is applied to a system that has already booted, the system must be reloaded before the newly applied vlan.dat configuration takes effect.

The True Hollywood Story of "PING"

2008-12-13T08:42:00.002-05:00

Below is an article created by Mike Muuss, the creator of the PING programe.

The Story of the PING Program

Yes, it's true! I'm the author of ping for UNIX. Ping is a little thousand-line hack that I wrote in an evening which practically everyone seems to know about. :-)
I named it after the sound that a sonar makes, inspired by the whole principle of echo-location. In college I'd done a lot of modeling of sonar and radar systems, so the "Cyberspace" analogy seemed very apt. It's exactly the same paradigm applied to a new problem domain: ping uses timed IP/ICMP ECHO_REQUEST and ECHO_REPLY packets to probe the "distance" to the target machine.
My original impetus for writing PING for 4.2a BSD UNIX came from an offhand remark in July 1983 by Dr. Dave Mills while we were attending a DARPA meeting in Norway, in which he described some work that he had done on his "Fuzzball" LSI-11 systems to measure path latency using timed ICMP Echo packets.
In December of 1983 I encountered some odd behavior of the IP network at BRL. Recalling Dr. Mills' comments, I quickly coded up the PING program, which revolved around opening an ICMP style SOCK_RAW AF_INET Berkeley-style socket(). The code compiled just fine, but it didn't work -- there was no kernel support for raw ICMP sockets! Incensed, I coded up the kernel support and had everything working well before sunrise. Not surprisingly, Chuck Kennedy (aka "Kermit") had found and fixed the network hardware before I was able to launch my very first "ping" packet. But I've used it a few times since then. *grin* If I'd known then that it would be my most famous accomplishment in life, I might have worked on it another day or two and added some more options.
The folks at Berkeley eagerly took back my kernel modifications and the PING source code, and it's been a standard part of Berkeley UNIX ever since. Since it's free, it has been ported to many systems since then, including Microsoft Windows95 and WindowsNT. You can identify it by the distinctive messages that it prints, which look like this:

PING vapor.arl.army.mil (128.63.240.80): 56 data bytes
64 bytes from 128.63.240.80: icmp_seq=0 time=16 ms
64 bytes from 128.63.240.80: icmp_seq=1 time=9 ms
64 bytes from 128.63.240.80: icmp_seq=2 time=9 ms
64 bytes from 128.63.240.80: icmp_seq=3 time=8 ms
64 bytes from 128.63.240.80: icmp_seq=4 time=8 ms
^C
----vapor.arl.army.mil PING Statistics----
5 packets transmitted, 5 packets received, 0% packet loss
round-trip (ms) min/avg/max = 8/10/16

In 1993, ten years after I wrote PING, the USENIX association presented me with a handsome scroll, pronouncing me a Joint recipient of The USENIX Association 1993 Lifetime Achievement Award presented to the Computer Systems Research Group, University of California at Berkeley 1979-1993. ``Presented to honor profound intellectual achievement and unparalleled service to our Community. At the behest of CSRG principals we hereby recognize the following individuals and organizations as CSRG participants, contributors and supporters.'' Wow!

From my point of view PING is not an acronym standing for Packet InterNet Grouper, it's a sonar analogy. However, I've heard second-hand that Dave Mills offered this expansion of the name, so perhaps we're both right. Sheesh, and I thought the government was bad about expanding acronyms! :-)
Phil Dykstra added ICMP Record Route support to PING, but in those early days few routers processed them, making this feature almost useless. The limitation on the number of hops that could be recorded in the IP header precluded this from measuring very long paths.
I was insanely jealous when Van Jacobson of LBL used my kernel ICMP support to write TRACEROUTE, by realizing that he could get ICMP Time-to-Live Exceeded messages when pinging by modulating the IP time to life (TTL) field. I wish I had thought of that! :-) Of course, the real traceroute uses UDP datagrams because routers aren't supposed to generate ICMP error messages for ICMP messages.
The best ping story I've ever heard was told to me at a USENIX conference, where a network administrator with an intermittent Ethernet had linked the ping program to his vocoder program, in essence writing:
ping goodhost sed -e 's/.*/ping/' vocoder
He wired the vocoder's output into his office stereo and turned up the volume as loud as he could stand. The computer sat there shouting "Ping, ping, ping..." once a second, and he wandered through the building wiggling Ethernet connectors until the sound stopped. And that's how he found the intermittent failure.

Sadly, Mike Muuss was killed in an automobile accident on November 20, 2000.His work lives on in testament to his intellect and indomitable spirit -- Lee A. Butler

The classic LAN Switching book

2008-11-14T16:13:00.002-05:00

I started to re-read the CCIE LAN switching book by Clark and Hamilton and I easily blew through the first seven chapters, I read this book several times before, It's such an easy read and very humorous (for a technical book).
The SpanningTree section is the real meat of this book it explains the theory with all its intricacies so intuitively, I really hope an updated version avail's itself sooner than later.

Battle of the CCIE trainers

2008-10-23T09:15:00.000-04:00

I have used Internetworkexpert for my study material in the past, they have an excellent support staff, their material is great, however, I have not tried IPexperts (yet) so I can not comment on their material.
Here is a link to an article posted on Brad Reese's Blog: http://www.networkworld.com/community/node/34276

So far so good

2008-10-19T23:45:00.001-04:00

TCIP/IP by Douglas Comer so far has been an interesting read; it starts out pretty basic talking about the birth of the ARPANET blah, blah, blah...But interesting.

I took a shot at the Boson practice test just to gage where I'm at as far as theory goes and I must say I am impressed with myself, I was able to remember allot. I do need to focus in QoS and security.

I'm kinda try'n to convince myself to just focus on what I need but I just feel safer going through all the material again and making sure I cover all the bases. I DO NOT want to retake this exam; I want to pass and move on to the real test!

Moving on

2008-10-18T07:04:00.003-04:00

I completed "Interconnection" by Radia Pearlman; the book was overall a good read, a very general and broad overview of networks and networking protocols. Pearlman describes the technology and proceeds to give her take on how it should have been done.

Now it’s on with “Internetworking with TCP/IP” by Douglas Comer. This book comes highly recommended by various sites, blogs and people I know to have read it. This book delves in detail about the ins and outs of TCP/IP and I’m looking to absorb as much as I can on this topic, since TCP/IP is what the internet and the whole world revolves around, although I’ve been working in the networking field for almost thirteen plus years and I know what to expect in the CCIE written exam, I’ve taken it before and passed, you can never go wrong with reading about this subject.

Once I restarted my CCIE studies I decided to take a different approach to achieving my goal “Modularize”; attack it by sections/levels. I first get the general “Open” view of the protocols first then get Cisco’s view on the subject. Then start from the bottom up, Ethernet technologies, level three stuff and so on.

I guess that’s enough for now, off to the books…

Another boring day at work...

2008-10-14T08:14:00.004-04:00

I'm at work thinking about how I want to get home and continue to study for written exam. It's mostly review since I took it once and also attempted the lab once. I'm almost done with "Interconnections" by Radia Pearlman, and then it will be TCP/IP by Comer.

I guess this job is not all bad, I love the schedule I work twelve hour shifts BUT...its three days on then two days off, then two on and then three off, the days don't seem long at all. I took the job due to unforeseen reasons but hey it's a job and with the current market... Before my current position I was on a large VoIP project, it was really fun I learned allot. I also held a design Engineer position with a large Carrier which I left for the VoIP project. I don't what to sound as if I can't hold a job, I just like learning new thing and If I'm in a position for to long, doing the same kind of thing I start getting bored, then it's time to move on.

So, I guess it's back to work now....

The coveted CCIE!

2008-10-02T11:58:00.004-04:00

Well, after a long hiatus I am back in pursuit of the CCIE certification R&S. I made my first attempt two years ago and I failed, I decided to take a "short" break, I was burnt out.
At this point I'm pretty much reviewing for the CCIE written exam.
I'm currently reading Radia Perlman's Interconnections sec. ed. The book is some what an easy read, she goes from the very basics and works her way up.
I am hoping to take the written by December and go straight into the lab preparation.
I will do my best to faithfully chronicle my journey.