Archive for May, 2014

End of an era and new stuff

May 12, 2014 4 comments

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.

Categories: Uncategorized

RPF on the 7750

Burak recently asked for a post on RPF loose and strict modes and how they behave on the 7750.  I have quit my job so I have been frantically trying to get things finished and handed over and haven’t had time to really test anything for my own amusement.  As I will be finishing up tomorrow and won’t have access to any 7750 lab stuff this is a real quick thrown together post.

We will use a simple network of four routers.  All routers have all interfaces in OSPF area 0 with the same cost of 10 on each link.  OSPF preference (AD) on the 7750 is 10.  We configure a static route on r1-rack3 pointing out to r2-rack3, its preference is 5. r1-rack3 is at



So what does the topology look like from r1-rack3s  perspective?


and what does r5-rack15 think?

r5r15 routetbale

r5-rack15 is going to send traffic on the direct path to r1-rack3 but r1-rack3 thinks should be reachable via r2-rack3.  Let’s enable RPF on the interface and see what happens (ignore the IntraAS in the name, it’s from another test).

r1r3enable rpf

I have now enabled loose mode RPF.  Theoretically traffic should pass here as once the prefix is in the routing table it should be ok.  First clear the statistics (you need to use the urpf-stats variable to clear RPF stats or they won’t clear down)

clear stats

Now we send a ping from r5-rack15 sourced from

ping from r5 good loose

As we can see the pings are successful.  This is because even though r1-rack3 uses different egress than the received packets ingress, loose allows more flexibility in what the router will accept.

r1r3 rpf loose no increment in poing

Happy days, our check fail stats have not increased.  Now let’s enable strict mode and see it all fall apart. Strict mode means you MUST receive the packet over the interface you would use to transmit to the destination.

r1r3 enable strict

Now when we ping from r5-rack15 to r1-rack3 we should not see a response to our packets arrive.

r5 pings fail

In fact debug router ip icmp doesn’t even show up failed attempts. They’re just ignored.

r1 rpf incrementing

Look at that, beautiful.  OK so it’s not a very elegant way of showing how it works but it does.  I haven’t found a debug for RPF fails or anything beyond show router interface statistics to display any further RPF information.  If you know of any stick it in the comments and I’ll add it.

Categories: ALU IGPs, ALU Multicast