iamjeffvader's studymotron and rantatorium

I’m giving up the consultants life and starting a real job next week in Riot Games.  In the meantime I’ll be working on the JNCIE and will link to any videos I do.  Most likely here.  https://www.youtube.com/channel/UCYokd2B0yiDopbAZn_0Vz4g

I have written a study guide entitled “Network Routing Specialist 1 – A Beefed-Up Self Study Guide” which covers the NRS1 track but digs deeper in to protocol function to a level that you might expect to see in the NRS2. Inside you will find chapters covering the 7×50 and 7210 hardware, tips and tricks on navigating the CLI, end of chapter quizzes and a lab covering IGP, MPLS, BGP and services.

The ebook is almost 700 pages long and technical content review was provided by Darren O’Connor and Davide Barbaro.

If you are interested please check out my business site https://snu.training/books.html

The book is now priced at $29 and is available in pdf or epub format.

I took the SRA lab a couple of weeks ago and got my result late last week (a pass).  Unlike the CCIE there isn’t really any information about going for the SRA in terms of logistics so here you go, here is how I got to Antwerp and how I got on.

I flew in to Zaventem from Dublin (with Aer Lingus).  Ryanair also fly to Charleroi (never going through that nightmare again) and Cityjet fly direct from Dublin to Antwerp.  I elected to go with Aer Lingus as the timing worked out better.   The lab is from 8:30  to 5ish.  From Brussels airport I took the De Decker coach to Antwerp Central Station (Queen Astrid Square I think).  It cost 10 eurodollars, an absolute bargain.  The bus departs on the hour from Zaventem and takes around 45 minutes to Antwerp.  If you have been to Diegem then you know where the bus to the Cisco hotels go from.  This one is in the same area, on the far left with blue paint on the ground at the stop. Here’s a fancy link .

If you have never been to Belgium before and are a native english speaker then you will find most people have an excellent level of fluency, seems par for the course in Benelux.  I speak French but was advised against doing so in Flanders.

After the short bus trip I got to central Antwerp at around 11am the day before my exam.  Once you get off the bus there is a fabulous looking central station.  ALU are about 10 mins walk from here.  Go in to the station and keep walking past all the diamond shops until you get to the end of the station. Turn left out the glass doors and ALU are just to the left of the station.

I stayed in the Linder hotel, there is also an Ibis within 1 minute walk from ALU.  It was about 180 euro for the night with breakfast and dinner, they have a sky bar where I had some coffee and tried to do some labs.  Some poor soul was doing his soundcheck for thats nights performance so it was loud and he was rubbish, lucky I brought my headphones.  I walked the 1 minute round to ALU just to make sure the reception area was where I was due to go in the morning.  I then had some nice organic fruit and pastries in a cafe type thing beside the hotel.  Le Petit Dejeuner I think it was called (obviously no one told them speaking French in Flanders was uncool, or maybe the joke was on me), staff were really nice and the food was good.   After that I went back to my room and had a nap. A bloody nap!  Who does that?  I have sleep apnoea so I like to snooze whenever I can.  I got up after a few hours and had dinner in the hotel, fine, reasonable quality then I went to sleep for super serial around 8pm.  Big mistake, I was up at midnight til around 4am, dozed off until my alarm went off at 5:30.  Breakfast wasn’t until 7 but I wanted to do some scenarios beforehand, couldn’t focus though.

Unlike when I sat the CCIE I wasn’t worried at all for this one, in fact I was expecting to fail as I didn’t prepare, and I had budget for a second attempt if required.  Because there is so little information on the SRA I thought a recce attempt would be a worthwhile investment.

At 8:10 I went round to ALU and was there around 8:11 🙂 and waited in reception for my proctor.  Like my NRS2 attempt my proctor was cool, explained the rules etc and off I went.

I had an initial read of the paper (which I didn’t do for my CCIE) and checked out all the diagrams.  I redrew them out on the paper the proctor provided me with, working pens too! Take note Cisco! All the SROS config guides were available in a folder on screen, I consulted them a few times, again I hadn’t really prepared.   You know all the ALU courses and study guides, they have 6 routers in them.   I use a network of 14 lab routers in the day job which was fine.

Now here is where I can’t really say any more detail.  I will say this, I would consider the exam somewhat on par with the NRS2 but with more complicated subject matter.  I found it relatively straightforward, finishing well within the allotted time and taking it easy at that.  I left after 6 hours having rechecked a couple of times.  I find some questions ambiguous in most exams, must be very hard for non native English speakers.  I made the decision on how to proceed based on what I felt was more logical in an exam environment.  For example if you need to change a service parameter that is tied to a physical element, don’t change the physical element, accommodate that restriction in your solution.  These exams are there to make you think right?  Not just go for the easy option.  Whether I was right or wrong I don’t know but I did enough to pass.

After the exam I went back to the same bus stop and waited for the bus.  In the lashing rain. For 45 minutes.  The bus was 10 euro back and even though this was around 4pm and traffic was awful our route seemed to go against all the traffic.  Always a plus.  Compulsory purchase of the Belgian chocolates for the family and off home.

I haven’t completed the SRA yet, I still have my elective written exam to complete, which is a weird kind of limbo to be in.

Jerry Springers final thought:  If you prepare with the ALU scenarios then there is no reason you shouldn’t pass this exam.  If I give the CCIE SP a 7-8/10 in terms of difficulty then this one would be a 4-5/10.  Maybe it was easier cos I had already done the CCIE, I don’t know.  It’s certainly not the hardest exam I’ve ever sat.  If you know what you are doing in theory and in practice, and not just learning by rote, then you should pass no problem.

SAVE YOUR CONFIGS OFTEN!!  These are sims so they can break.

I have been with my current employer for almost 15 years, that’s pretty much my entire adult life.  Turns out passing the CCIE opens a lot of doors so I resigned and I am off to try out the world of contracting.

How does that impact on my blog?  Well as sporadic as my entries might be I do enjoy writing and plan on keeping going.  I’ve committed to passing the SRA within the next 6 months at most so I will be posting more relevant stuff to that.  I won’t have access to a lab 24/7 and will have to buy time off mysrlab which seems very expensive but what can you do.  The sooner ALU release their vsim the better (around 12.0r4 apparently).

Anyway watch this space as I prepare for the NRS2 lab, complete the remaining 3 writtens for the SRA and then finally the SRA lab itself.

I’ve been feeling somewhat lethargic since passing my CCIE.  I think it’s actually some sort of trauma, going from 100 in a 50 zone to a dead stop and just lying on the pavement in the rain.  I am really struggling with motivation to do anything really outside of work so it’s time to throw off the shackles of post-CCIE depression and get back to doing something interesting. I’m going to be doing some stuff with multicast on the 7750s so this is the first post on it. I haven’t had time to actually do anything of much substance in the lab on it yet so I just knocked up a quick bit of PIM to highlight how easy it is to get basics up and running. It’s not very interesting but it’s a start. I plan to get in to Rosen and mLDP stuff in the future and do a post on inter AS VPN between SROS and XR, maybe Junos if it treats me nice.

First the topology: R3 and R4 will be PIM neighbours with R4 being our RP.

OK let’s get PIM working:

R4
config router pim
interface system
exit
interface to_R3_1/1/2
exit

R3
config router pim
interface system
exit
interface to_R4_1/1/2
exit

Don’t forget your CPM filters will need to allow PIM through. The above was done on an SR1 which doesn’t support them but they would look something like this:

configure system security cpm-filter ip-filter entry 100
match protocol "pim"
action accept


!!Don’t forget how dangerous misconfiguring filters can be or you will be in the car with your console cable to recover the device!!

Right that should be it for PIM, let’s see if we have neighbour lift off.

*A:R3# show router pim neighbor

===============================================================================
PIM Neighbor ipv4
===============================================================================
Interface Nbr DR Prty Up Time Expiry Time Hold Time
Nbr Address
-------------------------------------------------------------------------------
R4_1/1/2 1 1d 18:47:24 0d 00:01:21 105
34.34.34.4
-------------------------------------------------------------------------------
Neighbors : 1

Great stuff, now we will configure R4 as the RP (bsr and rp candidate) and make sure R3 figures this out. We will use the system address of R4

R4
config router pim
rp
bsr-candidate
address 44.44.44.44
no shutdown
exit
rp-candidate
address 44.44.44.44
no shutdown
exit
exit


And the proof/pudding relationship:

*A:R3# show router pim status | match post-lines 13 BSR
BSR State : Accept Preferred

Elected BSR
Address : 44.44.44.44
Expiry Time : 0d 00:01:19
Priority : 0
Hash Mask Length : 30
Up Time : 1d 18:39:01
RPF Intf towards E-BSR : R4_1/1/2
.
Candidate BSR
Admin State : Down
Oper State : Down
Address : None
Priority : 0
Hash Mask Length : 30
.
Candidate RP
Admin State : Down
Oper State : Down
Address : 0.0.0.0
Priority : 192
Holdtime : 150

So we can see R3 has in fact learned R4 is the BSR. Just to illustrate the point that R3 is not in the running for RP, we can see that both RP and BSR candidate are admin down by default.

Here is a quick post on how to capture at least some packet header information on a 7750 if you don’t have the luxury of Wireshark to hand. The 7750 allows the creation of mac and IP filters to control traffic in the same way an ACL does on an IOS device. The bonus you have with the Alcatel is that it can also log the header output to a file for review.

Creating a filter is straightforward but care must be taken to ensure you do not disrupt traffic flow when applying it.

First we will configure an IP filter using the default filter log, 101.

*A:r1# configure filter
- filter
[no] ip-filter + Configure an IP-filter
[no] mac-filter + Configure a mac-filter

As you can see we have the option to configure an IP or mac based filter. I have removed other options for now. Creating the filter itself is the first part of the process. Once done the next step is to specify the default action, in our case we want to forward all traffic. This step can be service impacting if not done correctly.

configure filter
ip-filter 99 create
default-action forward

Once that part is done we configure entries for variables we want to match against. To see all traffic we simply set the action to forward here as well. Why do we do this when we have already set the default action? There is no logging option outside of specific entries unfortunately. For the first filter we won’t bother matching anything, we want to capture all traffic.

entry 10 create
action forward
log 101

So that’s the filter done, we just need to apply it to the interface, or SAP, we want to monitor. Here I will apply it to interface tor4 and look at network traffic:

config router inter tor4 ingress filter ip 99

Now we should not have to wait long, as this interface is running OSPF we should see OSPF at least:

show filter log 101
[snip]
2013/11/20 22:19:38 Ip Filter: 99:10 Desc:
Interface: tor4 Direction: Ingress Action: Forward
Src MAC: 14-cf-a4-c0-40-5d Dst MAC: 01-00-5e-00-00-05 EtherType: 0800
Src IP: 41.41.41.4 Dst IP: 224.0.0.5 Flags: 0 TOS: c0 TTL: 1
Protocol: 89
[snip]
2013/11/20 22:19:42 Ip Filter: 99:10 Desc:
Interface: tor4 Direction: Ingress Action: Forward
Src MAC: 14-cf-a4-c0-40-5d Dst MAC: 01-00-5e-00-00-02 EtherType: 0800
Src IP: 41.41.41.4:646 Dst IP: 224.0.0.2:646 Flags: 0 TOS: c0 TTL: 1
Protocol: UDP

So what are we looking at here?

$timestamp Ip Filter: $filternumber:$entry Desc:
Interface:$interfaceID Direction: Ingress Action: Forward
Src MAC: 14-cf-a4-c0-40-5d Dst MAC: 01-00-5e-00-00-05 EtherType: 0800
Src IP: 41.41.41.4 Dst IP: 224.0.0.5 Flags: 0 TOS: c0 TTL: 1
Protocol: 89

Some of this is obvious, some not:
$timestamp: The time at which the packet was logged
$filternumber: the filter ID we configured, in this case 99
$entry: the entry we configured, i.e. 10
$interfaceID: the interface we configured the filter under

Some of the more obvious ones are we set the direction to ingress by putting the filter under ingress at the interface level. Our action on entry 10 was to forward. We are also presented with the source mac/IP which is our neighbour router (remember ingress). The destination is to all OSPF routers so this is a multicast packet. The EtherType indicates the upper layer protocol is IPv4 and the protocol number confirms this is OSPF. While it is useful to see OSPF packets it’s something that is easily seen in a debug.

The second packet in the capture is an LDP packet, an LDP hello in fact as it is UDP directed the all routers multicast address, the port number being used is 646. Maybe LDP isn’t as intuitive to debug, now you can see the traffic live. If we take a look at a mac filter the principle is the same. In this case we will place the filter on a SAP and see customer frames however first we will create a new log file, 102, to show how this is done.

config filter log 102 create
description "SAP_SNIFFER"
destination memory 100
wrap-around
no shutdown

We can send the traps to local memory or we can send them to syslog. With syslog there is more involved and people might not like you trap storming them
Now if we create and apply our mac filter:

mac-filter 99 create
default-action forward
entry 10 create
log 102
action forward
/configure service vpls 1234 sap 1/2/1:1234.0 ingress filter mac 99
show filter log 102
[snip]
2013/11/20 22:52:00 Mac Filter: 99:10 Desc:
SAP: 1/2/1:1234.0 Direction: Ingress Action: Forward
Src MAC: 00-a1-29-5d-b5-75 Dst MAC: 01-b1-c0-40-63 EtherType: 0800
Src IP: 10.9.8.1:1557 Dst IP: 10.9.10.15:162 Flags: 0 TOS: 00 TTL: 255
Protocol: UDP

This message is an SNMP trap being send from a device back to a server as it is using port 162. If we are monitoring SNMP we can leave this filter running for a while and ensure bidirectional communication is happening.
So why would you use a mac filter over an IP filter and vice versa? You can’t apply both to every interface type. In our IP filter example we applied it to a network interface, mac filters are not supported here. You need to choose the right filter for the right occasion.

If you want to look for a specific protocol it’s pretty straightforward.  Below we will edit ip filter 99 to match protocol 89.  This will then log against OSPF messages:

A:r1>config>filter>ip-filter# entry 10
A:r1>config>filter>ip-filter>entry# match protocol 89
*A:r1>config>filter>ip-filter>entry>match# back
*A:r1>config>filter>ip-filter>entry# info
----------------------------------------------
match protocol ospf-igp
exit
log 101
action forward
----------------------------------------------
*A:r1>config>filter>ip-filter>entry# /clear filter log 101
*A:r1>config>filter>ip-filter>entry# show filter log 101
[snip]
Maximum entries configured : 1000
Number of entries logged   : 1
2013/11/29 09:05:18  Ip Filter: 99:10  Desc:
Interface: tor4  Direction: Ingress  Action: Forward
Src MAC: 14-cf-a4-c0-40-5d  Dst MAC: 01-00-5e-00-00-05  EtherType: 0800
Src IP: 41.41.41.4  Dst IP: 224.0.0.5  Flags: 0  TOS: c0  TTL: 1
Protocol: 89

You can use various different protocol filters, ICMP, TCP or UDP port numbers. Filters can be a useful operational tool for troubleshooting but they can also be dangerous if used incorrectly. Practice using them in a controlled environment and add them to your troubleshooting arsenal.

In this post I will go over the basics of port configuration on the 7750, going in to some detail on the Ethernet specific parameters you can fine tune.  I will do this on XP type MDA which have DDM (diagnostic ability) built in to them.  This allows you to see light levels and card temperatures and also sends traps in to SAM so you can keep an eye on optics that may be failing or dirty, nice feature.  I don’t really have access to SDH/Sonet type cards but if I dig one out I might try and figure it out and post about it

The first part of configuring your port will cover the usual basics.  Depending on the card type you are using the default values with either be network or hybrid more.  Basically a network port mode allows you to configure a routed interface, IGP and MPLS and is used to connect your SP routers together.  You can’t run services on these ports, for that you need an access port configuration, well except if you have an IMM card (and no doubt others) which allow the configuration of a hybrid mode.  This allows the configuration of core connections but also services.

To change a port configuration to any great extent you usually have to shut it down.  By default the port will already be shut but sure here is how you do it anyway and then go in to Ethernet sub-config mode:

*A:pe1# configure port 1/1/1
*A:pe1>config>port# shutdown
*A:pe1>config>port# ethernet
*A:pe1>config>port>ethernet#


Changing some of the Ethernet variables have a habit of defaulting ones you may have already set so I like to configure ports in a specific sequence.
The mode determines how the port will function and also alters the MTU (default 9212 on network). As discussed your three modes of operation are access, network (default) and hybrid using the mode command.

*A:pe1>config>port>ethernet# mode access|network|hybrid


Next I like to change the encapsulation which has three options as well: null, dot1q and qinq.

*A:pe1>config>port>ethernet# encap-type dot1q|null|qinq


Now is probably a good time to talk about tag behaviour in SROS/TiMOS.  Unlike ‘normal’ VLAN behaviour the tag configuration doesn’t put traffic in to a specific VLAN as it would in a LAN set up.  The behaviour is one of a matching criteria only so if we consider we have an interface configured to match tag 100 within service 1234 and the port receives a frame with tag 100 (outer tag) how will traffic be processed?  The tag is popped and put in to service 1234:

-If the service is p2p the traffic is MPLS encapsulated (or GRE) and sent as native Ethernet across the core.  At the far end PE traffic is de-encapsulated (MPLS) and the egress dot1q tag is pushed and the frame transmitted.  If the service is local only then traffic is forwarded out the other local interface without MPLS forwarding.

-If the service is mp2mp the L2 destination address is inspected and a forwarding decision is made by the PE.  The remainder of the forwarding behaviour remains the same.

Tagging types:

Like the name suggests null encapsulation uses no tagging.  You can only have one service or routed port per physical port.  From a service perspective the benefit is tag transparency to the customers tagging as regardless of if the frame is tagged before it gets to your router, the traffic is accepted.

A port configured for dot1q ensures the router must match one tag, of course there are exceptions! In our example with tag 100, if the ingress frame has 100 applied as its outer tag then it is accepted into service 1234.  If it is any other integer then it will be dropped unless another matching tag/service is configured.  The exceptions here are if you configure a dot1q service SAP to expect untagged traffic or match a wildcard which I will cover when I get on to service configuration.

A port configured with dot1q-in-dot1q will expect services to be double tagged (again with exceptions).  Both inner and outer tags are generally matched except where untagged or wildcards are used.  The forwarding behaviour remains the same as above except there is now more granularity in how you can match traffic to services.   This setup is useful for carriers’ carrier type services where another provider is providing the attachment circuit to a remote location.  The outer tag is used for service delimitation on the other carriers network and the inner tag defines the service you are providing over their pipe.

MTU is the next variable I configure.  On the SROS routers the MTU will default to 9212 on a network port but not on an access port (that could be release dependent, I don’t know).  To change the layer 2 MTU use the mtu # command.

*A:pe1>config>port>ethernet# mtu 9212


If you need to change the speed or duplex settings on a port this is done in the Ethernet context too. You use the speed 10|100|1000 and duplex full|half commands.  I won’t spend any more time on these.

That’s it for standard configurations, now on to more case specific ones.

Auto negotiation isn’t anything new but there is a little feature in SROS called limited negotiation.  What this does, or doesn’t do, is participate in actual link negotiation but does transmit a form of keepalive across the link which enables faster link failure detection.  It is enabled using the following:

*A:pe1>config>port>ethernet# autonegotiation limited


Down When Looped

Another nice feature is called down when looped.  This transmits an untagged frame with the source/destination address of the router MAC address with an ethertype of 0x9000. The downside here is the untagged nature of the frame means you cant use this feature where you use a 3rd party attachment circuit as they will be expecting tagged traffic, your frame will be dropped.

If the PE detects it’s own address in a frame of this type it knows there is a loop in the path and disables the port.  This feature is hugely import for VPLS builds as a loop on an attachment circuit can bring down every VPLS with an interface on that port.  DWL is enabled by entering its context and performing a no shutdown.

*A:pe1>config>port>ethernet# down-when-looped
*A:pe1>conf>port>ethernet>dwl# no shutdown


The output of this is verified in the show port command:


show port 1/1/1 | match post-lines 2 Down-whe
Down-when-looped : Enabled Keep-alive : 10
Loop Detected : False Retry : 120
Use Broadcast Addr : False


As we can see down when looped is enabled and loop detection is false. If a loop was detected this state would change to ‘True’.

Variables we can configure include the keep-alive # option which defines the interval in seconds between transmission of the DWL PDUs. retry-timeout # allows you to set the time in seconds between a port being disabled due to loop detection and the system trying to recover the port. This is similar to err-disable recovery in IOS. Finally you can set the system to set the destination address to the broadcast address, enabled through use-broadcast-address.

Ethertypes:

You can alter the default ethertypes used by dot1q, q-in-q and PBB if you wish. Defaults for the first two are 0x8100 and provider backbone bridging uses 0x88e7.


show port 1/1/1 | match post-lines 1 8100
Dot1Q Ethertype : 0x8100 QinQ Ethertype : 0x8100
PBB Ethertype : 0x88e7


Changing these values is done using one of the following:


*A:pe1>config>port>ethernet# dot1q-etype 0x0600..0xffff
*A:pe1>config>port>ethernet# qinq-etype 0x0600..0xffff
*A:pe1>config>port>ethernet# pbb-etype 0x0600..0xffff


Miscellaneous:

There are some other variables which you can set that I won’t go in to but you can also enable dot1x, lldp (standardised equivalent to CDP) and various management procotols such as EFM, CFM and ELMI.

A final note on DDM mentioned above.  This displays port specific parameters on the XP or IMM cards. The below output shows you the temperature of the port, power readout and, most importantly from an operational perspective, the transmit and receive rates of the optics. The thresholds are used to trigger alerts to your SAM NMS.


show port 1/1/6 | match post-lines 10 Digital
Transceiver Digital Diagnostic Monitoring (DDM), Internally Calibrated
===============================================================================
Value High Alarm High Warn Low Warn Low Alarm
-------------------------------------------------------------------------------
Temperature (C) +33.9 +98.0 +88.0 -43.0 -45.0
Supply Voltage (V) 3.29 4.12 3.60 3.00 2.80
Tx Bias Current (mA) 6.3 60.0 50.0 0.1 0.0
Tx Output Power (dBm) -5.65 0.00 -2.00 -10.50 -12.50
Rx Optical Power (avg dBm) -6.43 -3.00 -4.00 -19.51 -20.51
===============================================================================


That’s all for this post, good to get the basics (boring bits) out of the way 🙂

Tis the season to write stuff down on what I hope to achieve over the coming year so that I might laugh at my abject failures in 12 months time.

My primary goal is one of self improvement.  This coming week marks the return of bi weekly squash and I need to be out on my bike cos I’m waaaayyy too fat again.  Regardless of if it’s cold/wet/windy.

Ridiculous one:

1) See Liverpool win the league.  No chance, but some hope all the same.

Professional goals:

2) Complete the NRS2 lab, this one should be achievable.  The issue here is one of cost. $750 worth of cost for a professional level cert!  Plus flights to Brussels and accommodation.  This is where my (lack of) negotiation skills come in to play with work.

3) Complete the SRA lab which includes sitting 5 more written exams.  This one is optional for me depending on completion of the writtens to become eligible.  I have it on good authority I can be at the level required for the lab in a couple of months of consistent practice.

4) Make a decision on whether I continue with my ‘dream’ of the CCIE RS or switch to the SP track, which I prefer.  This will be down to INE in part if they are willing to compromise on what I have already paid for.

5) Do a couple of CCNA levels certs, primarily the SP if INE release some vids as rumoured. As a hater of voice getting that CCNA done would be nice so I have some experience of it.

6) If time allows do the CCNP SP.

Are any of these achievable ?  Only time will tell.

TTFN.