Archive for the ‘policy’ tag
Stubby Post – Set DF to 0 with a Route-map
We ran into an issue the other day where an application was setting the DF bit in IP packets to 1. We thought it may be causing problems, so we looked at setting up a route-map to set the DF bit to 0. It turned out to be a different application problem, but it was a good exercise in looking at what you can do with route-maps and policies.
I set up a lab in GNS3 to replicate and do some captures. It’s a really simple setup. R1 connected to R2 connected to R3.
Beyond the routing, here’s the config we put on R2. You configure it just like PBR, but, instead of setting the next hop or interface, you just set the DF bit to 0.
route-map E0/0-IN permit 10 set ip df 0 ! interface Ethernet0/0 description To R1 ip address 10.0.0.2 255.255.255.0 ip policy route-map E0/0-IN
Really simple. We’ve all done this many times, but I’ve never cared enough about the DF bit to have to set it on a router. That’s usually what the applications does, and, to tell the truth, I imagine that setting it only shows up in 0.009% of networks.
To test the new policy, I did a packet capture between R1 and R2 and another between R2 and R3. R1-R2 shows the DF bit set to 1 on a ping I did from R1 to R3. For those that care, I did a ping 10.0.1.3 repeat 100 df-bit to generate this traffic.
The capture from R2-R3 shows the DF bit on the same packet set to 0.
ROUTE Notes – PBR and IP SLA
Feel free to correct.
Study Questions
- What’s the most primitive way to get traffic destined to a single host to use a different path than your dynamic IGP dictates?
Use a static route.
- What’s the most primitive way to get traffic sourced from a single host to use a different path than your dynamic IGP dictates?
Use policy-based routing (PBR).
- What’s the most primitive way to get traffic sourced from a single host and destined for another host to use a different path than your dynamic IGP dictates?
Use PBR.
- What are the steps to configure PBR?
Configure a route-map to match the desired traffic
Apply that route-map to an interface with the ip policy route-map command
- Configure PBR to send traffic that arrives on F0/0 from 10.0.0.5 destined for for 192.168.3.3 to be sent out the s0/0 interface.
R1(config)#ip access-list extended PBR-ACL1
R1(config)#permit ip host 10.0.0.5 host 192.168.3.3
R1(config)#route-map PBR-F0/0
R1(config-route-map)#match ip address PBR-ACL1
R1(config-route-map)#set interface s0/0
R1(config-route-map)#int f0/0
R1(config-if)#ip policy route-map PBR-F0/0
- What happens if you use PBR to redirect traffic to an IP that becomes unreachable?
That clause in the route-map is ignored, and the normal routing table is used.
- What difference does using default make in the set directive of the route-map?
If you use the default parameter in the set directive, then the router will first try to use the routing table to forward traffic before using the PBR settings. The one caveat, though, is the default chosen for the traffic cannot be the default route; a more-specific route must be in the routing table or else the PBR logic rears its head.
- What is IP SLA?
IP SLA is a feature of a Cisco IOS device where a process measures the behavior of the network.
- Why is this topic in the ROUTE book?
You can configure a track object to use IP SLAs to get a “failed” or “ok” status. That track object can be applied to static routes and PBR so that the routing is changed if the IP SLA measures a characteristic outside of normal parameters.
- What are the steps to configure IP SLA?
Create an IP SLA operation.
Define the type and parameters for the operation.
Define the frequency to run the operation.
Schedule when to start the operation.
- How do I use IP SLA to check if a host is pingable?
You use the icmp-echo as the operation type along with, at minimum, the IP address to ping.
- How can I use IP SLA to know whether a static route is usable or not?
First, create an IP SLA operation to ping the gateway for that route.
R1(config)#ip sla 5
R1(config-ip-sla)#icmp-echo 1.1.1.1
R1(config-ip-sla)#frequency 60 [ in seconds ]
R1(config-ip-sla)#exit
R1(config)#ip sla schedule 5 start-time now life forever
Then create a track object that references the IP SLA operation you just created.
R1(config)#track 2 ip sla 5 state
R1(config-track)#delay up 90 down 90 [ up if delay is below 90, down if above 90 ]
Finally, add the track to the static route.
R1(config)#ip route 10.0.0.0 255.255.0.0 1.1.1.1 track 2
Now, if the router can’t ping 1.1.1.1, the static route will be taken out of the routing table.
- What’s an IP SLA responder?
That’s (usually) a router that has been configured to interact with the IP SLA operation of another router to get characteristics of the connection between the two. These characteristics include jitter and TCP establishment times.
- How can I use a track object in PBR?
In the set directive, you use the track parameter. The sequence parameter is also used, but it’s not a part of the tracking process; it’s used to have the router go down a list of next hops until it finds on that’s available. Here’s an example.
set ip next-hop verify-availability 192.168.0.1 1 track 5
- Ummm…the book doesn’t have anything about that; what gives?
The cert guide leaves that part out for some reason even though it’s a very important part of IP SLA and PBR. Go figure.
What Command Was That
What command…
- …shows interfaces that have PBR configured on them?
show ip policy
- …shows the routing table and includes all the PBR configuration?
There isn’t one. You have to remember to check for PBR when traffic isn’t flowing as you think it should.
- …shows the IP SLA configuration?
show ip sla configuration [ Duh! ]
- …shows the IP SLA statistics?
show ip sla statistics [ Duh, again! ]
- …shows the track objects on a router?
show track
Stubby Post – Time-based ACLs and Policy-maps
Certain divisions of the company tend to shoot themselves in the foot by kicking off large file transfers during business hours, so I had a thought that maybe we could use time-based ACLs to do some QoSing for those guys. I fired up GNS3 with a 3600 running 12.4(25b) with some virtual PCs on it’s Ethernet interfaces.
time-range BUSINESSHOURS periodic daily 8:00 to 17:00 ! ip access-list extended PINGS permit icmp any any time-range BUSINESSHOURS ! class-map match-all PINGS match access-group name PINGS ! policy-map PM-F0/0-OUT class PINGS
First, I set the router’s time to outside of the time range and sent some pings over.
R1#sh clock
00:01:13.107 UTC Wed Apr 28 2010
R1#sh access-lists
Extended IP access list PINGS
10 permit icmp any any time-range BUSINESSHOURS (inactive)
R1#sh policy-map int f0/0
FastEthernet0/0
Service-policy output: PM-F0/0-OUT
Class-map: PINGS (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: access-group name PINGS
Class-map: class-default (match-any)
11 packets, 1140 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Alright, that’s expected. Now let’s set the clock to within the time range and repeat.
R1#sh clock
13:00:12.887 UTC Wed Apr 28 2010
R1#sh access-lists
Extended IP access list PINGS
10 permit icmp any any time-range BUSINESSHOURS (active) (10 matches)
R1#sh policy-map int f0/0
FastEthernet0/0
Service-policy output: PM-F0/0-OUT
Class-map: PINGS (match-all)
10 packets, 980 bytes
5 minute offered rate 0 bps
Match: access-group name PINGS
Class-map: class-default (match-any)
20 packets, 1970 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
How about that? Time-based ACLs seems to work with policy-maps. I didn’t know that.
NBAR and HTTP Data Conversations
I’m still working on the ONT test and doing labs, so I marked up a lab for me to work. I’m using the same setup as I did last time. The two routers are 3640s running 12.4(25b).
Part of the lab was to identify HTTP traffic coming into F0/0 and mark it as CS3. That’s pretty easy, right? Of course, the lab I made up was a little more complicated, but the point comes clear with a simpler example.
class-map match-all HTTP match protocol http ! policy-map PM-F0/0-IN class HTTP set dscp cs3 ! interface FastEthernet0/0 service-policy input PM-F0/0-IN
I fired off a small script on TestHost1 to repeatedly do NMap scans on TCP/80 of TestHost2 to generate some traffic.
root@bt:~#while ( true ) do nmap -sT -p 80 -v -n 172.16.2.101; done
I let that run for a while and checked out the service policy on F0/0; there were absolutely no matches on that class.
R1#sh policy-map int f0/0 input class HTTP
FastEthernet0/0
Service-policy input: PM-F0/0-IN
Class-map: HTTP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol http
QoS Set
dscp cs3
Packets marked 0
I thought that was strange, so I kept the script running and captured the traffic coming out of S1/0. Looking at the packets in Wireshark showed that none of the HTTP packets were showing up as being marked as CS3; they’re all set to the default DSCP value.
No matter how many NMap scans cycled through, the class never incremented a bit. I let it run for two full minutes and generated a few hundred HTTP packets, but there was still nothing.
On a whim, I enabled NBAR protocol discovery on F0/0 to see if that would shed any light on my mess. Guess what I found. That’s right; there were no HTTP matches to NBAR, either. That makes sense since the class-map I defined uses the NBAR protocol. Alright, so it seems that it’s NBAR that doesn’t see the packets as HTTP, but why?
Looking through the packet captures again, I noticed that there was no real data in the streams. I saw the 3-way TCP handshake (a.k.a., my signature wrestling move) and then a RST,ACK. I only told NMap to check if the port was open, so I changed the while loop a bit and enabled version detection with the “-sV” flag. This time when I can the script, NMap was actually getting the HTTP banner. It was much traffic, but it was an actual HTTP conversation, so I checked NBAR again. Success! The same for the class, too.
For craps and smiles, I created a class-map that matched SIP, added it to the same policy-map, and set NMap after TCP/5060 without version detection. Without having a real SIP conversation, the class counters incremented as long as I was sending packets. That would seem unexpected until you realize that NBAR has some advanced knowledge of HTTP; you can actually match on URLs, hostnames, and MIME-types. I guess that means it also know when a real HTTP conversation is taking place.
To finish out the testing, I added an ACL to the router that matched any-any-eq-80. I made the class-map into a match-any and added the ACL. Since the ACL just matches the destination port and doesn’t care what the content is, every packet sent matched the class as expected. I remember reading several places and seeing a couple videos that said that you can use NBAR matching and ACLs interchangeably. That may not really be true when it comes to HTTP.
Send any Cisco learning credits questions my way.
QoS Pre-classify and Class-map Order
I’m still studying for the ONT test, so I did some labs tonight. One of them was to demonstrate the qos pre-classify command for tunnel interfaces. When you have a packet sent over a GRE tunnel, the ToS field gets copied to the GRE packet, but there’s no way to see the original packet’s higher-level headers on the way out the interface. This can be a problem if your service policy needs to see protocol, port, IPs, etc. The fix for that is to enable qos pre-classify on the tunnel interface and cyrpto map; doing so will provide a copy of the original packet to the physical interface to classify the packet thoroughly.
Here’s the lab. I was testing from TestHost1 to TestHost2 and configuring R1 to do the pre-classification. Both R1 and R2 are 3640s running IOS 12.4(25b) and have a GRE tunnel between them.
I created a policy map that simply acknowledges the existence of ICMP packets; the router doesn’t do anything except match them in a class-map and smile at them on the way through. Here’s the snippet.
class-map ICMP match protocol icmp ! policy-map PM-S1/0-OUT class ICMP ! interface S1/0 service-policy output PM-S1/0-OUT ! interface tunnel 0 qos pre-classify
Not much going on there. We match ICMP using NBAR’s built-in protocols and do absolutely nothing. I did a few pings and noticed that there were no matches to the ICMP class and that all the packets were classified as class-default . I thought that the pre-classify wasn’t working, so I cursed for a while after making no progress at all. I had no idea what was wrong.
R1#sh policy-map int s1/0
Serial1/0
Service-policy output: PM-S1/0-OUT
Class-map: ICMP (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: protocol icmp
0 packets, 0 bytes
5 minute rate 0 bps
Class-map: class-default (match-any)
467 packets, 39832 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
I need to stop here so people don’t get confused. The configuration that you see is correct; the problem was actually with the NBAR protocols in the class-map. As Jeremy Stretch notes at the bottom of this article, there’s some issue with matching NBAR protocols. I later used an extended ACL to match ICMP which worked. The same is true for the SSH stuff later. Back to the show.
Here’s what I wound up with after cursing a lot and making random configuration changes to get the blasted thing to work. Notice the order of the classes.
class-map match-any TUNNEL match protocol gre ! policy-map PM-S1/0-OUT class TUNNEL class ICMP
I know that order is going to be important, but these are matching two totally different things, so it shouldn’t matter, right? I checked out the policy-map again and saw that every packet was matching the TUNNEL class-map, and none were matching the ICMP class-map.
R1#sh policy-map int s1/0
Serial1/0
Service-policy output: PM-S1/0-OUT
Class-map: TUNNEL (match-any)
441 packets, 49392 bytes
5 minute offered rate 2000 bps
Match: protocol gre
441 packets, 49392 bytes
5 minute rate 2000 bps
Class-map: ICMP (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: access-group name ICMP
0 packets, 0 bytes
5 minute rate 0 bps
Class-map: class-default (match-any)
467 packets, 39832 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
I finally went downstairs, talked it over with my wife who is my rubber duck, and finally figured it wouldn’t hurt to change the order of the classes. Once I put ICMP before TUNNEL, it started matching. I thought that was odd, so I left ICMP and added an SSH class and put it after the TUNNEL class. I saw the ICMP match and the tunnel match, but I didn’t see a single match on SSH even though I was SSHed through (not to) the router.
R1#sh policy-map int s1/0
Serial1/0
Service-policy output: PM-S1/0-OUT
Class-map: ICMP (match-any)
252 packets, 28224 bytes
5 minute offered rate 0 bps
Match: access-group name ICMP
252 packets, 28224 bytes
5 minute rate 0 bps
Class-map: TUNNEL (match-any)
5 packets, 440 bytes
5 minute offered rate 0 bps
Match: protocol gre
5 packets, 440 bytes
5 minute rate 0 bps
Class-map: SSH (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: access-group name SSH
0 packets, 0 bytes
5 minute rate 0 bps
Class-map: class-default (match-any)
547 packets, 46588 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
When I moved SSH above TUNNEL, it started incrementing as it should. The best that I can tell is that both the original packet and the GRE packet are being evaluated when pre-classification is enabled. Since all the packets in the lab are going over a GRE tunnel, GRE will always be matched if you assess before everything else.
For the record, I did this lab twice – once with the GRE tunnel encrypted and once without encryption. The results of the pre-classification were the same in both attempts; GRE matches every time.
Send any ROUTE class vouchers questions my way.
ONT Notes – AutoQoS
- AutoQoS benefits
- Automates QoS for most deployments
- Protects business-critical apps to maximize availability
- Simplifies QoS deployments
- Reduces configuration errors
- Cheaper, faster, and simpler deployments
- Follows DiffServ
- Allows complete control over QoS configs
- Allows modification of auto-generated configs
- AutoQoS phases of evolution
- AutoQoS VOIP – Early version that configures the basics without discovery
- AutoQoS for Enterprise – Second version that only runs on routers and uses two-step process
- Autodiscovery using NBAR
- Generation of class maps
- AutoQoS key elements
- Application classification
- Policy generation
- Configuration
- Monitoring and reporting
- Consistency
- Interfaces that you can configure AutoQoS on
- Serial ifs with PPP and HDLC
- FR point-to-point subifs (NOT multipoint)
- ATM point-to-point subifs
- FR-to-ATM links
- Prerequsites
- No Qos policy already configured on if
- CEF enabled on if
- Correct bandwidth configured on if
- IP address on low-speed if
- Configuring AutoQoS Enterprise on a router (NOT a switch)
- auto qos discovery – begins discovery process
- auto qos – generates and applies MQC-based policies
- Configuring AutoQoS VOIP
- auto qos voip [ trust | cisco-phone ]
- Verifying AutoQoS on router
- show auto discovery qos – get autodiscovery results
- show auto qos – examine configuration generated
- Number of classes
- Classification options
- Marking options
- Queuing mechanisms
- Other QoS mechanisms
- If, subif, PVC where policy is applied
- show policy-map interface – look at if stats
- Verify AutoQoS VOIP
- show auto qos
- show policy-map interface
- show mls qos maps – shows CoS to DSCP mappings
- Possible issues with AutoQoS
- Too many traffic classes – manually consolidate some
- Configuration doesn’t change – rerun AutoQoS
- Configuration may not fit your situation – fine-tune it by hand
- Fine-tuning AutoQoS
- Use QPM
- CLI
- copy policy into editor, change, reapply
- AutoQoS can match on characteristics besides ACLs and NBAR
- match input interface
- match cos
- match ip precedence
- match ip dscp
- match ip rtp
ONT Notes – Pre-classify and End-to-end QoS
- VPNs (Didn’t ISCW cover this?)
- Provide
- Confidentiality
- Integrity
- Authentication
- Types
- Remote-access
- Client-initiated
- NAS-initiated
- Site-to-site
- LAN-to-LAN
- Extranet
- Remote-access
- Provide
- L3 Tunneling protocols
- GRE
- IPSec
- Pre-classify allows traffic to be classified before being sent across a tunnel or crypto-ed.
- qos pre-classify
- Provides a view into the original IP headers
- To classify on pre-tunnel header, apply the policy to the tunnel interface WITHOUT pre-classify.
- To classify on post-tunnel header, apply the policy to the physical interface WITHOUT pre-classify.
- To classify on pre-tunnel header, apply the policy to the physical interface WITH pre-classify.
- SLA – agreement with provider to guarantee QoS mechanisms across their network based on your markings.
- Assures availability, loss, throughput, delay, and jitter.
- End-to-end QoS
- To be effective, each hop in the path must have QoS configured similarly.
- Necessary in three locations
- Campus – within the customer network
- The edges – customer facing the provider, provider facing customer
- On the provider network
- QoS tasks
- Campus access switches
- Speed/duplex settings
- Classification
- Trust
- Phone/access switch configs
- Multiple queues on switch ports, including priority for VOIP
- Campus distribution
- L3 policing and marking
- Multiple queues on switch ports, including priority for VOIP
- WRED
- WAN edge
- SLA definitions
- LLQ
- LFI
- WRED
- Shaping
- Provider cloud
- Capacity planning
- PHB
- LLQ
- WRED
- Campus access switches
- Enterprise campus QoS implementation
- Implement multiple queues to avoid congestion
- Assign VOIP and video to highest priority queue
- Esablish trust boundaries
- Use policing to rate-limit excess traffic
- Use hardware QoS when possible
- Control Plane Policing (CoPP)
- Applies QoS policy to traffic destined for the router
- Routing protocols
- Management protocols
- Can be used to avoid DOS attacks
- Applied to control-plane in global config
- Applies QoS policy to traffic destined for the router
ONT Notes – Congestion Avoidance, Policing, Shaping, and Link Efficiency
- Tail drop drawbacks
- TCP synchronization – Dropping TCP packets from different flows can cause them all to window down and back up again at the same time in cycles.
- TCP starvation – Non-TCP or aggressive flows can starve everyone else out when TCP throttles back.
- No differentiated drop – Tail drop doesn’t care who you are, so you get dropped if the queue is full.
- RED – Random Early Detection
- Avoids tail drop by randomly dropping packets from the queue before it gets full
- Only dropped TCP flows slow down instead of everyone who has sent a packet since the queue filled
- Queues are smaller.
- Link utilization is more efficient
- Configured with
- Minimum threshold – start dropping when the queue is this size
- Maximum threshold – if the queue is this big, start tail dropping
- Mark probability denominator (MPD) – 1/MPD is the ratio of packets to drop when between the thresholds
- WRED – Weighted RED
- Based on IP precedence or DSCP values
- Less-important packets are dropped more aggressively than important packets
- Applied to an interface, VC or a class within a policy map
- CBWRED – Class based WRED
- Configured with CBWFQ
- Policing
- Limits subrate bandwidth (give you 100kbps on a T1)
- Limits traffic of certain applications
- Any traffic that exceeds police is dropped or re-classified; it’s a hard limit
- Inbound or outbound
- Shaping
- Sets a limit but buffers any in excess
- Requires memory to store the buffer
- Buffers = delay and/or jitter
- Outbound only
- Can respond to network signals like BECNs and FECNs
- Token and bucket
- The queue is a bucket; if a byte of data needs to be sent, it needs a token.
- If there are enough tokens, the traffic is considered conforming.
- If there aren’t enough tokens, the traffic is considered exceeding, which triggers the drop (policing), re-classify (policing), or buffer (shaping).
- Frame relay traffic shaping (FRTS)
- Only controls frame relay traffic
- Applied on subif or DLCI
- Support fragmentation and interleaving
- Reacts to FECNs and BECNs
- Compression
- Removed redundancy and patterns in data
- Less data = less latency
- Hardware compression or hardware-assisted compression does not involve the main CPU
- Software compression does
- Payload compression
- Header compression
- Link fragmentation and interleaving
- Small data might be waiting for larger data pieces to finish sending
- Chunks data into smaller fragments so they don’t have to wait
- Interleaving shuffles flows in the Tx queue