Access-List Information from Cisco SNMP – How to Retrieve

Here's the history of how they came into being (and why they are the way they are):

• In the very early days of the Internet, people started asking for packet filters (aka access lists).
• Cisco implemented simple access lists first (filtering on destination host addresses, augmented by wildcard masks), but of course they weren't good enough to block (for example) SMTP, so they created extended access lists, which can match on source and destination IP addresses (with wildcards bits on both - these bits allow you to match whole prefixes), protocols, port numbers ...

So: access list = packet filter.

Later (but still decades ago) people started running multiple routing protocols on the same box and wanted to redistribute information between them. Not a problem, but you wouldn't want ALL the information you have propagated into the other routing protocol - you need ROUTE FILTERS. As is usually the case, everything looks like a nail if you happen to have a hammer, and thus Cisco's engineers implemented route filters with the object they already had - access lists.

At this point: access list = packet filter (and sometimes route filter)

With the advent of classless routing (yeah, it's that long ago - does anyone still remember the days of Class A, Class B and Class C addresses), people wanted to redistribute prefixes of certain size between routing protocols. For example: advertise all /24s from OSPF into BGP, but not the /32s. Impossible to do with access lists. Time for a new kludge: let's use extended access list and let's pretend the source IP address in the packet filter represents network address (actually prefix address) and the destination IP address in the same line of the packet filter represents subnet mask.

This far: access lists = packet filters. Simple access lists also serve as route filters (matching only on network addresses) and extended access lists serve as route filters matching addresses and subnet masks.

Fortunately someone retained a shred of reason at that time and started wondering what exactly the brilliant minds that decided reusing extended ACLs for route filters makes sense were smoking when they got that brilliant idea.

End result: Cisco IOS got prefix lists, which are (almost) identical in functionality to extended access lists acting as route filters, but displayed in a format that a regular human being has a chance of understanding.

Today: use access lists for packet filters and prefix lists for route filters. You can still use access lists as route filters but don't do it.

Makes sense?

Best practice wise - should I let the router or the ASA handle NAT (Overloading)?

In the most general of design best practices NAT is performed between an inside and outside network. NAT overloading is generally performed at the edge when there is limited public IP address space. You can learn more about NAT overloading, also known as Port Address Translation or PAT, in RFC 2663 (PAT is referred to as Network Address Port Translation (NAPT) in section 4.1.2).

In this particular scenario you can argue that you have two inside and outside networks and will need to perform some form of NAT on both the ASA (whether that is the NAT overloading you're using now, NAT exemption, static NAT, etc) and the Cisco Router.

I can ping the 172.16.2.2 interface but not 172.16.2.1 from a pc connected to one of the layer 2 switches (proves intervlan routing is working -- i have a 172.20.100.8 address on the PC). Why can't I ping 172.16.2.1 from a PC but I can from the Layer 3 Switch?

The ASA 172.16.2.2 is receiving the ICMP echo-request but does not have a route back to 172.20.100.0/27. The echo-reply is actually being forwarded to the Router 172.16.1.1 via the default route.

And most of all -- Why can't I get out to the Internet from the Layer 3 switch?

Currently your ASA and Cisco Router do not have routes to internal devices other than their connected routes.

Your ASA configuration:

route outside 0.0.0.0 0.0.0.0 172.16.1.1 1

This will provide a default route via the outside interface, but how will the ASA know how to reach subnets residing behind the Layer 3 Distribution Switch?

You'll need to add routes to the internal subnets via the inside interface using the Layer 3 Distribution Switch as the next-hop IP address.

ASA static routing example:

route inside 172.19.12.0 255.255.255.240 172.16.2.2
route inside 172.19.3.0 255.255.255.0 172.16.2.2
route inside 172.20.100.0 255.255.255.224 172.16.2.2

Further reading: ASA static routing

Your Cisco Router's configuration:

ip route 0.0.0.0 0.0.0.0 200.200.200.200

Additionally, how will your border router know how to reach subnets other than it's connected routes, and the catch all default route via the outside interface's next-hop address 200.200.200.200?

Router static routing example:

ip route 172.19.12.0 255.255.255.240 172.16.1.10
ip route 172.19.3.0 255.255.255.0 172.16.1.10
ip route 172.19.100.0 255.255.255.224 172.16.1.10
ip route 172.16.2.0 255.255.255.224 172.16.1.10

Further reading: ISR static routing

I cannot get an ip address right now from the DHCP server (Windows). Any insight into why?

Ensure you have end-to-end IP reachability between the client(s) sending DHCP discover messages and the DHCP server.

From what I can gather from your topology and configuration, the subnets 172.19.3.0/24, 172.19.12.0/28 and 172.20.100.0/27 should have no issues connecting to each other (assuming they are configured to use their respective default gateways) from a networking perspective.

You can remove the ip helper-address syntax from the SVI 100 given that the DHCP server is on the same segment and that command is used for a DHCP server(s) that is on a different segment.

interface Vlan100
ip address 172.20.100.1 255.255.255.224
ip helper-address 172.20.100.27