Hi! ….just moved from Ohio to Cali, an awesome adventure but everything else is pretty much on hold for a little bit. Not trying to neglect this site/CCIE prep, but a new opportunity is going to take some serious focus for the time being. It’s cool though, it’s a pretty sweet opportunity/journey ahead. Can’t really dive into details but I’ll definitely come back to this project and the lab prep.
David.
This is an interesting read regarding the details of the brief global Internet outages that occured this past November: http://www.nanog.org/meetings/nanog54/presentations/Tuesday/Cowie.pdf.
Many network operators throughout the world troubleshot this, myself included, and while the effects were brief, it brings to light a bit more publicy just how vital the underlying infrastructure really is. Great work to all those who helped remedy the situation!
There have been a lot of things on the horizon these last few months, like wrapping up my second quarter at UC, overcoming a massive ASA migration project (I think we personally experienced every bug Cisco has w/ NAT!), and… a potential move.
Finals are next week, so as I write this I’m chilling at a local coffee shop (woot woot for Boston Stoker!), with my math text, stickered-up Macbook Pro, and one of two recently acquired books on Perl. I have my IE lab, for Route/Switch currently scheduled for the end of June, which means payment is coming due. On the horizon, there’s also a potential for moving cross-country to pursue an awesome job opportunity (an environment of intense network engineering, scale, and pace). While nothing’s definite yet, the excitement hasn’t waded a bit since first hearing of it nearly 6 weeks ago!
If things work out, I’d like to attempt the lab prior to the move, which means I’ve got some intense study ahead of me — perfect timing as my last class is Monday. I’m going to put the revised schedule here, to hold myself to it 
.
New target date: April 20th
Revised location: San Jose
Core focus areas:
o BGP (i vs e, regex, MED, confederations, dampening, reflection)
o Automation (TCL, EEM, Perl)
o Redistribution of BGP, OSPF, and ISIS
o JUNOS (BGP, OSPF, and ISIS w/ Cisco)
o IEEE 802.3 Spec (deep on the L2 things like flow control, etc)
o IPv4 (ICMP, TCP, UDP, and all related RFCs)
o IPv6 (I should know this inside/out)
o All things STP
o Next gen stuff like TRILL (FabricPath)/LISP/TrustSEC
o MPLS-TE
If you’re reading this as another potential IE candidate, yes – some of this is beyond scope! I’m creating my own blueprint of what I think an IE should know to properly hold their own against the designation.
After this, I think I’ll take a break from Cisco to go after some Juniper stuff! I passed my IE Security written, but it was pretty easy (ok, I might be a security nerd too!), so I think I’ll break from this to learn JUNOS more, work towards their mid-level cert, and then come back for the security lab next year.
Wish me luck!
david
I recently finished Dr. Stanley’s book “Stop Acting Rich and Live Like a Millionaire” and it was a very intriguing look at what he calls “the glittering rich”, “the aspirationals”, and “the millionaire next door”. The points brought up, with actual survey data to validate it, are very contrary to what one might think of when hearing the term “millionare”.
Dr. Stan made a very strong point that while there are a very select few who have so much excess money that they just blow it, most millionares are quite the opposite and live a lifestyle far under their incomes, and instead prefer to blend in like an average joe.
From a psychological standpoint, it brings to light a lot of interesting perspectives on individual personalities. He puts together a few common personalities and quite accurately describes their spending behavior and overall attitude.
Overall, I suggest that anyone with a slight interest in the topic to take a read. It’s not huge, in the ~250 page mark, and well worth the time.
INE’s Expanded R/S 4.x Blueprint, converted into an Word outline:
I found the original to be too cluttered to use as a check-list style outline of my progress, so I cleaned it up a bit and threw in a table of contents. Original Source: http://blog.internetworkexpert.com/2009/05/12/ccie-rs-4x-expanded-study-blueprint/
Interesting stuff — FPM provides the ability match on RegEx within the payload of a specified packet type. The example below matches the payload of the letter “A” within the payload of an ICMP Echo (PING) and then logs each occurrence.
Step 1: Load FPM definition files
load protocol system:fpm/phdf/ether.phdf
load protocol system:fpm/phdf/ip.phdf
load protocol system:fpm/phdf/icmp.phdf
load protocol system:fpm/phdf/tcp.phdf
load protocol system:fpm/phdf/udp.phdf
Step 2 — Create the first class-map of the protocol/payload RegEx
class-map type access-control match-all ICMPES
match field ICMP type eq 8
match start ICMP payload-start offset 0 size 256 regex “.*AAAA.*”
Step 3 — Create a second class-map to identify the packet header stack (ICMP within IP over Ethernet)
class-map type stack match-all ICMPINIP
stack-start l2-start
match field ETHER type eq 0×800 next IP
match field layer 2 IP protocol eq 1 next ICMP
Step 4 — Create a policy map to reference the first class and configure the corresponding log (or drop) action
policy-map type access-control ICMPES
class ICMPES
log
Step 5 — Create a second policy map to reference the second class and then nest the previous policy-map
policy-map type access-control STACK
class ICMPINIP
service-policy ICMPES
Step 6 — Apply the second policy map to an interface
interface FastEthernet0/0
service-policy type access-control input STACK
Testing — from another router,
issue ping 172.31.5.25 data 41
note: 41 == ASCI for “A”
Verification
then look at the log on the original:
*Mar 9 11:47:37.337: %SEC-6-IPACCESSLOGDP: list ICMPES permitted icmp 172.31.2.254 (FastEthernet0/0 ) -> 172.31.5.25 (8/0), 1 packet
I’ll admit I’ve been neglecting both this blog and my studies lately. I just wrapped up my first quarter at the University of Cincinnati and though I did well (B+ in College Algebra I!!!), it kicked my butt from a focus/time perspective.
Now that I’ve got a little time until the next quarter/class, I’m hitting up the lab prep again and skipped over to Lab 4. As I run through it, most things seem pretty straightforward but I’ve come across a few items that deserve being noted.
IPv6 on 3560s
– Beware! Regardless of code/feature set, these will appear as though IPv6 support is not present (missing commands/etc.). I went through several iterations of code changes before stumbling across this command “sdm prefer dual-ipv4-and-ipv6 default”, which must be issued and followed by a reboot prior to IPv6 commands being available.
IPv6 w/ OSPF over Hub/Spoke
– Another gotcha! If the spoke is using a point-to-point sub-interface and the hub is using just a single multi-point interface, be sure to verify the following items in an IPv6 OSPF configuration: matching IPv6 OSPF interface types (show ipv6 ospf interface) and appropriate Link-Local Frame-Relay mappings where necessary.
IPv6 Route Summarization
– I need to brush up on this…. I’m strongly familiar with most things IPv6, but arbitrary summarization is apparently a weak spot of mine. I eventually got the task correct but that was only after several trial/error attempts at variations on the prefix length.
Inbound route filtering for “just even subnets”
– Though I’ve seen this briefly at times in the past, its not something that comes back easily and I struggled here. The brief rundown is that a wildcard mask of “254.254.254.254″ with a subnet of 0.0.0.0 would match just the even subnets of all octets. A wildcard mask of 255.255.254.255 would match only subnets with an even third octet. Credit for this goes out to “http://routerjockey.com/2010/05/19/using-discontiguous-wildcard-masks-in-acls/” and “http://packetlife.net/blog/2008/sep/11/mask-comparison-subnet-versus-wildcard/”.
To anyone running a Juniper box, hopefully your environments are stable now. A few searches online, such as the NANOG list, will reveal a number of people affected by a bug in various versions of firmware on Juniper hardware that caused pegged CPUs this morning. From my perspective in North America, we felt the impact of this at about 9:15A EST (the issue impacted our transit providers and their providers).
David.
Bug ID:
View Bulletin PSN-2011-08-327
Title MX Series MPC crash in Ktree::createFourWayNode after BGP UPDATE
Products Affected This issue can affect any MX Series router with port concentrators based on the Trio chipset — such as the MPC or embedded into the MX80 — with active protocol-based route prefix additions/deletions occurring.
Platforms Affected
Security
JUNOS 11.x
MX-series
JUNOS 10.x
SIRT Security Advisory
SIRT Security Notice
Revision Number 1
Issue Date 2011-08-08
PSN Issue :
MPCs (Modular Port Concentrators) installed in an MX Series router may crash upon receipt of very specific and unlikely route prefix install/delete actions, such as a BGP routing update. The set of route prefix updates is non-deterministic and exceedingly unlikely to occur. Junos versions affected include 10.0, 10.1, 10.2, 10.3, 10.4 prior to 10.4R6, and 11.1 prior to 11.1R4. The trigger for the MPC crash was determined to be a valid BGP UPDATE received from a registered network service provider, although this one UPDATE was determined to not be solely responsible for the crashes. A complex sequence of preconditions is required to trigger this crash. Both IPv4 and IPv6 routing prefix updates can trigger this MPC crash.
There is no indication that this issue was triggered maliciously. Given the complexity of conditions required to trigger this issue, the probability of exploiting this defect is extremely low.
The assertions (crash) all occurred in the code used to store routing information, called Ktree, on the MPC. Due to the order and mix of adds and deletes to the tree, certain combinations of address adds and deletes can corrupt the data structures within the MPC, which in turn can cause this line card crash. The MPC recovers and returns to service quickly, and without operator intervention.
This issue only affects MX Series routers with port concentrators based on the Trio chipset, such as the MPC or embedded into the MX80. No other product or platform is vulnerable to this issue.
Solution:
The Ktree code has been updated and enhanced to ensure that combinations and permutations of routing updates will not corrupt the state of the line card. Extensive testing has been performed to validate an exceedingly large combination and permutation of route prefix additions and deletions.
All Junos OS software releases built on or after 2011-08-03 have fixed this specific issue. Releases containing the fix specifically include: 10.0S18, 10.4R6, 11.1R4, 11.2R1, and all subsequent releases (i.e. all releases built after 11.2R1).
This issue is being tracked as PR 610864. While this PR may not be viewable by customers, it can be used as a reference when discussing the issue with JTAC.
KB16765 – “In which releases are vulnerabilities fixed?” describes which release vulnerabilities are fixed as per our End of Engineering and End of Life support policies.
Workarounds
No known workaround exists for this issue.
For next study session on Lab 1, I’m jumping to my most difficult area — QoS.
Overall Steps:
- Configure a map-class for each DLCI, with “map-class frame-relay NAME”.
- Under the map-class, configure the FRTS parameters, such as “frame-relay traffic-shaping”, “frame-relay adaptive-shaping becn”, “frame-relay cir”, frame-relay mincir”, etc.
- Apply the map-class to the DLCI, under the interface, with “frame-relay interface-dlci NUMBER”, and then “class NAME”.
- Enable “frame-relay traffic-shaping” at the interface level if also enabled on the DLCI level.
- Show applied configuration with “show traffic-shape”.
Caveats:
When required to adjust the interval (Tc), the correct command for SHAPING is not “frame-relay tc”, but rather “frame-relay bc NUMBER”. The previous command is used only in POLICING [reference: http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/frtp_gsr.html]
To determine the numeric value for “Tc”:
First, calculate the number of intervals in a second by taking 1000 and dividing it by the desired Tc value. We are starting with 1000 here because this is in milliseconds, of which there are 1000 in any given second. So, if the desired Tc is 50ms, we would divide 1000 by 50, which gives us 20 [intervals in a second].Now, take the CIR value [the desired shaping-rate in bits per second], and divide it by the above number, [intervals in a second].
Under the map-class, configure this Tc value with “frame-relay bc VALUE”.
Issuing “show traffic-shape” should show the desired interval.
If given a requirement such as “allow for a burst of 1/4 of the policing rate”, the thing to remember here is that the amount specified will be in Bytes, not bits per second, so we have a little math to do.
If given a situation where we are asked to police at 128 kilobits per second, and we’d like to permit bursting above that for an additional 1/4 of that rate, here’s what we’d need to do:
First, determine the value in Bytes for the policing amount. So, for 128,000 bits per second [the same as 128 Kilobits/sec], we would divide that number by 8 (dividing by 8 converts from bits to Bytes), which results in 16,000 Bytes.
Now, we take the above result, 16,000 Bytes, and multiply it by the desired bursting value. So, the math for this would be 16,000(1/4), which results in 4,000 Bytes.
Finally, to provide a burst value of 1/4 of the initial policing rate, our burst amount would be set at 4,000 Bytes under the policy-map.
It has been a bit of a delay since I last worked on Lab 1, because just last week I started my first week of class, College Algebra, towards my Bachelor’s at the University of Cincinnati. I took the previous week or so to wrap up last-minute algebra review since it had been several years since my last math course. Now that I’ve got a handle on the scope of the course, I am returning to my CCIE lab prep.
So we continue, with Vol2, Lab 1. I last left off with having completed all redistribution activities, and I was somewhat shocked at the solutions to them. I had made significant use of route tagging and filtering based on those tags. I had tagged routes sent from EIGRP into OSPF as 100 for example, and on the redistribution of OSPF into EIGRP I had filtered at that point to prevent routes tagged as 100. On the opposite side, of routes going from OSPF to EIGRP, I tagged them with a value of 200. I did this, because during my first attempt at Lab 1, I remember carelessly redistributing without any filtering (such a dumb move!), and it caused massive loops/anomalies. The solutions presented were basically a compromise between these two extremes.
An easily overlooked item to remember, when routes are being advertised from an eBGP peer to an iBGP peer, is that by default, the next-hop address is unchanged. If that next hop, (the subnet of the physical circuit), is not directly advertised or redistributed, then traffic would not be able to reach the external prefixes. Solutions to correct: advertise/redistribute the connected subnet or add “next-hop-self” to the neighbor statement of the iBGP neighbors, for the router interfacing between the eBGP and iBGP sessions.
When configuring the Boot Strap Router (BSR) for IPv6 PIM, remember that IPv6 and IPv4 PIM statements are completely separate (“ships in the night”), and that if you are using Loopback0 as the source interface for the BSR messages for IPv4 PIM, it would need to have IPv6 reachability in order to participate in IPv6 PIM. Another “gotcha” is that ipv6 unicast-routing and ipv6 multicast-routing would need to be enabled to properly route IPv6 multicast (the RFP check would fail if there were no existing IPv6 routes).
I’m getting quicker at this one, just did all of the MPLS section on Lab 1 without any help/references — sweet!
Remember, when configuring MPLS VPNs, BGP is used to exchange routing information. So that tiny little requirement of “establish IP reachability for the subnets within the VRFs”, really means like a small chunk of BGP config on each side. In reality, it’s broken down into just a few steps, so don’t be fearful.
MPLS VPN Steps:
If not already in place, establish basic MPLS connectivity [mpls ip on the interfaces, mpls ip globally, etc.] Establish BGP connectivity between the nodes, not thinking about the VRF just yet. So R5 and R6 should show as established neighbors within the “show ip bgp summary” output. Create the VRFs [ip vrf NAME] Assign route-distinguishers to the VRFs [rd 100:5] Configure VRF export/import policy [route-target export 100:5 / route-target import 100:6]. This is referring to the above RD value. In Lab 1, we are exporting our own RD (100:5), but the opposing router is exporting routes as 100:6, so we import that one. Configure interfaces that are participating in the VRF [ip vrf forwarding VPN_A], and then configure the interface’s IP address (if an IP address was already configured, the interface’s VRF configuration just previously stated would cause the IP address to be removed). Within BGP, go into “vpnv4″ sub-configuration mode [under router bgp 100 > "address-family vpnv4"] Configure two settings per VRF neighbor, the “send-community both” and “activate”. In Lab 1 on Router 5, neighbor 150.1.6.6 activate / neighbor 150.1.6.6 send-community both. Configure advertisement of the routes within BGP by going into the VRF specific sub-configuration mode [under router bgp 100 > address-family ipv4 vrf VPN_A] Advertise routes like you normally would, anything here is specific to the VRF. In Lab 1, “redistribute connected” for example.
That’s all for now, will continue in the next study session.
David.
