AutoQoS Overview

Great presentation from Cisco on AutoQoS

Advertisements

Policy Based Routing

Policy Based Routing (PBR)

Policy-based routing, generally referred to as “policy routing”, is the use of route maps to determine the path a packet will take to get to its final destination.

* I remember the PBR lab in the CCNP Route exam. The requirement was to redirect a users machine via a slow WAN link. This involving setting their next hop IP to that of the 56k WAN link, as apposed to the 2Mbps Serial WAN link. Nice!

* For QoS purposes, traffic can be “marked” by policy routing in order to give different levels of service to various classes of traffic.

PBR Rules

  • Policy routing doesn’t affect the destination of the packet, but does affect the path that is taken to get there.
  • Policy routing can forward traffic based on the source IP address or the destination IP address (with the use of an extended ACL).
  • Policy routing can be configured globally or on a per-interface level.
  • If a packet doesn’t match any of the specific criteria in a route map, or does match a line that has an explicit deny statement, the data is sent to the routing process and will be processed normally.

Applying policy routing on an interface affects only packets arriving on that interface – in this case, Serial0.

R2(config)#int s0
R2(config-if)#ip policy route-map CHANGE_NEXT_HOP

Applying the policy globally applies the route map to packets generated on the router, not on all packets received on all interfaces.

R2(config)#ip local policy route-map CHANGE_NEXT_HOP

Verify either or both with show ip policy.

Chris Bryant Tip: If you don’t want to route packets that don’t match a route-map clause, the set command must be used to send those packets to the null0 interface. Naturally, this set command should be the final set command in the route map.

Route Map Configuration

1. Create an ACL to identify the traffic. (Standard or Extended where relevant)

R2(config)#access-list 32 permit host 20.4.4.4

2. Create Route Map with intuitive name.

R2(config)#route-map EXAMPLE permit 10
R2(config-route-map)#match ip address 29
R2(config-route-map)#set ip next-hop 40.1.1.1
R2(config-route-map)#route-map EXAMPLE deny 20
R2(config-route-map)#match ip address 30

3. Apply route map under interface or globally (Where applicable!)

R2(config)#int s0
R2(config-if)#ip policy route-map CHANGE_NEXT_HOP

Redistribution: Route Tagging

Redistribution: Route Tagging

“tag Tag value for destination routing protocol”

Tagging routes can help you prevent some big nasty routing loops, especially with 2-way redistribution. You can tag routes with a numeric value as they’re redistributed, and then prohibit routes with that same value from being “re-redistributed” back into the original routing protocol.

Example: Tagging routes with a value of 10 that are being redistributed from RIP into OSPF:

R1(config)#route-map RIP2OSPF permit 10
R1(config-route-map)#set tag 10

The redistribution config:

R1(config)#router ospf 1
R1(config-router)#redistribute rip route-map RIP2OSPF subnets
R1(config-router)#redistribute connected subnets

You won’t see tag values in the routing table, but you will see them in the extended show ip route command with the network number specified.

R3#show ip route 2.2.2.0
Routing entry for 2.2.2.0/24
Known via "ospf 1", distance 110, metric 20
Tag 10, type extern 2, forward metric 64
Last update from 172.13.13.1 on Serial1, 00:00:43 ago
Routing Descriptor Blocks:
* 172.13.13.1, from 172.13.13.1, 00:00:43 ago, via Serial1
Route metric is 20, traffic share count is 1

The following config will prevent any routes with the tag 10 from being redistributed from OSPF back into RIP, while allowing any untagged routes to be redistributed and tagged with 20.

R1(config)#route-map OSPF2RIP deny 10
R1(config-route-map)#match tag 10
R1(config-route-map)#route-map OSPF2RIP perm 20
R1(config-route-map)#set tag 20

So we use ‘tagging’ to simply mark a route learned via redistribution and then ‘do something’ (Permit or Deny) to it using a route map.

Redistribution: Route Maps

Redistribution: Route Maps

Using Route Maps To Change Route Values And Attributes

Distribute-lists are a powerful tool in our route redistribution toolbox – but sometimes we’ll want to do more than simply permit or deny routes to be advertised and redistributed. Sometimes we’ll want to set different metrics for different routes, and maybe even change an OSPF external route type or two – and we’ll do that with route maps.

Let’s take a look at the mechanics of route map operation:

  • Route maps are somewhat similar to access-lists.
  • They both come to a basic decision of “permit” or “deny”.
  • Route lists give us additional power over the data beyond just a simple “transmit” or “don’t transmit”.
  • With route maps, we can actually change route attributes.

Route Map Example

1. For source address 20.1.1.1 only, change next hop IP address to 10.1.1.1

R2(config)#access-list 17 permit host 20.1.1.1
R2(config)#route-map ?
WORD Route map tag
R2(config)#route-map CHANGE_NEXT_HOP ?
<0-65535> Sequence to insert to/delete from existing route-map entry
deny Route map denies set operations
permit Route map permits set operations
<cr>
R2(config)#route-map CHANGE_NEXT_HOP permit ?
<0-65535> Sequence to insert to/delete from existing route-map entry
<cr>
R2(config)#route-map CHANGE_NEXT_HOP permit 10
R2(config-route-map)#match ip address 17
R2(config-route-map)#set ip next-hop 10.1.1.1

Key Points with Route Map

  1. The only factor that a standard ACL can match is the source IP address.
  2. Route map statements can be given a sequence number, and this is a great help when you want to go back to an existing route map and add statements. You do not have to assign a sequence number, and if you don’t, the first statement you enter will be numbered “10” and each statement after that will have a sequence number that increments by 10 from the previous statement.
  3. The <cr> indicates that this command could be entered just as it is, without a permit or deny statement. If you do not specify permit or deny, a route map statement will default to “permit”.

Example requirement for the use of ‘route maps’

  • 2.2.2.0 — Double the default seed metric and set the route to OSPF external type 1.
  • 22.2.0.0 – Keep the default seed metric, set the route to OSPF external type 1.
  • 222.2.2.0 — Do not redistribute this route at all.
  • All future redistributed routes — allow redistribution with the default seed metric and OSPF route type.

1. Identify each network to be filtered using ACLs.

2. Create an overall route map with an intuitive name, such as RIP2OSPF. Using ‘match’ and ‘set’ statements, we work through the requirement a point at a time.

For our 1st requirement, here is what we would need to do:

access-list 2 permit 2.2.2.0 0.0.0.255

route-map RIP2OSPF permit 10

match ip address 2

set metric 40 (20 is the default for redistributed/external OSPF)

set metric-type type-1

Simple as that! 🙂

For our second requirement we will use the same route-map with a different sequence number:

route-map RIP2OSPF permit 20

Same as before, but based on the specific requirement.

Remember also a ‘catchall’ clause is required at the very end of your route map:

route-map RIP2OSPF permit 50 (Last sequence)

Route maps are mainly used in BGP, but can be used with IGPs in the manner.

‘show route-map’ is great for verification your map:

R1#show route-map
route-map RIP2OSPF, permit, sequence 10
Match clauses:
ip address (access-lists): 2
Set clauses:
metric 40
metric-type type-1
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, permit, sequence 20
Match clauses:
ip address (access-lists): 22
Set clauses:
metric-type type-1
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, deny, sequence 30
Match clauses:
ip address (access-lists): 44
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, permit, sequence 40
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes

The next step is to now apply the route-map. 🙂

Example of applying route map for redistribution from RIP into OSPF:

R1(config)#router ospf 1

R1(config-router)#redis rip subnets route-map RIP2OSPF

Or ‘redis rip route-map RIP2OSPF subnets’ either way round will do the job. 🙂

Redistribution: Using Distribute Lists to Control Redistribution

Redistribution: Using Distribute Lists to Control Redistribution

distribute-list = filter networks in routing updates (From IOS Help)

Once you perform route redistribution, you’ll often find that you need to fine-tune the process by allowing some routes to be redistributed while preventing redistribution of other routes. We can do that with distribute lists.

A distribute-list uses an ACL to define the routes to be redistributed – and explicitly or implicitly prohibited from redistribution.

Example for redistribution into OSPF to filter out networks 8.1.1.0/24 and 9.1.1.0/24:

R1(config)#access-list 17 deny 8.1.1.0 0.0.0.255
R1(config)#access-list 17 deny 9.1.1.0 0.0.0.255
R1(config)#access-list 17 permit any

We would assume the command is completed in OSPF as follows:

R1(config-router)#distribute-list 17 out serial0
% Interface not allowed with OUT for OSPF

But OSPF will not work in this manner, as the routing updates are in the format of LSAs, where as EIGRP and RIP aren’t. Hence we can’t filter LSAs as such.

So….

We need to specify a protocol as apposed to an interface.

Example:

R1(config-router)#distribute-list 17 out rip

This will filter routes going into OSPF, that match ACL 17 and originate from RIP.

NOTE: OSPF will converge extremely quickly and this will/should show in the best routes asap.

***show ip protocols will also show any applied distribute lists and their direction!***

RIP Example:

R1(config)#router rip
R1(config-router)#distribute-list 17 ?
in Filter incoming routing updates
out Filter outgoing routing updates
R1(config-router)#distribute-list 17 in ?
BRI ISDN Basic Rate Interface
Ethernet IEEE 802.3
Loopback Loopback interface
Null Null interface
Serial Serial
<cr>
R1(config-router)#distribute-list 17 in ethernet0

Redistribution: Passive Interfaces

Not really specifically a redistribution concept, but categorised by Chris Bryant as redistribution so what the hell.

Passive Interfaces

Passive interfaces can be a big help in controlling routing updates and or/ routing control traffic, depending on which protocol you’re dealing with:

RIP: Passive interfaces do not send routing updates, but will accept them. RIP adjacencies aren’t affected by passive interfaces since RIP doesn’t have adjacencies in the first place. A RIP passive interface will not send routing updates, but it will accept them.

EIGRP: Hellos aren’t sent, so no adjacency can be formed via a passive interface. If an adjacency exists on an interface that is then made passive, the adjacency is dropped. A subnet running a passive interface can be advertised.

EIGRP passive interfaces do not send Hellos, therefore the neighbour relationship on this specific interface is torn down.

EIGRP passive interfaces do not send Hellos, but the subnet running on that passive interface can still be advertised via the network command.

OSPF: Passive interfaces do not send OSPF Hellos, so again no adjacency can be formed, and existing adjacencies are lost on interfaces that are then configured as passive. Additionally, the subnet running on the passive interface will be advertised as a stub network.

Just as with EIGRP, the adjacency through the now passive interface is lost, but the subnet is still advertised via the network command.

You can set all interfaces on a router as passive for a given protocol with the passive-interface default command.

R3(config)#router ospf 1
R3(config-router)#passive-interface default

To set the interfaces back to their default, just use the no passive-interface default command.

R3(config-router)#no passive-interface default

Redistribution: ip default-gateway vs. ip default-network

ip default-gateway vs. ip default-network

The ip default-network command can be used to inject a default route into your routing process.

If the router has an interface directly connected to the network specified with this command, the router will generate a default route and send that route to its neighbor routers.

This command can be a little tricky to use, and it works differently with different protocols. It’s easy to get ip default-network and ip default-gateway mixed up.

They’re both used to generate a default route. The key difference is that ip default-gateway is used when IP routing is off, while ip default-network is used when IP routing is on.