Archive for September 2012
Blogging for two years now!!!!
Well, its been another year time flies when your having fun! it’s hard to believe another year has flown by. It only feels like a few weeks ago, I did my last yearly post! I’d say the last year has been pretty good to me I got a SonicWall ceritifcation, my CCIP, & CCDP. Plus I started my way torwards my CCIE: R&S I’ve read and labbed for a lot of hours already reinforcing my knowledge.
So far I’ve got 65 articles published, which means I’ve published 35 new articles last year compared to the 30 articles I did my first year. Nowadays this blog averages 3600+ views a month where as last year it was only averaging around 1200-1400 views a month which means more and more of you guys are coming back! Thanks Guys!!! I’ve got much more in store for this blog this over the next year, I’m looking to get this blog its own domain and I have plans getting a few videos posted as well, so heres to another year of blogging!!
I’ve recently taken a Senior IT position within another MSP (Really recently, this will be my second week in the new position) so now I’ll get even more exposure to more technologies F5 Load Balancers, Nexus, IPS’s, and much more ASA related work on top of the normal switching and routing world that carriers it all (And I have couple wireless networks so we might be seeing wireless making a comeback!) So there will be many more blog posts coming down the pipe!
My top 5 articles:
- Understanding a Wi-Fi Connection with 3,406 views.
- Cisco Band Select with 2,703 views.
- Wireless Networking & the 5 GHz RF Range with 2,262 views.
- Cisco WLC Interfaces with 2,137 views.
- Cisco IOS DHCP Server with Option 43 for LWAP’s with 1,617 views
Total visits to my blog per date: 49,929!!!
Big changes from last year!!!!
Unicast Reverse Path Forwarding uRPF
Another great security feature within every Cisco IOS ISR is uRPF, Unicast Reverse Path Forwarding. This nifty little feature has the router verify the source of any IP packets received is reachable via the routing table. uRPF is used to prevent common spoofing attacks and follows RFC 2827 for ingress filtering. The router will actually rely on the CEF table to perform lookups. uRPF works in 2 modes strict mode and loose mode, lets quickly talk about these two modes of operation.
- Strict Mode: In this mode the router verifies the source of the IP packet arrives on the same interface the router would use to reach that source address. Beware of asymmetric routing.
- Loose Mode: In this mode the router simply verifies the source IP can be reached via the CEF table using any interface.
Now that we quickly discussed the 2 different modes uRPF operates in, let’s go over a few quick tips:
- Since uRPF relies on CEF, CEF must be enabled.
- uRPF takes into account multiple paths, so if you are doing any equal cost load sharing uRPF will take that into account. uRPF will also take into account any unequal cost load sharing (such as EIGRP variance).
- Asymmetric routing is different from (un)equal cost load sharing, and can/will cause issues with uRPF.
- uRPF works best at the network edge, and to further specify the network edge not on your access layer the network edge facing the public internet.
Let’s now configure uRPF, we are going to start off with the configuration of loose mode:
This is a good time to mention uRPF is configured on an interface basis, and it is enabled by a single command. The keyword at the end of the command specifies the mode uRPF operates in, since I am configuring uRPF in loose mode I want to make sure the router can reach the source of any IP packet received on interface fa0/0 using any interface on the router.
Now let’s configure uRPF to operate in strict mode:
You’ll notice this command is very similar to the way enable loose mode, with the exception of the keyword rx at the end of the commend, this tells the router to verify the source of any IP packet received on interface fa0/1 should be reachable via interface fa0/1 and not any other interface on the router. As mentioned previously the router verifies connectivity by looking at the CEF table, if CEF points to an interface that the packet was not received on that packet will get dropped.
Now that we have configured uRPF (simple right?) let’s issue a couple show commands to verify our configuration:
Show ip traffic – This command will tell you how many packets uRPF has dropped.
Under the IP statistics the first Drop section has an entry for unicast RPF this counter keeps track of how many packets uRPF drops which is definitely useful to know. You’ll also notice 12 packets were dropped, which we will discuss later.
Another command is show cef interface %Interfacenum/num% this command will also tell you whether or not uRPF is enabled on the specific interface.
Let’s also not forget the simplest command of them all: show run interface %interfacenum/num%
One feature that makes uRPF even more powerful is the fact we can tag on an ACL specifying traffic we want checked or don’t want to be checked. For example I configured uRPF on one my lab routers that had an old DMVPN & BGP configuration running on it, shortly after I configured uRPF I noticed the BGP adjacencies to the spokes go down. After that I configured an ACL so my DMVPN Tunnel traffic was not caught by the uRPF check.
You guys should know by now how much I love named ACL’s but you’ll notice I used an extended numbered ACL, the reason for that on the is simply due to the fact I couldn’t use a named ACL with uRPF.
No option to use a named ACL only numbered ACLs. There are two other options there allow-default which allows the default router to be used when verifying source addresses, and allow-self-ping which allows the router to ping itself, although allowing self-ping opens the router up to a DoS vulnerability.
You can also read more about uRPF in RFC 3704.
CCIE or Null! 