OER/PFR Part 6

This is hopefully my next to last blog post on OER. 🙂

Up to this point, OER has influenced outbound traffic selection. 12.4(9)T added the BGP Inbound Optimization feature. OER does this by route withdrawal, AS_PATH prepending and setting communities which allow the neighbor AS to prepend or set local preference based on the community values. The inbound options are more limited as it only supports passive monitoring. OER learns inside prefixes based on what is advertised to eBGP peers from the border routers. This can cause a weird issue after routes have been controlled where you are advertising a route learned from one BR back out to the same AS. Technically, the other AS drops the advertisement, but it still gets reported to the MC as an inside route. It’s best to have the outside routers set no-export community in a route-map to the eBGP peers.

A few lessons (bugs?) I’ve learned in my testing on 12.4(15)T14:
1) Using match [traffic-class | ip address ] prefix-list inside in an oer-map doesn’t work like the documentation shows. When I configured it, the matching routes were put in the external database instead. match oer learn inside works fine.
2) Oer-maps can’t contain both inside and outside sequences. Everything either ends up in the external or internal prefix database, depending on the order you configured them in the oer-map.

Once you have an OER topology up and running, adding BGP inbound optimization is just a few more commands. Most of this is optional, but it was included to show some of the features.


R3CoreMC#conf t
R3CoreMC(config)#oer master
R3CoreMC(config-oer-mc)#border 1.1.1.1
R3CoreMC(config-oer-mc-br)#interface s 0/0 ext
R3CoreMC(config-oer-mc-br-if)#maximum utilization receive percentage 65
R3CoreMC(config-oer-mc-br-if)#border 2.2.2.2
R3CoreMC(config-oer-mc-br)#interface s 0/0 ext
R3CoreMC(config-oer-mc-br-if)#maximum utilization receive percentage 65
R3CoreMC(config-oer-mc-br-if)#oer master
R3CoreMC(config-oer-mc)#max range receive percent 20
R3CoreMC(config-oer-mc)#learn
R3CoreMC(config-oer-mc-learn)#inside bgp

The command to inspect the inside prefix database is slightly different. The control is verified by inspecting the bgp table of the eBGP peers. R1 has prepended AS100 once to the advertisement.


R3CoreMC#show oer master prefix inside
OER Prefix Statistics:
Prefix (inside) State Time Curr BR CurrI/F Protocol
PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos
ActSDly ActLDly ActSUn ActLUn EBw IBw
——————————————————————————–
3.0.0.0/24 INPOLICY 0 2.2.2.2 Se0/0 BGP
104 108 0 0 4752 4763
N N N N 140 45
4.0.0.0/24 INPOLICY* 0 1.1.1.1 Se0/0 U
101 98 0 0 4591 4831
N N N N 142 40

R9#show ip bgp 3.0.0.0/24
BGP routing table entry for 3.0.0.0/24, version 27
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
2
100
110.0.0.10 (metric 2) from 119.0.0.1 (101.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 95.0.0.1, Cluster list: 101.1.1.1
100 100
19.0.0.1 from 19.0.0.1 (1.1.1.1)
Origin IGP, localpref 100, valid, external

Another way to influence inbound traffic is by setting a community so the eBGP peers can prepend or set a downgraded local preference.


R1B1#conf t
R1B1(config)#router bgp 100
R1B1(config-router)#neighbor 19.0.0.9 send-community standard

R2B2#conf t
R2B2(config)#router bgp 100
R2B2(config-router)#neighbor 210.0.0.10 send-community standard

R3CoreMC#conf t
R3CoreMC(config)#oer master
R3CoreMC(config-oer-mc)#border 1.1.1.1
R3CoreMC(config-oer-mc-br)#int s 0/0 e
R3CoreMC(config-oer-mc-br-if)#downgrade bgp community 100:1234
R3CoreMC(config-oer-mc-br-if)#border 2.2.2.2
R3CoreMC(config-oer-mc-br)#int s 0/0 ext
R3CoreMC(config-oer-mc-br-if)#downgrade bgp community 100:1234

R3CoreMC#show oer master prefix inside
OER Prefix Statistics:
Prefix (inside) State Time Curr BR CurrI/F Protocol
PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos
ActSDly ActLDly ActSUn ActLUn EBw IBw
——————————————————————————–
3.0.0.0/24 INPOLICY* 0 2.2.2.2 Se0/0 BGP
76 76 0 0 2959 2959
N N N N 168 19
4.0.0.0/24 HOLDDOWN 58 1.1.1.1 Se0/0 BGP
104 102 0 0 4469 4848
N N N N 152 38

AS 200 can now match that community to set a poor local preference or prepend an ASN.


R9#conf t
R9(config)#ip community-list 1 permit 100:1234
R9(config)#route-map DOWNGRADE
R9(config-route-map)#match community 1
R9(config-route-map)#set local-preference 5
R9(config-route-map)#route-map DOWNGRADE permit 20
R9(config)#router bgp 200
R9(config-router)#neighbor 19.0.0.1 route-map DOWNGRADE in

R10#conf t
R10(config)#ip community-list 1 permit 100:1234
R10(config)#route-map DOWNGRADE
R10(config-route-map)#match community 1
R10(config-route-map)#set local-preference 5
R10(config-route-map)#route-map DOWNGRADE perm 20
R10(config-route-map)#router bgp 200
R10(config-router)#neighbor 210.0.0.2 route-map DOWNGRADE in

The results are checked on R9. The community is visible and the local preference is set to 5. R9 will use the internal route learned from R10 as the next-hop. Once the downgrade community is configured for a BR’s interface, OER automatically have that BR cease prepending as a means of control.


R9#show ip bgp 4.0.0.0
BGP routing table entry for 4.0.0.0/24, version 30
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Flag: 0x9C0
Advertised to update-groups:
2
100
110.0.0.10 (metric 2) from 119.0.0.1 (101.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 95.0.0.1, Cluster list: 101.1.1.1
100
19.0.0.1 from 19.0.0.1 (1.1.1.1)
Origin IGP, localpref 5, valid, external
Community: 100:1234

OER/PFR Part 5

OER also has the ability to control/inject routes based on the BGP table. Just like static routes it can inject a more specific route or it can control path selection through the use of the local preference attribute. The basic configuration is the same as with static routes, although there are a couple of caveats when using BGP.

I’m using the same topology as before. The inside network is BGP AS 100 and the outside network is AS 200. R3 & R4 are route-reflectors. AS 200 is configured to send only a default route to AS 100. I did swap the 7200 routers out for 3725s. I generally use 7200 routers in my GNS3 lab because they are the only type unaffected by the multicast bug. 99.9% of the time they are better than other routers for CCIE labbing. The only downside I’ve found to them is entering NTP commands causes the routers to lock up. For an OER lab, 3725s are better since 7200 border routers prevent you from learning based on delay. Other than those two specific cases, I’d always recommend 7200s since multicast is more of a core topic.

NOTE: As it turns out, 3725s don’t work for learning delay either. 😦

topology

The first caveat with BGP concerns default routes. If more specific routes don’t exist in the BGP table, you can’t aggregate based on the bgp table. The OER database will be empty.


R3CoreMC#conf t
R3CoreMC(config)#oer master
R3CoreMC(config-oer-mc)#learn
R3CoreMC(config-oer-mc)#mode route metric bgp local-pref 5123
R3CoreMC(config-oer-mc-learn)#throughput
R3CoreMC(config-oer-mc-learn)#aggregation-type prefix-length 24

Give it a few minutes and everything is under control.


R3CoreMC#show oer master prefix
OER Prefix Statistics:

Prefix State Time Curr BR CurrI/F Protocol
PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos
ActSDly ActLDly ActSUn ActLUn EBw IBw
ActSJit ActPMOS ActSLos ActLLos
——————————————————————————–
90.0.0.0/24 INPOLICY 0 1.1.1.1 Se0/0 BGP
69 69 0 0 3213 3213
U U 0 0 65 4
N N
95.0.0.0/24 INPOLICY 0 2.2.2.2 Se0/0 BGP
87 84 0 0 4538 4662
U U 0 0 101 5
N N
100.1.1.0/24 HOLDDOWN 64 2.2.2.2 Se0/0 BGP
38 38 0 0 0 0
U U 0 0 32 2
N N
101.1.1.0/24 INPOLICY 0 1.1.1.1 Se0/0 BGP
83 76 0 0 4089 4199
U U 0 0 53 2
N N

R3CoreMC#show oer master border detail
Border Status UP/DOWN AuthFail Version
2.2.2.2 ACTIVE UP 00:25:01 0 2.1

External Capacity Max BW BW Used Load Status Exit Id
Interface (kbps) (kbps) (kbps) (%)
——— ——– —— ——- ——- —— ——
Se0/0 Tx 384 288 196 51 UP 4
Rx 211 6 1
——————————————————————————–
Border Status UP/DOWN AuthFail Version
1.1.1.1 ACTIVE UP 00:25:01 0 2.1

External Capacity Max BW BW Used Load Status Exit Id
Interface (kbps) (kbps) (kbps) (%)
——— ——– —— ——- ——- —— ——
Se0/0 Tx 384 288 180 46 UP 3
Rx 211 13 3

R2B2#show oer border routes bgp
BGP table version is 77, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
OER Flags: C – Controlled, X – Excluded, E – Exact, N – Non-exact, I – Injected

Network Next Hop OER LocPrf Weight Path
*> 95.0.0.0/24 210.0.0.10 CEI 0 200 i
*> 100.1.1.0/24 210.0.0.10 CEI 0 200 i

Now for our next BGP caveat. Look at one of the routes that OER injected. It has the no-export community set to prevent these routes from leaving the AS. This means that send-community has to be configured inside the AS.


R2B2#sh ip bgp 100.1.1.0
BGP routing table entry for 100.1.1.0/24, version 77
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
Advertised to update-groups:
2
200, (injected path from 0.0.0.0/0)
210.0.0.10 from 210.0.0.10 (95.0.0.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: no-export

Just to bring everything together I’m going to define an application with a learn-list and apply a separate control policy via an oer-map. I slightly modified the ACL and prefix-list so it would only match R9’s traffic.


R3CoreMC#sh ip access-lists
Extended IP access list DSCP_AGG
10 permit ip any any dscp 9
R3CoreMC#sh ip prefix-list
ip prefix-list DSCP_FILTER: 1 entries
seq 5 permit 90.0.0.0/24
R3CoreMC#conf t
R3CoreMC(config)#oer master
R3CoreMC(config-oer-mc)#learn
R3CoreMC(config-oer-mc-learn)#list seq 1 refname SECRET_SAUCE
R3CoreMC(config-oer-mc-learn-list)#traffic-class access-list DSCP_AGG filter DSCP_FILTER
R3CoreMC(config-oer-mc-learn-list)#throughput
R3CoreMC(config-oer-mc-learn-list)#oer-map MAP 10
R3CoreMC(config-oer-map)#match oer learn list SECRET_SAUCE
R3CoreMC(config-oer-map)#set mode select-exit best
R3CoreMC(config-oer-map)#set periodic 90
R3CoreMC(config-oer-map)#set backoff 180 180
R3CoreMC(config-oer-map)#set holddown 180
R3CoreMC(config-oer-map)#oer master
R3CoreMC(config-oer-mc)#policy-rules MAP
R3CoreMC#show oer master traffic-class
OER Prefix Statistics:

DstPrefix Appl_ID Dscp Prot SrcPort DstPort SrcPrefix
Flags State Time CurrBR CurrI/F Protocol
PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos EBw IBw
ActSDly ActLDly ActSUn ActLUn ActSJit ActPMOS
——————————————————————————–
90.0.0.0/24 N 9 256 N N 0.0.0.0/0
HOLDDOWN 98 1.1.1.1 Se0/0 PBR
U U 0 0 3639 3639 83 0
U U 0 0 N N

95.0.0.0/24 N defa N N N N
INPOLICY @71 2.2.2.2 Se0/0 BGP
94 94 0 0 6165 6165 53 5
U U 0 0 N N

100.1.1.0/24 N defa N N N N
HOLDDOWN 69 1.1.1.1 Se0/0 BGP
50 50 0 0 0 0 46 2
U U 0 0 N N

101.1.1.0/24 N defa N N N N
HOLDDOWN 59 2.2.2.2 Se0/0 BGP
60 60 0 0 0 0 41 2
U U 0 0 N N

And finally, I remove the default route and prefix filters from AS200 so AS100 has a full view of the bgp table and change the aggregation type to bgp.


R3CoreMC#sh oer master traffic-class
OER Prefix Statistics:
DstPrefix Appl_ID Dscp Prot SrcPort DstPort SrcPrefix
Flags State Time CurrBR CurrI/F Protocol
PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos EBw IBw
ActSDly ActLDly ActSUn ActLUn ActSJit ActPMOS
——————————————————————————–
90.0.0.0/24 N 9 256 N N 0.0.0.0/0
HOLDDOWN 14 2.2.2.2 Se0/0 PBR
U U 0 0 4737 4737 74 0
U U 0 0 N N

95.0.0.0/24 N defa N N N N
INPOLICY @6 1.1.1.1 Se0/0 BGP
101 101 0 0 4431 4431 82 4
169 169 0 0 N N

100.1.1.0/24 N defa N N N N
INPOLICY @1 2.2.2.2 Se0/0 BGP
126 126 0 0 3998 3998 48 2
65 65 0 0 N N

101.1.1.0/24 N defa N N N N
HOLDDOWN 8 1.1.1.1 Se0/0 BGP
119 119 0 0 3318 3318 54 2
U U 0 0 N N

Instead of injecting more specific routes, OER is now using local preference to influence route selection. You can actually see this behavior when injecting routes with BGP also. Once the route is injected, OER will “double influence” the path selection by modifying the local preference on the injected route.

R3CoreMC#sh ip bgp quote-regexp ^200$
BGP table version is 123, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path
* i90.0.0.0/24 24.0.0.2 0 100 0 200 i
*>i 13.0.0.1 0 100 0 200 i
*>i95.0.0.0/24 13.0.0.1 0 5123 0 200 i
*>i100.1.1.0/24 24.0.0.2 0 5123 0 200 i
*>i101.1.1.0/24 13.0.0.1 0 5123 0 200 i

IPv6 Tunneling Part 2

The next type of tunnels to cover are the multipoint tunnels. Each have their own set of requirements to configure properly outside of setting the tunnel mode.

6-to-4 (mode ipv6ip 6to4). The ipv6 address of the tunnel must embed the IPv4 tunnel source as an IPv6 address. Prefix should start with 2002.

ISATAP (mode ipv6ip isatap). Must use eui-64 prefix. Embeds the IPv4 tunnel source with the configured prefix.

IPv4-compatible (mode ipv6ip auto-tunnel). Uses the least amount of config. The tunnel address is automatically derived from the tunnel source with a /96 prefix.

As a small addition to our previous topology, each IPv6 router has a loopback interface with the address 2002:CC1E:X::X/64 where X = router number.

Convert the IPv4 loopback address to IPv6.
150.1.2.2
150.1.4.4
150.1.5.5

150/16 = 9 with a remainder of 6 IE 96 (not the number 96). 1, 2, 4, 5 all convert easily to hex values 1, 2, 4, and 5 respectively.
The converted ipv6 prefixes would be:

2002:9601:0202::/64
2002:9601:0404::/64
2002:9601:0505::/64

Configuring the tunnels and establishing basic connectivity. No tunnel destinations are needed as they are automatically known based on the address format.


R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int tun245
R2(config-if)#ipv6 address 2002:9601:202::2/64
R2(config-if)#tunnel source loopback0
R2(config-if)#tunnel mode ipv6ip 6to4
R2(config)#ipv6 route 2002::/16 tun245

R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#int tun245
R4(config-if)#ipv6 address 2002:9601:404::4/64
R4(config-if)#tunnel source loopback0
R4(config-if)#tunnel mode ipv6ip 6to4
R4(config)#ipv6 route 2002::/16 tun245

R5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#int tun245
R5(config-if)#ipv6 address 2002:9601:505::5/64
R5(config-if)#tunnel source loopback0
R5(config-if)#tunnel mode ipv6ip 6to4
R5(config)#ipv6 route 2002::/16 tun245

R2#ping 2002:9601:505::5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:9601:505::5, timeout is 2 seconds:
!!!!!

R2#ping 2002:9601:404::4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:9601:404::4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/16/28 ms

R4#ping 2002:9601:505::5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:9601:505::5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/27/36 ms

What about the loopback adapters?


Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2002:CC1E:4::4, timeout is 2 seconds:

Success rate is 0 percent (0/3)
R2#ping 2002:CC1E:5::5 repeat 3

Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2002:CC1E:5::5, timeout is 2 seconds:

Success rate is 0 percent (0/3)

What’s going on here? Remember that there are no tunnel destinations configured. IOS determines the IPv4 destination by converting the embedded address into IPv4.
cc1e:0005 and cc1e:0004 convert to 204.30.0.5 and 204.30.0.5. These addresses do not exist in our topology!!!

A debug ip packet detail reveals the issue.


R4#ping 2002:CC1E:5::5 repeat 3

Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2002:CC1E:5::5, timeout is 2 seconds:

*Feb 22 13:14:56.587: IP: s=150.1.4.4 (local), d=204.30.0.5, len 120, unroutable, proto=41.
*Feb 22 13:14:58.591: IP: s=150.1.4.4 (local), d=204.30.0.5, len 120, unroutable, proto=41.
*Feb 22 13:15:00.595: IP: s=150.1.4.4 (local), d=204.30.0.5, len 120, unroutable, proto=41.
Success rate is 0 percent (0/3)

Each router will need additional static routes.


R2(config)#ipv6 route 2002:cc1e:5::/64 2002:9601:505::5
R2(config)#ipv6 route 2002:cc1e:4::/64 2002:9601:404::4

R4(config)#ipv6 route 2002:cc1e:2::/64 2002:9601:202::2
R4(config)#ipv6 route 2002:cc1e:5::/64 2002:9601:505::5

R5(config)#ipv6 route 2002:cc1e:2::/64 2002:9601:202::2
R5(config)#ipv6 route 2002:cc1e:4::/64 2002:9601:404::4

R4#ping 2002:cc1e:2::2 repeat 3

Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2002:CC1E:2::2, timeout is 2 seconds:
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 8/14/20 ms
R4#ping 2002:cc1e:5::5 repeat 3

Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2002:CC1E:5::5, timeout is 2 seconds:
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 40/45/52 ms

ISATAP tunnels are configured much the same way. The tunnel address must be eui-64. IOS will concatenate your configured prefix + ::5efe:IPv4 address.


On each router:
R2(config)#int tun245
R2(config-if)#no ipv6 address
R2(config-if)#ipv6 address 2002:cc1e:245::/64 eui
R2(config-if)#tunnel mode ipv6ip isatap

R2#sh ipv6 int tun245
Tunnel245 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::5EFE:9601:202
No Virtual link-local address(es):
Global unicast address(es):
2001:CC1E:245::5EFE:9601:202, subnet is 2002:CC1E:245::/64 [EUI]

R2#ping 2002:CC1E:245::5EFE:9601:404

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:CC1E:245::5EFE:9601:404, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/22/36 ms
R2#ping 2002:CC1E:245::5EFE:9601:505

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:CC1E:245::5EFE:9601:505, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/19/24 ms

Now to establish full connectivity with OSPFv3.


On each router:
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config-if)#int lo100
R2(config-if)#ipv6 ospf 1 area 0
R2(config)#int tun245
R2(config-if)#ipv6 ospf 1 area 0

Wait as long as you like, the OSPF neighbors won’t form. OSPF considers the tunnel interface to be point-to-point. However, the tunnels are NBMA. That means you have to change the network type to one of the non-broadcast types and configure static neighbors.


R2#sh ipv6 ospf int tun245
Tunnel245 is up, line protocol is up
Link Local Address FE80::5EFE:9601:202, Interface ID 15
Area 0, Process ID 1, Instance ID 0, Router ID 150.1.2.2
Network Type POINT_TO_POINT, Cost: 11111
Transmit Delay is 1 sec, State POINT_TO_POINT,

R2(config-if)#ipv6 ospf network point-to-multipoint non
R2(config-if)#ipv6 ospf nei FE80::5EFE:9601:505
R2(config-if)#ipv6 ospf nei FE80::5EFE:9601:404

R4(config-if)#ipv6 ospf network point-to-multipoint non
R4(config-if)#ipv6 ospf nei FE80::5EFE:9601:505
R4(config-if)#ipv6 ospf nei FE80::5EFE:9601:202

R5(config-if)#ipv6 ospf network point-to-multipoint non
R5(config-if)#ipv6 ospf nei FE80::5EFE:9601:202
R5(config-if)#ipv6 ospf nei FE80::5EFE:9601:404

R2(config-if)#
*Feb 22 14:50:11.623: %OSPFv3-5-ADJCHG: Process 1, Nbr 150.1.4.4 on Tunnel245 from LOADING to FULL, Loading Done
*Feb 22 14:50:11.631: %OSPFv3-5-ADJCHG: Process 1, Nbr 150.1.5.5 on Tunnel245 from LOADING to FULL, Loading Done

R2(config-if)#do sh ipv6 route ospf
IPv6 Routing Table – 9 entries
Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP
U – Per-user Static route, M – MIPv6
I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary
O – OSPF intra, OI – OSPF inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2
ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2
D – EIGRP, EX – EIGRP external
O 2002:CC1E:4::4/128 [110/11111]
via FE80::5EFE:9601:404, Tunnel245
O 2002:CC1E:5::5/128 [110/11111]
via FE80::5EFE:9601:505, Tunnel245
O 2002:CC1E:245::5EFE:9601:404/128 [110/11111]
via FE80::5EFE:9601:404, Tunnel245
O 2002:CC1E:245::5EFE:9601:505/128 [110/11111]
via FE80::5EFE:9601:505, Tunnel245

R2(config-if)#do sh ipv6 ospf int tun245
Tunnel245 is up, line protocol is up
Link Local Address FE80::5EFE:9601:202, Interface ID 15
Area 0, Process ID 1, Instance ID 0, Router ID 150.1.2.2
Network Type POINT_TO_MULTIPOINT, Cost: 11111
Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT,

R2(config-if)#do ping 2002:cc1e:4::4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:CC1E:4::4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/11/16 ms
R2(config-if)#do ping 2002:cc1e:5::5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:CC1E:5::5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/18/24 ms

Last, but certainly not least, is v4-compatible. It takes only 2 lines to configure.
Note: Previous IPv6 address and OSPF commands were removed.


On each router:
R2(config-if)#tunnel source loopback0
R2(config-if)#tunnel mode ipv6ip auto-tunnel
R2#ping ::150.1.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to ::150.1.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/11/16 ms
R2#
*Feb 22 14:58:10.275: %SYS-5-CONFIG_I: Configured from console by console
R2#ping ::150.1.5.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to ::150.1.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/16/28 ms

R4#ping ::150.1.5.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to ::150.1.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/40/44 ms

IPv6 Tunneling Part 1

The first type of tunnels to cover are the point-to-point tunnels: Manual (mode ipv6ip) and IPv6 over GRE IPv4 (mode gre ip).

Manual tunnels have less encapsulation overhead but only support IPv6 as a passenger protocol. It uses IP Protocol 41.

IPv6 over GRE IPv4 tunnels have more overhead but can carry more than just IPv6 passenger protocols. It uses IP Protocol 47.

The topology I am using is a simple hub-spoke design with an IPv4 only cloud between the spokes. Don’t worry about SW1 for now. 🙂
ipv6topology

Now for the tunnel configurations. R4 R2 will use a GRE tunnel while R5 R2 will use a manual tunnel.


R2(config)#int tun24
R2(config-if)#ipv6 address 2001:cc1e:24::2/64
R2(config-if)#tunnel source lo0
R2(config-if)#tunnel destination 150.1.4.4

R2(config-if)#int tun25
R2(config-if)#ipv6 address 2001:cc1e:25::2/64
R2(config-if)#tunnel source lo0
R2(config-if)#tunnel destination 150.1.5.5
R2(config-if)#tunnel mode ipv6ip

R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#int tun24
R4(config-if)#ipv6 address 2001:cc1e:24::4/64
R4(config-if)#tunnel source lo0
R4(config-if)#tunnel destination 150.1.2.2

R5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#int tun25
R5(config-if)#ipv6 address 2001:cc1e:25::5/64
R5(config-if)#tunnel source lo0
R5(config-if)#tunnel destination 150.1.2.2
R5(config-if)#tunnel mode ipv6ip

I also applied an access-list on both of R2’s interfaces to monitor the traffic types. Then did a ping test from R4 and R5 to R2.


Before pings:

Extended IP access list 100
10 permit gre any any
20 permit 41 any any
30 permit ip any any (4 matches)

After first set of pings:
R4#ping 2001:cc1e:24::2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:24::2, timeout is 2 seconds:
!!!!!

Extended IP access list 100
10 permit gre any any (15 matches)
20 permit 41 any any
30 permit ip any any (12 matches)

After second set of pings:
R5#ping 2001:cc1e:25::2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:25::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/24/44 ms

Extended IP access list 100
10 permit gre any any (15 matches)
20 permit 41 any any (15 matches)
30 permit ip any any (24 matches)

What about a spoke-to-spoke ping?


R4#ping 2001:cc1e:25::5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:25::5, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

Since these are point-to-point links, they need a route to each other. This can be configured either with a static IPv6 route on the spokes or with a routing protocol.


R5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#ipv6 route ::/0 tun25

R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#ipv6 route ::/0 tun24
R4(config)#do ping 2001:cc1e:25::5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:25::5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/28/40 ms

And with a routing protocol:


R4(config)#no ipv6 route ::/0 tun24
R4(config)#int tun24
R4(config-if)#ipv6 ospf 1 area 0

R5(config)#no ipv6 route ::/0 tun25
R5(config)#int tun25
R5(config-if)#ipv6 ospf 1 area 0

Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int tun24
R2(config)#int tun24
R2(config-if)#ipv6 ospf 1 area 0
*Feb 22 12:14:41.443: %OSPFv3-5-ADJCHG: Process 1, Nbr 150.1.4.4 on Tunnel24 from LOADING to FULL, Loading Done
R2(config-if)#int tun 25
R2(config-if)#ipv6 ospf 1 area 0
R2(config-if)#
*Feb 22 12:14:49.863: %OSPFv3-5-ADJCHG: Process 1, Nbr 150.1.5.5 on Tunnel25 from LOADING to FULL, Loading Done

R4(config-if)#do sh ipv6 route ospf
IPv6 Routing Table – 8 entries
Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP
U – Per-user Static route, M – MIPv6
I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary
O – OSPF intra, OI – OSPF inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2
ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2
D – EIGRP, EX – EIGRP external
O 2001:CC1E:25::/64 [110/22222]
via FE80::C80D:4DFF:FE28:0, Tunnel24

R4(config-if)#do ping 2001:cc1e:25::5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:25::5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/43/60 ms

OER/PfR Part 4

Up to this point you’ve seen how OER can define and control separate traffic classes, but what if you want custom policies applied to the classes such as holddown timers, aggregation types, route control and select-exit methods? What about activating delay and throughput on one class and just throughput on another. Yes, OER can do that too.

I’m going to create two custom classes reusing one of the ACLs defined previously as well as creating a new one.


R3CoreMC#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3CoreMC(config)#ip access-list extended CHARGEN
R3CoreMC(config-ext-nacl)#permit tcp any eq chargen any (direction is important!)

R3CoreMC(config-ext-nacl)#exit
R3CoreMC(config)#ip prefix-list DSCP_FILTER permit 90.0.0.0/24
R3CoreMC(config)#ip prefix-list DSCP_FILTER permit 100.1.1.0/24
R3CoreMC(config)#oer master
R3CoreMC(config-oer-mc)#application define CHARGEN access-list CHARGEN
R3CoreMC(config-oer-mc)#learn
R3CoreMC(config-oer-mc-learn)#list seq 1 refname SECRET_SAUCE
R3CoreMC(config-oer-mc-learn-list)#traffic-class access-list DSCP_AGG ?
filter Specify filter using prefix-list

R3CoreMC(config-oer-mc-learn-list)#traffic-class access-list DSCP_AGG fi
R3CoreMC(config-oer-mc-learn-list)#$list DSCP_AGG filter DSCP_FILTER
R3CoreMC(config-oer-mc-learn-list)#aggregation-type prefix-length 30
R3CoreMC(config-oer-mc-learn-list)#throughput
R3CoreMC(config-oer-mc-learn-list)#list seq 2 refname CHARGEN
R3CoreMC(config-oer-mc-learn-list)#traffic-class application CHARGEN
R3CoreMC(config-oer-mc-learn-list)#aggregation-type prefix-length 28
R3CoreMC(config-oer-mc-learn-list)#throughput

IP prefix filtering is done with a prefix-list. Using an ACL to filter won’t work. Just remember ACLs to define traffic (protocols, ports, dscp values), prefix-lists to filter prefixes. You have the ability to create custom named applications and reference them later in the learn-list. Using application define is similar to creating a custom application port-mapping in nbar. Learn lists are somewhat similar to class-maps. There are prebuilt applications you can match in the list as well as calling your own defined applications.The CHARGEN “application” appears at the top of the list. You also can override some of the default learn settings like throughput, delay, count and aggregation-count.


R3CoreMC(config-oer-mc-learn-list)#traffic-class application ?
CHARGEN CHARGEN
cuseeme cuseeme
dhcp dhcp
dns dns
filter Specify filter using prefix-list
finger finger
ftp ftp
gopher gopher
http http
httpssl httpssl
imap imap
irc irc
kerberos kerberos
l2tp l2tp
ldap ldap
mssql mssql
nfs nfs
nntp nntp
none none
notes notes
ntp ntp
pcany pcany
pop3 pop3
pptp pptp
simap simap
sirc sirc
sldap sldap
smtp smtp
snntp snntp
spop3 spop3
ssh ssh
telnet telnet

Okay so there’s two custom applications named SECRET_SAUCE and CHARGEN. Now what? Well if learn-lists are class-maps, oer-maps are policy-maps. Or route-maps, you decide. The oer-map allows you to configure how OER controls routes, set timers and resolve priorities.

Note the match and set options.


R3CoreMC#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3CoreMC(config)#oer-map MAP
R3CoreMC(config-oer-map)#?
oer-map configuration subcommands:
default Set a command to its defaults
exit Exit from oer-map configuration submode
match Match values for OER policy
no Negate a command or set its defaults
set Set values for OER policy

R3CoreMC(config-oer-map)#set ?
active-probe Manually create an active probe for a known target
backoff Specify backoff timer parameters
delay Specify delay parameters
holddown Specify hold-down timer parameter
interface Specify an OER managed border router interface
jitter Specify jitter parameters
link-group Specify the link group
loss Specify loss parameters
mode Specify OER operating mode settings
mos Specify mos parameters
next-hop Specify the next-hop ip address
periodic Specify periodic rotation timer value
probe Specify active probe parameter
resolve Specify OER policy resolver settings
traceroute Enable traceroute
unreachable Specify unreachable parameters

R3CoreMC(config-oer-map)#match ?
ip IP specific information
oer Match oer prefixes
traffic-class Specify Traffic class

Now configure the oer-map to match the custom applications and set separate policies for them.

R3CoreMC(config)#oer-map MAP 10
R3CoreMC(config-oer-map)# match oer learn list SECRET_SAUCE
R3CoreMC(config-oer-map)# set mode select-exit best
R3CoreMC(config-oer-map)# set backoff 90 90
R3CoreMC(config-oer-map)# set holddown 180
R3CoreMC(config-oer-map)# set mode route control
R3CoreMC(config-oer-map)# set mode monitor both
R3CoreMC(config-oer-map)# set resolve utilization priority 1 variance 15

R3CoreMC(config-oer-map)#oer-map MAP 20
R3CoreMC(config-oer-map)# match oer learn list CHARGEN
R3CoreMC(config-oer-map)# set mode select-exit good
R3CoreMC(config-oer-map)# set backoff 180 180
R3CoreMC(config-oer-map)# set holddown 360
R3CoreMC(config-oer-map)# set mode route control
R3CoreMC(config-oer-map)# set mode monitor both
R3CoreMC(config-oer-map)# set resolve utilization priority 1 variance 20
R3CoreMC(config-oer-map)#oer master
R3CoreMC(config-oer-mc)#policy-rules MAP
R3CoreMC(config-oer-mc)#no shut
R3CoreMC(config-oer-mc)#end

Use show oer master policy to display the global policy and custom oer-map policies. Any setting prefaced with a * overrides the global settings.

R3CoreMC#sh oer master policy
Default Policy Settings:
backoff 90 90 90
delay relative 50
holddown 90
periodic 0
probe frequency 56
mode route control
mode monitor both
mode select-exit good
loss relative 10
jitter threshold 20
mos threshold 3.60 percent 30
unreachable relative 50
resolve utilization priority 1 variance 10
resolve delay priority 11 variance 20

oer-map MAP 10
sequence no. 8444249301975040, provider id 1, provider priority 30
host priority 0, policy priority 10, Session id 0
match oer learn list SECRET_SAUCE
*backoff 90 90 90
delay relative 50
*holddown 180
periodic 0
probe frequency 56
*mode route control
*mode monitor both
*mode select-exit best
loss relative 10
jitter threshold 20
mos threshold 3.60 percent 30
unreachable relative 50
next-hop not set
forwarding interface not set
*resolve utilization priority 1 variance 15
*resolve delay priority 11 variance 20

oer-map MAP 20
sequence no. 8444249302630400, provider id 1, provider priority 30
host priority 0, policy priority 20, Session id 0
match oer learn list CHARGEN
*backoff 180 180 180
delay relative 50
*holddown 360
periodic 0
probe frequency 56
*mode route control
*mode monitor both
*mode select-exit good
loss relative 10
jitter threshold 20
mos threshold 3.60 percent 30
unreachable relative 50
next-hop not set
forwarding interface not set
*resolve utilization priority 1 variance 20
*resolve delay priority 11 variance 20

* Overrides Default Policy Setting

And finally, the standard verification plus show oer master learn list. The custom defined application is listed by name. If a pre-configured application is used, that name would appear as well. OER is learning the two applications using the /28 and /30 prefix lengths that were defined in the learn list.


R3CoreMC#sh oer master traffic-class
OER Prefix Statistics:

DstPrefix Appl_ID Dscp Prot SrcPort DstPort SrcPrefix
Flags State Time CurrBR CurrI/F Protocol
PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos EBw IBw
ActSDly ActLDly ActSUn ActLUn ActSJit ActPMOS
——————————————————————————–
95.0.0.0/28 CHARGEN defa N N N 0.0.0.0/0
INPOLICY 0 1.1.1.1 Se2/0 PBR
426 371 28265 28865 16618 1704 86 13
U U 0 0 N N

101.1.1.0/28 CHARGEN defa N N N 0.0.0.0/0
INPOLICY 0 2.2.2.2 Se2/0 PBR
430 412 16917 23146 29929 13857 54 10
226 435 0 0 N N

90.0.0.0/30 N 9 256 N N 0.0.0.0/0
OOPOLICY @29 1.1.1.1 Se2/0 PBR
U U 0 0 22589 22589 67 0
U U 0 0 N N

100.1.1.0/30 N 11 256 N N 0.0.0.0/0
INPOLICY @27 2.2.2.2 Se2/0 PBR
U U 0 0 45262 45262 53 0
447 447 0 0 N N

R3CoreMC#sh oer master learn list
Learn-List seq 1 refname SECRET_SAUCE
Configuration:
Traffic-Class Access-list: DSCP_AGG
Filter: DSCP_FILTER
Aggregation-type: prefix-length 30
Learn type: throughput
Session count: 50 Max count: 100
Policies assigned: 10
Stats:
Traffic-Class Count: 2
Traffic-Class Learned:
Appl Prefix 100.1.1.0/30 11 256
Appl Prefix 90.0.0.0/30 9 256

Learn-List seq 2 refname CHARGEN
Configuration:
Traffic-Class Application: CHARGEN
Aggregation-type: prefix-length 28
Learn type: throughput
Session count: 50 Max count: 100
Policies assigned: 20
Stats:
Traffic-Class Count: 2
Traffic-Class Learned:
Appl Prefix 101.1.1.0/28 CHARGEN
Appl Prefix 95.0.0.0/28 CHARGEN

I think that’s about it for OER for now.
You can check out a free vseminar on PfR from INE here.
Cisco also has articles on PfR on their DockWiki site here.

OER/PfR Part 3

Note: I had some trouble getting this to work initially until I specifically went under learn mode and configured no delay. I think it may be a quirk of the 7200s I’m emulating in GNS3. I also took the time to create an EEM applet on R9,R10,R11 to continually generate chargen traffic. OER requires SYN/SYNACK packets for passive monitoring. I configured 4 separate applets to generate traffic to all of the “host” routers. R11 uses 2 different interfaces to source traffic. We’ll get into why later.

event manager applet CHARGEN1
event timer watchdog time 5
action 0.0 cli command “enable”
action 2.0 cli command “telnet 3.0.0.5 chargen /source lo100”
event manager applet CHARGEN2
event timer watchdog time 5
action 0.0 cli command “enable”
action 2.0 cli command “telnet 3.0.0.6 chargen /source lo100”
event manager applet CHARGEN3
event timer watchdog time 5
action 0.0 cli command “enable”
action 2.0 cli command “telnet 4.0.0.7 chargen /source lo101”
event manager applet CHARGEN4
event timer watchdog time 5
action 0.0 cli command “enable”
action 2.0 cli command “telnet 4.0.0.8 chargen /source lo101”

Now we’re going to get a little more complicated and dive into the world of application aware routing. This means the MC will control the route based on more than just a destination prefix. This also means that we can’t use static routing to control the traffic. Enter PBR. This adds a new requirement to our topology. The border routers must be directly connected, otherwise there’s no way to guarantee that the PBR would be effective and loop-free. To meet this new requirement we will configure a tunnel interface on R1 and R2 then define the tunnel interfaces as an internal interface on the MC.


R2B2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2B2(config)#int tun12
*Feb 17 20:44:31.654: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel12, changed state to down
R2B2(config-if)#ip address 12.12.12.2 255.255.255.0
R2B2(config-if)#tunnel source lo0
R2B2(config-if)#tunnel destination 1.1.1.1
R2B2(config-if)#end

R1B1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1B1(config)#int tun12
*Feb 17 20:44:31.654: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel12, changed state to down
R1B1(config-if)#ip address 12.12.12.2 255.255.255.0
R1B1(config-if)#tunnel source lo0
R1B1(config-if)#tunnel destination 2.2.2.2
R1B1(config-if)#end
R1B1#ping 12.12.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.12.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/44/60 ms
R1B1#

R3CoreMC#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3CoreMC(config)#oer master
R3CoreMC(config-oer-mc)#border 1.1.1.1
R3CoreMC(config-oer-mc-br)#interface tun12 int
R3CoreMC(config-oer-mc-br)#interface tun12 inter
R3CoreMC(config-oer-mc-br)#border
*Feb 17 20:47:43.870: %OER_MC-5-NOTICE: BR 1.1.1.1 IF Tu12 UP
R3CoreMC(config-oer-mc-br)#border 2.2.2.2
R3CoreMC(config-oer-mc-br)#interface tun12 int
R3CoreMC(config-oer-mc-br)#end
R3CoreMC#
*Feb 17 20:47:51.518: %OER_MC-5-NOTICE: BR 2.2.2.2 IF Tu12 UP
*Feb 17 20:47:51.522: %OER_MC-5-NOTICE: PBR Requirements met

Notice the message on the MC telling us the PBR requirements are now met. For testing, the four host routers are configured to mark dscp values based on destination address.

R5H1#sh access-lists
Extended IP access list R10
10 permit ip any host 95.0.0.1
Extended IP access list R11
10 permit ip any host 100.1.1.1
20 permit ip any host 101.1.1.1
Extended IP access list R9
10 permit ip any host 90.0.0.1

R5H1#sh run | s class-map
class-map match-all R11
match access-group name R11
class-map match-all R10
match access-group name R10
class-map match-all R9
match access-group name R9

R5H1#sh policy-map int
GigabitEthernet1/0

Service-policy output: MARK

Class-map: R9 (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: access-group name R9
QoS Set
dscp 9
Packets marked 0

Class-map: R10 (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: access-group name R10
QoS Set
dscp af11
Packets marked 0

Class-map: R11 (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: access-group name R11
QoS Set
dscp 11
Packets marked 0

Class-map: class-default (match-any)
33 packets, 3236 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any

Now we have to configure some ACLs on the MC to define the application. Anything with dscp values 9 or 11 will be considered. Then the ACL is applied under learn mode.

R3CoreMC#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3CoreMC(config)#ip access-list extended DSCP_AGG
R3CoreMC(config-ext-nacl)#permit ip any any dscp 9
R3CoreMC(config-ext-nacl)#permit ip any any dscp 11
R3CoreMC(config)#oer master
R3CoreMC(config-oer-mc)#learn
R3CoreMC(config-oer-mc-learn)#traffic-class aggregate access-list DSCP_AGG

Check the policy-map on R5 to verify the traffic is being marked.

R5H1#sh policy-map int
GigabitEthernet1/0

Service-policy output: MARK

Class-map: R9 (match-all)
994 packets, 551687 bytes
30 second offered rate 98000 bps, drop rate 0 bps
Match: access-group name R9
QoS Set
dscp 9
Packets marked 994

Class-map: R10 (match-all)
688 packets, 386271 bytes
30 second offered rate 70000 bps, drop rate 0 bps
Match: access-group name R10
QoS Set
dscp af11
Packets marked 688

Class-map: R11 (match-all)
966 packets, 559807 bytes
30 second offered rate 102000 bps, drop rate 0 bps
Match: access-group name R11
QoS Set
dscp 11
Packets marked 966

R3 profiles the traffic again. Note that show oer master prefix only lists the 95.0.0.0/24 network now. That is the only prefix that is receiving traffic that doesn’t match the defined application. R9/R11 are both receiving dscp9/dscp11 packets. The other prefixes are controlled by PBR and not STATIC.

R3CoreMC#sh oer master prefix

Prefix State Time Curr BR CurrI/F Protocol
PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos
ActSDly ActLDly ActSUn ActLUn EBw IBw
ActSJit ActPMOS ActSLos ActLLos
——————————————————————————–
95.0.0.0/24 HOLDDOWN 310 2.2.2.2 Se2/0 STATIC
U U 0 0 0 0
U U 0 0 116 12
N N

R3CoreMC#sh oer master traffic-class
OER Prefix Statistics:

DstPrefix Appl_ID Dscp Prot SrcPort DstPort SrcPrefix
Flags State Time CurrBR CurrI/F Protocol
PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos EBw IBw
ActSDly ActLDly ActSUn ActLUn ActSJit ActPMOS
——————————————————————————–
90.0.0.0/24 N 9 256 N N 0.0.0.0/0
HOLDDOWN 293 2.2.2.2 Se2/0 PBR
U U 0 0 0 0 81 0
U U 0 0 N N

95.0.0.0/24 N defa N N N N
HOLDDOWN 308 2.2.2.2 Se2/0 STATIC
U U 0 0 0 0 112 12
U U 0 0 N N

100.1.1.0/24 N 11 256 N N 0.0.0.0/0
HOLDDOWN 316 2.2.2.2 Se2/0 PBR
U U 0 0 0 0 47 0
U U 0 0 N N

101.1.1.0/24 N 11 256 N N 0.0.0.0/0
HOLDDOWN 298 2.2.2.2 Se2/0 PBR
U U 0 0 0 0 27 0
U U 0 0 N N

Note the BRs that are being selected for the exit paths. If we check R1 we can see the PBR policy that R3 applied.


R1B1#sh ip access-lists dynamic
Extended IP access list oer#1
268435455 permit ip any 101.1.1.0 0.0.0.255 dscp 11 (1373 matches)
536870911 permit ip any 100.1.1.0 0.0.0.255 dscp 11 (1086 matches)
1073741823 permit ip any 90.0.0.0 0.0.0.255 dscp 9 (2562 matches)

R1B1#sh route-map dynamic
route-map OER-02/18/13-15:33:27.398-25-OER, permit, sequence 0, identifier 1732625800
Match clauses:
ip address (access-lists): oer#1
Set clauses:
ip next-hop 12.12.12.2
interface Tunnel12
Policy routing matches: 5904 packets, 755923 bytes
Current active dynamic routemaps = 1

R1B1#sh ip policy
Interface Route map
Gi1/0 OER-02/18/13-15:33:27.398-25-OER (Dynamic)
Tunnel12 OER-02/18/13-15:33:27.398-25-OER (Dynamic)

Any traffic matching ACL OER#1 is sent over the tunnel to R2.

Now we’re going to filter our application. R11 has loopbacks in the 100.1.1.0/24 and 101.1.1.0/24 network. R5 is marking traffic destined for either prefix with dscp 11. Currently, R1 is allowing any traffic marked dscp 9 or 11 to be controlled via PBR. Only traffic that meets the dscp criteria AND is destined for the 90.0.0.0/24 or 100.1.1.0/24 networks will be considered.

Configure a traffic-class filter ACL and apply it to the MC.

R3CoreMC#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3CoreMC(config)#ip access-list extended DSCP_FILTER
R3CoreMC(config-ext-nacl)#permit ip any 100.1.1.0 0.0.0.255 dscp 11
R3CoreMC(config-ext-nacl)#permit ip any 90.0.0.0 0.0.0.255 dscp 9
R3CoreMC(config-ext-nacl)#oer master
R3CoreMC(config-oer-mc)#learn
R3CoreMC(config-oer-mc-learn)#traffic-class filter access-list DSCP_FILTER

OER is definitely a hurry up and wait feature. It can take a while to get everything under control especially if it decides it hasn’t seen enough traffic to control an application.

R3CoreMC#sh oer master prefix
OER Prefix Statistics:

Prefix State Time Curr BR CurrI/F Protocol
PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos
ActSDly ActLDly ActSUn ActLUn EBw IBw
ActSJit ActPMOS ActSLos ActLLos
——————————————————————————–
95.0.0.0/24 INPOLICY 0 2.2.2.2 Se2/0 STATIC
302 333 40130 36652 18778 19059
U U 0 0 74 13
N N
101.1.1.0/24 HOLDDOWN 307 2.2.2.2 Se2/0 STATIC
U U 0 0 0 0
U U 0 0 26 8
N N
R3CoreMC#sh oer master traffic-class
OER Prefix Statistics:

DstPrefix Appl_ID Dscp Prot SrcPort DstPort SrcPrefix
Flags State Time CurrBR CurrI/F Protocol
PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos EBw IBw
ActSDly ActLDly ActSUn ActLUn ActSJit ActPMOS
——————————————————————————–
90.0.0.0/24 N 9 256 N N 0.0.0.0/0
HOLDDOWN 227 2.2.2.2 Se2/0 PBR
U U 0 0 25162 25162 85 0
U U 0 0 N N

95.0.0.0/24 N defa N N N N
INPOLICY 0 2.2.2.2 Se2/0 STATIC
302 333 40130 36652 18778 19059 73 12
U U 0 0 N N

100.1.1.0/24 N 11 256 N N 0.0.0.0/0
HOLDDOWN 237 2.2.2.2 Se2/0 PBR
U U 0 0 0 0 42 0
U U 0 0 N N

101.1.1.0/24 N defa N N N N
HOLDDOWN 302 2.2.2.2 Se2/0 STATIC
U U 0 0 0 0 25 7
U U 0 0 N N

The dscp marked traffic destined for 101.1.1.0/24 no longer meets the application criteria and is now controlled with static routes.

OER/PfR Part 2: Electric Bugaloo

Now that we have the absolute basics out of the way, it’s time to look at some of the filtering options. This time I’m going to do an http file copy from R9/R10 and chargen telnet connection from R11. All chargen traffic is destined to 100.1.1.0/24 whereas http traffic is destined to 90.0.0.0/24 and 95.0.0.0/24.

R5H1#sh tcp br
TCB Local Address Foreign Address (state)
674428B4 3.0.0.5.19 100.1.1.1.29248 ESTAB
65BCA5DC 3.0.0.5.19 100.1.1.1.22328 ESTAB
65BB0248 3.0.0.5.19 100.1.1.1.50702 ESTAB
67419940 3.0.0.5.80 90.0.0.1.12440 ESTAB
65BC7248 3.0.0.5.19 100.1.1.1.54544 ESTAB
65BBDC80 3.0.0.5.19 100.1.1.1.36658 ESTAB
67404634 3.0.0.5.80 95.0.0.1.62482 ESTAB
67407658 3.0.0.5.19 100.1.1.1.22249 ESTAB
673E0434 3.0.0.5.19 100.1.1.1.39421 ESTAB

Now I configure R3 to only watch for tcp port 19 traffic.

R3CoreMC#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3CoreMC(config)#oer master
R3CoreMC(config-oer-mc)#learn
R3CoreMC(config-oer-mc-learn)#protocol tcp port 19
R3CoreMC(config-oer-mc-learn)#end
R3CoreMC#

This time when R3 learns prefixes, it only sees traffic destined for 100.1.1.0/24.

R3CoreMC#sh oer master traffic-class
OER Prefix Statistics:

DstPrefix Appl_ID Dscp Prot SrcPort DstPort SrcPrefix
Flags State Time CurrBR CurrI/F Protocol
PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos EBw IBw
ActSDly ActLDly ActSUn ActLUn ActSJit ActPMOS
——————————————————————————–
100.1.1.0/24 N defa N N N N
DEFAULT* @88 2.2.2.2 Se2/0 U

And eventually R3 controls the route and changes the exit to R2 using a static route just like last time.

R3CoreMC#sh oer master traffic-class
OER Prefix Statistics:

DstPrefix Appl_ID Dscp Prot SrcPort DstPort SrcPrefix
Flags State Time CurrBR CurrI/F Protocol
PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos EBw IBw
ActSDly ActLDly ActSUn ActLUn ActSJit ActPMOS
——————————————————————————–
100.1.1.0/24 N defa N N N N
HOLDDOWN 81 2.2.2.2 Se2/0 STATIC
U U 0 0 0 0 38 1
U U 0 0 N N

OER/PfR Part 1

I’ve been studying for my CCIE:R&S since April 2012.  I’m just going to dive right in and talk about the topic I’ve been working on lately which is OER.  There doesn’t seem to be a ton of information on this in the blogosphere, so I’m going to go through and document what I think I know.
The initial setup is absurdly easy and I’m going to assume you already know how to get the borders and master up and communicating.  Here is the topology I’m using in GNS3.  Everything inside the box is the internal network.  R1 & R2 are configured to redistribute static routes into OSPF that have a tag of 5000.  Each has injected a default route, although the route from R1 is preferred to force all traffic through R1.  R5, R6, R7, R8 have ip routing disabled and are configured with R3 or R4 as their default gateway.

topology

The MC is using a very basic config to get everything started.  All timers are set to their minimums to speed up the process.

MC_initconfig

Three traceroutes from R5 to show the path of traffic currently.  All traffic takes a path from R3 -> R1 -> R9 for the external networks.

R5_pretraceroutes

To start generating traffic, I source some http copies from R9, R10, R11 from their loopbacks to R5.  You can see here that R1 is overloaded and using 100% of its configured b/w of 384kbps.   R2’s serial interface is only at 20% load (the file copy from R5->R10).

MC_overload

Now the MC sees the traffic and discovers which border routers are being used as exit points in the network.

MC_discoverexit

MC_showdiscoverexit

After the timer counts down, R3 chooses two routes to control and injects static routes on R2.  Note the C flag on R2 designating that it’s the router injecting the static route, whereas R1 has an X flag.

BR_routecontrol

A quick look at R4’s RIB reveals the E2 routes from R2.

R4_externalroutes

Now let’s do those traceroutes from R5 again and see what’s happened.

R5_posttraceroute

R3 controls networks 95.0.0.0/24 and 100.1.1.0/24 and both of those networks are now taking a path of R3 -> R4 -> R2 -> R10 whereas 90.0.0.0/0 is still using R1 as its exit point.