OER Part 2

Optimised Edge Routing / Performance Routing - Part 1

Here is a simple OER/PFR configuration example. R1 is the master controller with R4 and R5 the border routers. 

Border router 1

 key chain OER

 key 1

   key-string CISCO

oer border

 local Loopback0
 master 1.1.1.1 key-chain OER

Border router 2

 key chain OER

 key 1

   key-string CISCO

oer border

local Loopback0
master 1.1.1.1 key-chain OER

Master router

 oer master

 border 4.4.4.4 key-chain OER

  interface FastEthernet0/1 external
  interface FastEthernet0/0 internal

 border 5.5.5.5 key-chain OER

   interface FastEthernet0/1 external
   interface FastEthernet0/0 internal

 Verification Commands

R1#s oer master border
Border           Status   UP/DOWN             AuthFail  Version
5.5.5.5          ACTIVE   UP       00:13:00          0  2.1
4.4.4.4          ACTIVE   UP       00:13:32          0  2.1

R1#show oer border
OER BR 5.5.5.5 ACTIVE, MC 1.1.1.1 UP/DOWN: UP 00:22:18,
  Auth Failures: 0
  Conn Status: SUCCESS, PORT: 3949
  Version: 2.1  MC Version: 2.1
  Fa0/0           INTERNAL
  Fa0/1           EXTERNAL

Learning Prefixes on the OER Master Controller (MC) - Part 2

I enable learning on the OER Master.

oer master

learn

throughput
delay

I examine the ‘Learn Settings’s 

R4#s oer master | b Learn Settings

Learn Settings:

  current state : SLEEP

  time remaining in current state : 6957 seconds

  throughput

  no delay

  no inside bgp

  no protocol

  monitor-period 5

  periodic-interval 120

  aggregation-type prefix-length 24

  prefixes 100

  expire after time 720

I notice the OER Master is 'sleeping' i.e. not learning prefixes. By default the OER master learns for 5 mins and then sleeps for 120 minutes!  To increase the frequency of OER master learning from the default settings I adjust the monitor period (length of time MC learns prefixes) and the periodic-interval (time between monitoring periods).

oer master

learn

monitor-period 1

periodic-interval 0

I generate some traffic from the MC to R9

ip sla 1

 icmp-echo 9.9.9.9

 frequency 10

ip sla schedule 1 life forever start-time now

ip sla 2

 tcp-connect 9.9.9.9 23 source-ip 1.1.1.1

 timeout 500

 frequency 2

ip sla schedule 2 life forever start-time now

On R9

Ip sla responder

I now check the MC is learning about this prefix

R4#show oer master prefix learned throughput

OER Prefix Statistics:

 Pas - Passive, Act - Active, S - Short term, L - Long term, Dly - Delay (ms),

 P - Percentage below threshold, Jit - Jitter (ms),

 MOS - Mean Opinion Score

 Los - Packet Loss (packets-per-million), Un - Unreachable (flows-per-million),

 E - Egress, I - Ingress, Bw - Bandwidth (kbps), N - Not applicable

 U - unknown, * - uncontrolled, + - control more specific, @ - active probe all

 # - Prefix monitor mode is Special, & - Blackholed Prefix

 % - Force Next-Hop, ^ - Prefix is denied

Prefix                  State     Time Curr BR         CurrI/F         Protocol

                      PasSDly  PasLDly   PasSUn   PasLUn  PasSLos  PasLLos

                      ActSDly  ActLDly   ActSUn   ActLUn      EBw      IBw

                      ActSJit  ActPMOS  ActSLos  ActLLos

--------------------------------------------------------------------------------

9.9.9.9/32             INPOLICY*        0 4.4.4.4         Fa0/1           U    

                             123      127        0        0        0        0

                               U       75        0        0        1        1

                               N        N

My next post is on how to get the MC to choose the best route.

OER MC Best Route Selection - Part 3

From the Master Controller R1 I trace to the loopback of R9.  It can be seen I have two valid paths: one via R4 and one via R5. 

trace 9.9.9.9

Type escape sequence to abort.

Tracing the route to 9.9.9.9

  1 11.11.11.2 84 msec

     10.10.10.1 72 msec

     11.11.11.2 56 msec

  2 12.1.1.5 72 msec

     13.1.1.6 72 msec

     12.1.1.5 56 msec

  3 21.0.0.9 [AS 2] 88 msec

     20.0.0.9 [AS 2] 120 msec *

I now enable oer 'route control' on the master. I also configure 'select exit best'.

oer master

mode route control

mode select-exit best

After a few minutes i notice the master has selected a best exit via R4. It achieves this by adjusting the bgp local preference.

s ip bgp 9.9.9.9
BGP routing table entry for 9.9.9.9/32, version 7
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Multipath: iBGP
  Not advertised to any peer
  2
    13.1.1.6 (metric 110) from 5.5.5.5 (5.5.5.5)
      Origin incomplete, metric 409600, localpref 100, valid, internal
  2
    12.1.1.5 (metric 20) from 4.4.4.4 (4.4.4.4)S IP BG
      Origin incomplete, metric 409600, localpref 5000, valid, internal, best


 I now trace to R9 again and can see the path taken is the OER selected best route.

trace 9.9.9.9
Type escape sequence to abort.
Tracing the route to 9.9.9.9

  1 10.10.10.1 28 msec 44 msec 32 msec
  2 12.1.1.5 36 msec 56 msec 32 msec
  3 20.0.0.9 [AS 2] 36 msec *  72 msec

Alternatives to VXLAN

NVGRE

NVGRE (Network Virtualization Generic Routing Encapsulation) achieves the same functional goal as VXLAN on the network, however the encapsulation of VLAN traffic is done on the virtualised server instead.   In essence the network VLAN limitations are overcome by application software.

The server builds a gre tunnel and the virtual subnet id is included in the GRE header.  Each virtual machine is mapped to a host PA (physical address).  End to end communication is completed over existing networks that are essentially unaware of the encapsulated payloads and server vlan mappings.

IP Rewrite

An alternative approach to GRE tunnelling is ‘IP rewrite’. This solution requires each virtual server has its own IP address. This ip address is rewritten to a physical ip address for transport across the network.  This mapping is reversed on reaching the destination.  

CISCO OTV
OTV or Overlay Transport Virtualisation is Cisco's proprietary solution to extending VLANs over IP networks. It encapsulates L2 within IP allowing VLANs to be tunneled over a routed IP network. It is currently enabled on the NEXUS OS.

TRILL

Transparent Interconnection of Lots Of Links or TRILL, enables extension of L2 domains, through use of RBridges or (Routing Bridges).  TRILL RBridges communicate with a link state protocol, however this  executes within the L2 domain i.e. no ip addresses are required.  RBridges have knowledge of the topology consisting of all the RBridges and all the links between RBridges.

When an RBridge receives an Ethernet frame from an end node it encapsulates the frame in a TRILL header, addressing the packet to the RBridge with the destination MAC attached to it.  The destination RBridge performs the decapsulation before sending the packet onwards.

TRILL like the other technoloigies described enables a large L2 cloud to be created with a common subnet. Therefore hosts within the L2 cloud do NOT need  to change their ip address if they relocate. TRILL is an ietf standard.

to be continued .....

VXLANs - Building On VLANS

VLANS have been around ever since I have been in networking, providing a network segregation function at Layer 2.  

802.1q is the IEEE standard that defines VLAN tagging. In summary a 32 bit field is added between source MAC and Ether Type field in an Ethernet Frame.  12 bits of this field were set aside for the VLAN id, so enabling 4094 vlans.  

In hindsight only setting aside 12 bits to the VLAN id could now be viewed as an oversight.   Today especially in the Cloud Infrastructure space, single physical topologies, have now become multi tenanted spaces each requiring their own isolated network.   4094 vlans has become a constraint.

Additionally when the VLAN concept was derived it was designed to run in a ‘localised’ environment. Today there are requirements for multiple physical environments to be logically connected at L2.

VXLAN or Virtual eXtensible LANs aim to build upon the existing VLAN concept but solve some of the problems described. Firstly the VXLAN id is 24 bits, doubling the old VLAN id field size, and enabling over 16 million VLAN ids.     Secondly VXLAN extends the reach of VLAN by enabling VLANs to be transported or encapsulation over an IP, Layer 3 routed domain.

VXLAN does not represent the only solution to the VLAN limitations of 802.1Q.  I hope to post on some of the other solutions available.

Zone Based Firewall

I interface
P olicy
Z one pair
A pply

Each interface is assigned a security zone

A zone pair specify a one way firewall policy between 2 zones

INTERFACES
int fa0/0
zone-member security outside

int s0/1/0
zone-member securty inside

ZONE-PAIRS
zone-pair security {name} source inside dest outside

POLICY
class-map type inspect match-any ALLOWED
match telnet

policy-map type inspect FWPOLICY
class type inspect ALLOWED
inspect

APPLY
zone-pair security inside-to-outside
service-policy type inspect  FWPOLICY

show zone security
show zone-pair security
show class-map type inspect ALLOWED


I nterface
P policy
Z one pair
S ervice policy

Step 1: Define and populate our zones:

configure terminal
!
zone security ZONE_PRIVATE
zone security ZONE_INTERNET
!
interface range fa0/0 - 1
zone-member security ZONE_PRIVATE
!
interface s0/0
zone-member security ZONE_INTERNET

Step 2: Define the class maps that identify traffic that is permitted between zones:

configure terminal
!
class-map type inspect match-any CM_INTERNET_TRAFFIC
match protocol http
match protocol https
match protocol ftp

Step 3: Configure a policy map which specifies the action for the class map:

configure terminal
!
policy-map type inspect PM_PRIVATE_TO_INTERNET
class type inspect CM_INTERNET_TRAFFIC
inspect

Step 4: Configure the zone pair and apply your policy:

configure terminal
zone-pair security ZONEP_PRIV_INT source ZONE_PRIVATE destination ZONE_INTERNET
service-policy type inspect PM_PRIVATE_TO_INTERNET

ANOTHER EXAMPLE!!!!! 

class-map type inspect match-any Guest_Protocols
 match protocol http
 match protocol https
 match protocol dns
class-map type inspect match-any All_Protocols
 match protocol tcp
 match protocol udp
 match protocol icmp
!
policy-map type inspect Trusted
 class class-default
  pass
policy-map type inspect Guest_to_Internet
 class type inspect Guest_Protocols
  inspect 
 class class-default
  drop
policy-map type inspect Trusted_to_Internet
 class type inspect All_Protocols
  inspect 
 class class-default
  drop
!         
zone security Trusted
zone security Guest
zone security Internet
zone-pair security Trusted source Trusted destination Trusted
 service-policy type inspect Trusted
zone-pair security Trusted->Internet source Trusted destination Internet
 service-policy type inspect Trusted_to_Internet
zone-pair security Guest->Internet source Guest destination Internet
 service-policy type inspect Guest_to_Internet 

 MY EXAMPLE !!!!!!!


Just a basic Zone Based Firewall Example

R1 -----------------1.1.1.4 FA0/0 R4 2.2.2.4 FA0/1 -------------------- R3


CONFIG ON R4

zone security RICHPRIVATE
zone security RICHINTERNET

Int fa0/0
 zone-member security RICHPRIVATE

Int fa0/1
 zone-member security RICHINTERNET

class-map type inspect match-any ALLOW
 match protocol telnet
 match protocol icmp

policy-map type inspect RICHINSPECT
 class type inspect ALLOW
  inspect

zone-pair security RICHPRIVATE-TO-INTERNET source RICHPRIVATE destination RICHINTERNET
 service-policy type inspect RICHINSPECT


R4#show policy-map type inspect zone-pair

policy exists on zp RICHPRIVATE-TO-INTERNET
 Zone-pair: RICHPRIVATE-TO-INTERNET

  Service-policy inspect : RICHINSPECT

    Class-map: ALLOW (match-any)
      Match: protocol telnet
        0 packets, 0 bytes
        30 second rate 0 bps
      Match: protocol icmp
        1 packets, 80 bytes
        30 second rate 0 bps

   Inspect
        Packet inspection statistics [process switch:fast switch]
        icmp packets: [0:10]

        Session creations since subsystem startup or last reset 1
        Current session counts (estab/half-open/terminating) [0:0:0]
        Maxever session counts (estab/half-open/terminating) [0:1:0]
        Last session created 00:04:54
        Last statistic reset never
        Last session creation rate 0
        Maxever session creation rate 1
        Last half-open session total 0

    Class-map: class-default (match-any)
      Match: any
      Drop
        0 packets, 0 bytes

Great troubleshooting command 

ip inspect log drop-pkt