pbr in gns3...

i was having trouble earlier with pbr, determining path choice with a route map... thought i was losing my mind... see this:

http://www.cisco.com/en/US/docs/ios/12_0/qos/configuration/guide/qcpolicy.html

according to this document pbr is supported in cef based switching since 12.0... the question is how well is cef supported in gns3 running ios... my guess is gns3 may choke a little here... i'm the last one to call out gns3; it's the best thing that ever happened to people like us, but...

here's the example:

r1#trace 6.6.6.6
Type escape sequence to abort.
Tracing the route to 6.6.6.6
VRF info: (vrf in name/id, vrf out name/id)
  1 10.1.1.2 32 msec
    10.1.2.2 20 msec

r1 has a choice of two paths in this ospf/eigrp redistributed topology to get to the far end loopback 6.6.6.6... both paths are supported in the trace... i want to determine one path...

so i set up a pbr on r1 to force the path through r2...

r1(config)#access-list 1 permit 6.6.6.6
r1(config)#access-list 1 permit any
r1(config)#do sh access-list
Standard IP access list 1
    10 permit 6.6.6.6
    20 permit any

r1(config)#route-map this
r1(config-route-map)#match ip add 1
r1(config-route-map)#set ip next-hop 10.1.1.2
r1(config-route-map)#exit
r1(config)#int f0/0
r1(config-if)#ip policy route-map this
r1(config-if)#

r1#ping 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/20 ms
r1#sh route-map
route-map this, permit, sequence 10
  Match clauses:
    ip address (access-lists): 1
  Set clauses:
    ip next-hop 10.1.1.2
  Policy routing matches: 0 packets, 0 bytes


no matches...

turn off cef...

r1(config)#no ip cef
r1(config)#end
r1#ping 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/13/20 ms
r1#sh route-map
route-map this, permit, sequence 10
  Match clauses:
    ip address (access-lists): 1
  Set clauses:
    ip next-hop 10.1.1.2
  Policy routing matches: 0 packets, 0 bytes

still no matches... so i turned cef back on...

if i debug the policy i get no hits as well...

r1#debug ip policy
Policy routing debugging is on
r1#ping 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/24 ms

nothing...

then there's this... ip local policy route-map (route-map name) see link above...

r1(config)#ip local policy route-map this
r1(config)#end
r1#
*Oct 28 12:34:29: %SYS-5-CONFIG_I: Configured from console by console
r1#ping 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/13/20 ms
r1#
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6, len 100, policy match
*Oct 28 12:34:33: IP: route map this, item 10, permit
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6 (FastEthernet0/0), len 100, policy routed
*Oct 28 12:34:33: IP: local to FastEthernet0/0 10.1.1.2
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6, len 100, policy match
*Oct 28 12:34:33: IP: route map this, item 10, permit
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6 (FastEthernet0/0), len 100, policy routed
*Oct 28 12:34:33: IP: local to FastEthernet0/0 10.1.1.2
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6, len 100, policy match
*Oct 28 12:34:33: IP: route map this, item 10, permit
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6 (FastEthernet0/0), len 100, policy routed
*Oct 28 12:34:33: IP: local to FastEthernet0/0 10.1.1.2
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6, len 100, policy match
*Oct 28 12:34:33: IP: route map this, item 10, permit
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6 (FastEthernet0/0), len 100, policy routed
*Oct 28 12:34:33: IP: local to FastEthernet0/0 10.1.1.2
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6, len 100, policy match
*Oct 28 12:34:33: IP: route map this, item 10, permit
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6 (FastEthernet0/0)
r1#, len 100, policy routed
*Oct 28 12:34:33: IP: local to FastEthernet0/0 10.1.1.2

now i don't feel like i'm losing my goddamn mind...

r1#sh route-map
route-map this, permit, sequence 10
  Match clauses:
    ip address (access-lists): 1
  Set clauses:
    ip next-hop 10.1.1.2
Nexthop tracking current: 0.0.0.0
10.1.1.2, fib_nh:0,oce:0,status:0

  Policy routing matches: 5 packets, 500 bytes

that's a big difference...

r1#trace 6.6.6.6
Type escape sequence to abort.
Tracing the route to 6.6.6.6
VRF info: (vrf in name/id, vrf out name/id)
  1 10.1.1.2 8 msec 4 msec 8 msec
  2 192.168.1.2 8 msec 8 msec 8 msec
  3 172.16.1.1 12 msec 40 msec *

no big deal... i still love gns3...

quote of the day... qos, pbr, tos, historically...

according to odom route ocg...

an example of one of my anki cards...

Quality of service (QoS) refers to the entire process of how the network infrastructure can choose to apply different levels of service to different packets. For example, a router may need to keep delay and jitter (delay variation) low for VoIP and Video over IP packets, because these interactive voice and video calls only work well when the delay and jitter
are held very low. So, the router might let VoIP packets bypass a long queue of data packets that might be waiting to exit an interface, giving the voice packet better (lower) delay and jitter. Most QoS designs mark each packet with a different value inside the IP header, for the
purpose of identifying groups of packets–a service class–that should get a particular QoS treatment. For instance, all VoIP packets could be marked with a particular value so that the router can then find those marked bits, know that the packet is a VoIP packet due to that marking, and apply QoS accordingly. Although the most commonly used QoS marking tool today is Class-Based Marking, in the past, PBR was one of the few tools that could be used for this important QoS function
of marking packets. PBR still supports marking; however, most modern QoS designs ignore PBR’s marking capabilities.
 

Before discussing PBR’s marking features, a little background about the historical view of the IP header’s type of service (ToS) byte is needed. The IP header originally defined a ToS byte whose individual bits have been defined in a couple of ways over the years. One such definition used the first three bits in the ToS byte as a three-bit IP Precedence (IPP) field, which could be used for generic QoS marking, with the higher values generally implying a better QoS treatment. Back in the 1990s, the ToS byte was redefined as the Differentiated Services (DS) byte, with the first six bits defined as the Differentiated Service Code Point (DSCP). Most QoS implementations today revolve around setting the DSCP field. PBR supports setting the older QoS marking fields—the IP Precedence (IPP) and the entire ToS byte—using commands set ip precedence value and set ip tos value, respectively, in the route map. To configure packet marking, configure PBR as normal, but add a set command that defines the field to be marked and the value.

and a repost of this outstanding graphic...