OER

OER or Optimised Edge Routing. Also known as PFR or Performance Routing is now part of the v4 blueprint. In summary it is a feature that enables selection of a route based on its dynamic performance metrics. Something lacking with traditional routing protocols that assign a metric to a route. This assigned metric is in effect the static expected performance of the route that can be used when comparing with any route alternates.

OER is a step towards route selection based on true dynamic performance e.g. in terms of real round trip times of packets. There’s quite a bit of configuring required. CISCO lays out five phases

• Profiling
• Measuring
• Policy Application
• Control
• Verification

The components of OER include a Master Controller (MC) and the Border Routers (BR). The BR’s send performance statistics to the MC. The MC sends routing policy decisions to the BR’s. It’s the BRs that sit on the edge of the network and implement the policies to control the traffic leaving on the external links.

Here i lay out the basic config between MC and Borders. Authentication via a key chain between MC and BR is not optional.

Master Configuration

R1
key chain RIC
key 1
key-string ROUTERRIC

oer master
keepalive 10
logging
!
border 2.2.2.2 key-chain RIC
interface Serial1/0 external
interface Ethernet0/0 internal
!
border 3.3.3.3 key-chain RIC
interface Serial1/0 external
interface Ethernet0/0 internal



Border Config on R2 and R3

key chain RIC
key 1
key-string ROUTERRIC
!
oer border
local Loopback0
master 1.1.1.1 key-chain RIC

Verification On R1

R1#show oer master
OER state: ENABLED and ACTIVE
Conn Status: SUCCESS, PORT: 3949
Number of Border routers: 2
Number of Exits: 2
Number of monitored prefixes: 0 (max 5000)
Max prefixes: total 5000 learn 2500
Prefix count: total 0, learn 0, cfg 0

Border Status UP/DOWN AuthFail
3.3.3.3 ACTIVE UP 00:01:57 0
2.2.2.2 ACTIVE UP 00:02:14 0

Verification on R2 and R3
R2#show oer border
OER BR 2.2.2.2 ACTIVE, MC 1.1.1.1 UP/DOWN: UP 00:45:16,
Auth Failures: 0
Conn Status: SUCCESS, PORT: 3949
Exits
Et0/0 INTERNAL
Se1/0 EXTERNAL

EIGRP V6

New in V4 CCIE R and S. EIGRP V6 is found in the configuration guide under the IPV6 EIGRP section and not under EIGRP.

Below is a sample config

ipv6 unicast-routing
ipv6 router eigrp 1
no shut

int e0/0
ipv6 enable
ipv6 eigrp 1

Of note is the fact that the EIGRPV6 router process is shutdown until it is manually enabled with ‘no shut’.
R4(config-rtr)#do show ipv6 eigrp ne
IPv6-EIGRP neighbors for process 1
% EIGRP 1 is in SHUTDOWN

Once the ipv6 router eigrp process is started then the neighbour relationship comes up!

R4(config-rtr)#ipv6 router eigrp 1
R4(config-rtr)#no shut
*Mar 1 00:05:32.727: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 1: Neighbor FE80::C003:13FF:FE7C:0 (FastEthernet0/0) is up: new adjacency

R4#s ipv6 eigrp ne
IPv6-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num
0 Link-local address: Fa0/0 013 00:01:38 1980 5000 0 1
FE80::C003:13FF:FE7C:0

Reviewing the V4 Blueprint

I have listed the CCIE Lab v4 R and S blueprint below. The following topics look like additions over and above the V3 lab content. So far I have reviewed and blogged on RITE and MPLS, so hope to cover the other topics over the coming weeks and months.

New V4 topics
PPPoE
OER (Optimised Edge Routing)
MPLS
EIGRP v6
Ipv6 Multicast
AUTOQOS
NETFLOW
RITE (Router IP Traffic-Export)
EEM (Embedded Event Manager)
Zone Based Firewall
IPS (intrusion Prevention System)

Complete V4 blueprint
1.10 Implement Spanning Tree Protocol (STP)
(a) 802.1d
(b) 802.1w
(c) 801.1s
(d) Loop guard
(e) Root guard
(f) Bridge protocol data unit (BPDU) guard
(g) Storm control
(h) Unicast flooding
(i) Port roles, failure propagation, and loop guard operation
1.20 Implement VLAN and VLAN Trunking Protocol (VTP)
1.30 Implement trunk and trunk protocols, EtherChannel, and load-balance
1.40 Implement Ethernet technologies
(a) Speed and duplex
(b) Ethernet, Fast Ethernet, and Gigabit Ethernet
(c) PPP over Ethernet (PPPoE)
1.50 Implement Switched Port Analyzer (SPAN), Remote Switched Port Analyzer (RSPAN), and flow control
1.60 Implement Frame Relay
(a) Local Management Interface (LMI)
(b) Traffic shaping
(c) Full mesh
(d) Hub and spoke
(e) Discard eligible (DE)
1.70 Implement High-Level Data Link Control (HDLC) and PPP

2.00 Implement IPv4
2.10 Implement IP version 4 (IPv4) addressing, subnetting, and variable-length subnet masking (VLSM)
2.20 Implement IPv4 tunneling and Generic Routing Encapsulation (GRE)
2.30 Implement IPv4 RIP version 2 (RIPv2)
2.40 Implement IPv4 Open Shortest Path First (OSPF)
(a) Standard OSPF areas
(b) Stub area
(c) Totally stubby area
(d) Not-so-stubby-area (NSSA)
(e) Totally NSSA
(f) Link-state advertisement (LSA) types
(g) Adjacency on a point-to-point and on a multi-access network
(h) OSPF graceful restart
2.50 Implement IPv4 Enhanced Interior Gateway Routing Protocol (EIGRP)
(a) Best path
(b) Loop-free paths
(c) EIGRP operations when alternate loop-free paths are available, and when they are not available
(d) EIGRP queries
(e) Manual summarization and autosummarization
(f) EIGRP stubs
2.60 Implement IPv4 Border Gateway Protocol (BGP)
(a) Next hop
(b) Peering
(c) Internal Border Gateway Protocol (IBGP) and External Border Gateway Protocol (EBGP)
2.70 Implement policy routing
2.80 Implement Performance Routing (PfR) and Cisco Optimized Edge Routing (OER)
2.90 Implement filtering, route redistribution, summarization, synchronization, attributes, and other advanced features

3.00 Implement IPv6
3.10 Implement IP version 6 (IPv6) addressing and different addressing types
3.20 Implement IPv6 neighbor discovery
3.30 Implement basic IPv6 functionality protocols
3.40 Implement tunneling techniques
3.50 Implement OSPF version 3 (OSPFv3)
3.60 Implement EIGRP version 6 (EIGRPv6)
3.70 Implement filtering and route redistribution

4.00 Implement MPLS Layer 3 VPNs
4.10 Implement Multiprotocol Label Switching (MPLS)
4.20 Implement Layer 3 virtual private networks (VPNs) on provider edge (PE), provider (P), and customer edge (CE) routers
4.30 Implement virtual routing and forwarding (VRF) and Multi-VRF Customer Edge (VRF-Lite)

5.00 Implement IP Multicast
5.10 Implement Protocol Independent Multicast (PIM) sparse mode
5.20 Implement Multicast Source Discovery Protocol (MSDP)
5.30 Implement interdomain multicast routing
5.40 Implement PIM Auto-Rendezvous Point (Auto-RP), unicast rendezvous point (RP), and bootstrap router (BSR)
5.50 Implement multicast tools, features, and source-specific multicast
5.60 Implement IPv6 multicast, PIM, and related multicast protocols, such as Multicast Listener Discovery (MLD)

6.00 Implement Network Security
6.01 Implement access lists
6.02 Implement Zone Based Firewall
6.03 Implement Unicast Reverse Path Forwarding (uRPF)
6.04 Implement IP Source Guard
6.05 Implement authentication, authorization, and accounting (AAA) (configuring the AAA server is not required, only the client-side (IOS) is configured)
6.06 Implement Control Plane Policing (CoPP)
6.07 Implement Cisco IOS Firewall
6.08 Implement Cisco IOS Intrusion Prevention System (IPS)
6.09 Implement Secure Shell (SSH)
6.10 Implement 802.1x
6.11 Implement NAT
6.12 Implement routing protocol authentication
6.13 Implement device access control
6.14 Implement security features

7.00 Implement Network Services
7.10 Implement Hot Standby Router Protocol (HSRP)
7.20 Implement Gateway Load Balancing Protocol (GLBP)
7.30 Implement Virtual Router Redundancy Protocol (VRRP)
7.40 Implement Network Time Protocol (NTP)
7.50 Implement DHCP
7.60 Implement Web Cache Communication Protocol (WCCP)

8.00 Implement Quality of Service (QoS)
8.10 Implement Modular QoS CLI (MQC)
(a) Network-Based Application Recognition (NBAR)
(b) Class-based weighted fair queuing (CBWFQ), modified deficit round robin (MDRR), and low latency queuing (LLQ)
(c) Classification
(d) Policing
(e) Shaping
(f) Marking
(g) Weighted random early detection (WRED) and random early detection (RED)
(h) Compression
8.20 Implement Layer 2 QoS: weighted round robin (WRR), shaped round robin (SRR), and policies
8.30 Implement link fragmentation and interleaving (LFI) for Frame Relay
8.40 Implement generic traffic shaping
8.50 Implement Resource Reservation Protocol (RSVP)
8.60 Implement Cisco AutoQoS

9.00 Troubleshoot a Network
9.10 Troubleshoot complex Layer 2 network issues
9.20 Troubleshoot complex Layer 3 network issues
9.30 Troubleshoot a network in response to application problems
9.40 Troubleshoot network services
9.50 Troubleshoot network security

10.00 Optimize the Network
10.01 Implement syslog and local logging
10.02 Implement IP Service Level Agreement SLA
10.03 Implement NetFlow
10.04 Implement SPAN, RSPAN, and router IP traffic export (RITE)
10.05 Implement Simple Network Management Protocol (SNMP)
10.06 Implement Cisco IOS Embedded Event Manager (EEM)
10.07 Implement Remote Monitoring (RMON)
10.08 Implement FTP
10.09 Implement TFTP
10.10 Implement TFTP server on router
10.11 Implement Secure Copy Protocol (SCP)
10.12 Implement HTTP and HTTPS
10.13 Implement Telnet

Router Sniffer Capture

Ever wondered if you can run a sniffer from a router? I have only ever used monitor sessions on switches so Router IP Traffic Export or RITE was an interesting discovery for me. This can be used to achieve the same as a monitor session on a switch. Also this is on the V4 blueprint so a useful command to have come across. Its not that difficult either!

There are just two configuration steps. Define the outgoing sniffer port along with the mac address of the device attached and then define the capture traffic flows on the ingress port.

Heres an example
interface Ethernet0/1
ip traffic-export profile RICH
mac-address 1111.2222.3333

interface Ethernet0/0
ip traffic-export apply RICH

R1#show ip traffic-exp
Router IP Traffic Export Parameters
Monitored Interface Ethernet0/0
Export Interface Ethernet0/1
Destination MAC address 1111.2222.3333
bi-directional traffic export is off
Input IP Traffic Export Information Packets/Bytes Exported 0/0
Packets Dropped 0
Sampling Rate one-in-every 1 packets
No Access List configured
Profile RICH is Active

There are a number of extra options i'venot detailed here. The above shows the basic configuration that’s needed to get the feature operational.

SHAM LINKS

A customer has 2 entry points into an MPLS VPN. It is a requirement for the customer to traverse the MPLS VPN for intersite traffic. When the customer is running OSPF between its sites by default the backdoor, slower, serial connection will always be preferred by OSPF. This is because links injected into the OSPF domain by the PE routers will be external routes and hence always less preferred than OSPF internal routes.

Sham links get around this problem. Effectively they are a vehicle to enable the OSPF links traversing the provider backbone to appear as internal OSPF routes.

Sham links appear analogous to virtual links. They have tunnel start and end points and traverse a routing domain. The following are required

1) A /32 loopback address on each PE router. This has to be in the customer VRF and NOT be directly advertised into OSPF.

2) Advertise these loopbacks into MP-BGP as vpnv4 routes. This is how the PE routers will learn about the endpoints of the sham-link.

3) Configure the sham-link under the OSPF process on the PE routers

1)
PE1
Int lo0
Ip vrf forwarding CUST1
Ip address 192.168.0.1

PE2
Int lo0
Ip vrf forwarding CUST1
Ip address 192.168.0.2

2)
PE1
Router bgp 1
Address-family ipv4 vrf CUST1
Network 192.168.0.1 255.255.255.255

PE2
Router bgp 1
Address-family ipv4 vrf CUST1
Network 192.168.0.1 255.255.255.255

3)
PE1
Router ospf 1 vrf CUST1
Area 0 sham-link 192.168.0.1 192.168.0.2

PE1
Router ospf 1 vrf CUST1
Area 0 sham-link 192.168.0.2 192.168.0.1

Using the PING TOS field

The extended ping command can be useful when testing MQC policies. The IP header TOS value of packets can be explicitly set, and hence MQC configuration can subsequently be tested.

The extended ping command expects the TOS value to be set using a decimal value (see below).


R1#ping
Protocol [ip]:
Target IP address: 10.0.0.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]: 184
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/32/68 ms

If you only know or are given the DSCP marking the question then arises 'How to i derive the TOS value from the DSCP marking?

This can easily be calculated when remembering the DSCP marking denotes the decimal value of the first 6 bits of the IP TOS header field. The last 2 bits of the TOS field are not used, so will always be zero.

As an example DSCP 46 equates to 101110 binary. To convert to a TOS value simply append the last two zero bits and convert back to decimal. Therefore 101110 becomes10111000 and when converted back to decimal this becomes 184. This is the decimal TOS representation of DSCP 46.

BGP transit AS's and how to avoid

How can you prevent your own BGP AS becoming a transit path? This can be achieved by making use of a distribute-list or a prefix-list. However these methods do not scale well as future ip addressing changes or additions require access lists to be revisited.

BB1 ------ R1 (AS 101) ------- R2 (AS 101) ------- BB2

Here are 2 options that scale and do not require revisiting when ip addresses change.

OPTION 1 - Make use of the no-export community.
-------------------------------------------------------------

Here i apply the community no-export to ALL incoming bgp routes.

R1
route-map NOEXPORT
set community no-export

router bgp 101
neigh {ip addr BB1} route-map NOEXPORT in
neigh {ip addr r2} send-community


OPTION 2 – Make use of the filter-list command
-----------------------------------------------------------

Here i create an as-path access list and only allow bgp routes originated in the routers own as (AS 101) to be advertised out.

R2
ip as-path access-list 1 permit ^$

router bgp 101
neigh {ip addrBB2} filter-list 1 out


With both commands i use show ip bgp {ip address} advertise for verification of advertised routes.