DHCP Snooping and Option 82

This is yet another one of those topics I always passed over.  "DHCP snooping", I'd say to myself, "is too simple to bother with".  I've also never put it into production, so I've absolutely never set it up.  Figured this was as good a time as any.  When I write about these topics I like to learn all aspects of them, so I'll delve into the problems created by DHCP option 82 as well.

We'll start out really simple on this one just to get the feature working.

One VLAN (100), one subnet.  R1 will be the DHCP server, R3 will be the DHCP client.  SW1 will be running DHCP snooping.  Once again, I tend to use GNS3 for diagrams (probably obvious from the icons), but this cannot actually be labbed in GNS as the 16-port switch that can be inserted in the 3725 doesn't have the capacity to perform DHCP snooping.  I'm using real 26xx series routers and 3560 switches.

First we'll start without snooping.

Stateful NAT with Asymmetric Routing

In IOS 12.3, Cisco introduced support for asymmetric routing with SNAT, or Stateful NAT.  The SNAT feature allows multiple routers to share NAT tables, generally with the expectation of an HSRP standby router being able to take over the NAT translations from the primary.  Prior to 12.3, all NAT traffic had to pass through one router - the primary while it's up, or the secondary while it's down.  The idea was to make sure the NAT sessions didn't timeout on the primary router from it only seeing parts of a TCP session. With the outside asymmetric feature, this requirement is removed, and the "backup" router can share state with the primary router, keeping the NAT sessions alive.

While it's technically optional now, SNAT is embedded with HSRP.  I've had a couple production scenarios where asymmetric HSRP is necessary.  Normally the scenario looks something like this:

In this example, EDGE1 and EDGE2 are the HSRP pair.  Both EDGE1 and EDGE2 are peered to different ISPs with eBGP.  They're also peered to each other via iBGP.  Why HSRP here?  This is a perfectly good hot/hot scenario.  In the average route/switch diagram, the expectation would be to have hosts or other routers behind EDGE1 and EDGE2.  In the real world, unless you're an ISP or an enterprise with a large public presence, the average large business puts an HA firewall pair in hot/cold directly behind the Internet edge.  If these were routers instead, you could use iBGP to pass the full Internet tables downstream, and have load sharing in that fashion.  If these were hosts instead, you could use GLBP and get egress load sharing on to the EDGE routers by having each host have an alternating ARP for the default gateway.

Reflexive ACLs and Local Policy Routing

Two topics today: Reflexive ACLs (RACLs) and Local Policy Routing, and how they interoperate.

RACLs provide a firewall-like function.

The idea is to manually create two ACLs: inside-to-outside, and outside-to-inside.  inside-to-outside matches will be reversed into a reflexive ACL, and then evaluated as part of outside-to-inside, which would generally otherwise deny most traffic.

Here's our diagram:



R1 & R2 will represent our inside network, and R3 the outside.  R2's Fa0/1 will be our security border.  The segment IPs are represented on the diagram.  Each router is using it's router number to form its IP address (on 192.168.12.0; R2 would be 192.168.12.2, etc).  Each router also has a loopback of X.X.X.X/24, where X is the router number.