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
Best Answer
Introduction
First off, let me write that i spend most of the summer trying to figure out a correct way to get this done. More so i had to hire a CCIE full time for a week or so to help out and in the process we had Cisco TAC trying to figure out an error on our 6500 series switches.
Why would you do this?
Today there's a virtual explosion of rich media applications on the IP network. This explosion of content and media types, both managed and un-managed, requires network architects to take a new look at their Quality of Service (QoS) designs.
The first step may seem obvious and superfluous, but in actuality it is crucial: clearly define the business objectives that your QoS policies are to enable. These may include any/all of the following:
With these goals in mind, network architects can clearly identify which applications are relevant to their business. Conversely, this experience will also make it apparent, which applications are not relevant towards achieving business objectives. Such applications could be consumer-oriented and/or entertainment-oriented applications. In the end it is all up to you.
The solution
I wanted to make this as easy and configuration free as possible. With that in mind combined with the fact, that QoS should always be processed in hardware, i was recommended to make use of the Auto-QoS feature in Cisco by the CCIE i hired.
So instead of marking traffic at the access level, the marking can be made by the end users or servers themselves. Auto-QoS then provides the correct classes for transportation of the traffic throughout the network. This enabled me to decide what applications or services which should be prioritized or de-prioritized via active directory group policies.
For starters i wanted to make it simpel. This meant prioritizing VoIP and Video applications, which is already predefined in Auto-QoS when you are using Cisco IP devices/TelePresence/Cameras etc., which we do.
Topology overview
We make use of the following access/core equipment.
Our topology is primarily based on a star topology, observe the following topology drawing (We use BGP in our WAN MPLS):
QoS on the access layer
The configuration is very simpel and straight forward, when using Auto-QoS. Remarking traffic and sending that to the MPLS ISP is a bit more complicated, but i will showcase examples below.
All access switches are setup with Auto-QoS, where all ports both access and trunk/uplinks are trusted with DSCP. Observe the following QoS table, where all values for DSCP, CoS, ToS etc. are setup in a table. This gives a good overview of the selected classes and the structure in which i'm trying to accomplish in my design:
Auto-QoS uses AF (Assured Forwarding) values for DSCP marking.
Enabling Auto-QoS on the access switch
Global configuration
Port configuration
That's it, the switch and ports will now run Auto-QoS.
Auto-QoS Configuration guide for the 2960X Series: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960x/software/15-0_2_EX/qos/configuration_guide/b_qos_152ex_2960-x_cg/b_qos_152ex_2960-x_cg_chapter_011.html
Enabling Auto-QoS on the Core layer
There's a big difference in the way QoS is handled by Core switches. The Cisco 6500 Series does not support Auto-QoS SRND4, therefore we will need to manually configure QoS and map it to the correct classes in order to preserve the Auto-QoS design. The Cisco 3650 and 3850 Series support Auto-QoS SRND4 and therefore it's pretty simpel to configure:
Enabling Auto-QoS on the 3650 and 3850 Series
Global configuration
Port configuration
When connecting the Core to the MPLS ISP, we want to remark the traffic into 5 classes (Because this is what our ISP supports). This is so, that the traffic will be prioritized through the MPLS to all the locations in the topology (See drawing for reference). Your ISP might be different and therefore the remarking should be made so it fits your design. The following example is how you remark all traffic into 5 classes.
You need to copy the auto generated Auto-QoS "AutoQos-4.0-Output-Policy" policy-map and then create a new one. You HAVE to use the same class-maps as generated by Auto-QoS. If you try to create your own they will be ignored, therefore the same class-maps are used and the marking is made from those classes:
The 5 classes will hereafter be prioritized and sent to the MPLS as follows:
The bandwidth percentages are used as remaining. This means that all classes are allowed to use 100% of the bandwidth and loan from the other classes if the bandwidth is not used. It's like bandwidth sharing, which means that whatever class is prioritized the highest will be able to send traffic if the link is congested.
The policy-map classes and percentages can be modified as needed to suit your individual requirements.
On the port uplink to the ISP the following needs to be configured:
That's it for the 3650 and 3850 Series.
Enabling QoS on the 6500 Series
The 6500 Series does not support Auto-QoS SRND4. It's very basic and it only understands layer 2 CoS values for VoIP. This means you need to configure all QoS from the ground up, to fit the Auto-QoS infrastructure from the access layer. QoS needs to be configured based on which module is installed on the chassis. You also need to create policy-maps for both ingress and egress (input/output).
The Supervisor only understands CoS between the module and the ASIC in the chassis.
To activate Auto-QoS for CoS, you need to utilize the following global command:
This will create a table-map of CoS to DSCP, but the values do not all comply to the Auto-QoS SRND4 standard (CoS 7 is mapped to 54, which should be 56). Therefore you will need to remove the table-map and replace it with the following:
To create QoS and policy-maps we need to find out, what queueing model a module is using. In the example below the Ingress and Egress queue is the same, but on some modules the Rx and Tx queues are different and therefore you will need to create policy-maps in accordance to how the queueing model is. To find out what queueing model an interface is using, you need to issue the following command. The below example is based on the module: C6800-16P10G
As written the queues are the same on this module and therefore we can use the same policy for both input and output.
1p7q4t basically means: 1 priority queue, 7 normal queues, where all 7 normal queues have 4 thresholds. You can get more info by searching for the module name and queueing. This module, the C6800-16P10G is explained in this link: https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6800-series-switches/datasheet-c78-733662.html
See table 1, Queues.
Firstly we need to create the class-maps, that will be used for all policy-maps. This will match the DSCP values for the individual classes that matches the classes from Auto-QoS SRND4. Notice that the class-maps are created as lan-queueing with the match-all statement, which functions like AND/OR in programming. match-all=AND & match-any=OR.
Check the following configuration guide; Cisco Campus QoS design simplified, where configuration examples are provided per different modules at the bottom of the presentation: http://honim.typepad.com/files/campus-qos-design-simplified-brkcrs-2501.pdf
225 pages, link is slow.
Creating class-maps (Global configuration):
You can change the names or edit as you like, to fit your needs.
After creating the class-maps i'll create the policy-map. It defines the priority of the DSCP value and sets the bandwidth in the different queues, after it matches a DSCP value.
After creating the policy-map you need to apply it to an interface:
To verify your configuration and to see that queueing is being performed you can use the following command (you might need to shut/no shut the interface for it to take effect):
To remark the traffic on the 6500 Series you need to create new class-maps and a new policy-map. The class-maps are not created as lan-queues and the match statement is match-any=OR instead of match-all as we want to check multiple values one after one. So if the first value does not match the packet, the next one will be checked and so forth.
I want to point out that this is where we had to involve Cisco TAC, because the following bug came up: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuz52151
We had to change the class-maps from matching on AF values to raw DSCP values (discard-class) instead. We also had to upgrade the switch to version 152-1.SY5 (MD). After we followed these directions we've not had any problems since.
The configuration is as follows:
After this we create the policy-map:
Then we need to apply it to an interface:
That's it. I hope this information helps you. I understand when people say, that QoS is complicated. It can be done in various ways and the above example is just a snip of how it can be done. I know that Cisco are working on spreading the Auto-QoS SRND4 standard to more and more devices to help creating a good basis for Quality of Service.