Rpl

© 2006 Cisco Systems, Inc. All rights reserved. Cisco Confidential Presentation_ID 1

Advanced IOS-XR Training RPL in depth


Why RPL

Scaling

Using route-maps on IOX scale could lead to configs in the several 100k lines to over a million depending on number of peers this doesn‟t scale. How do we solve the scaling problem.

Rewrote a major isp‟s 15k lines of route-maps in 1k lines of RPL won‟t always get this kind of reduction :-{


Scaling policy (add reuse)

Modularity

Exploit modularity to reuse common portions of configs

Parameterization

For elements which are not exact copies of each other we can add parameterization ( think variables ) to get further re-use.


Improve the clarity

No silently skipped statements: wysiwyg

Explicit logic relationships

Match ip community-list 10 20

Is this a logical or or a logical and ?

User defined control flow -- no forced structure to match statements

All elements should have meaningful names

Inline lists where needed


RPL Definitions

AttachPoint

Any place in the system that binds the use of a specific policy for a specific purpose.

Example:

router bgp 2

neighbor 1.2.3.3

address-family ipv4 unicast

policy foo in

policy bar out


RPL Definitions continued

Hierarchical policy

A policy which refers to another policy with an apply statement

Example:

route-policy one

set med 100

end-policy

route-policy two

apply one

set community (10:100)

end-policy


RPL Definitions continued

Parameterized policy

A hierarchical policy that passes values e.g.

route-policy one ($med)

set med $med

end-policy

route-policy two

apply one (10)

end-policy


RPL Syntax Review


RPL Lexicon

BGP Attribute(s) RPL Attribute(s) RPL Operation(s)

next-hop source pass / drop

weight destination suppress-route

local-preference route-type unsuppress-route

med rib-has-route length, unique-length

origin traffic-index set

as-path dampening apply

community label If, then

ext community tag else, elseif

rd and, or, not

eq, neq, le, gt

in, is

ios-regex


If-then, Elseif, Nested If

An if statement uses a conditional expression to decide which actions or dispositions should be taken for the given route.

if as-path in as-path-set-1 then

drop

endif

The if statement also permits an else clause, which is executed if the

expression is false.

if med eq 150 then

set local-preference 10

elseif med eq 200 then


else


endif


If-then, Elseif, Nested If (Continue …)

The statements within an if statement may themselves be if statements, as shown

in the following

if community matches-every(12:34, 56:78) then

if med eq 8 then

drop

endif


endif


Boolean Expressions

Boolean expressions evaluate as either true or false.

The routing policy language provides means to build compound conditions

from simple conditions by means of Boolean operators.

There are three Boolean operators : negation (not), conjunction (and), and disjunction (or).

RP/0/1/0:pod1(config-rpl)#if med eq 42 and next-hop in (1.1.1.1) then


Compound Booleans

The RPL provides means to build compound conditions from simple

conditions by means of Boolean operators. There are three Boolean operators: negation (not), conjunction (and), and disjunction (or).

med eq 10 and not destination in (10.1.3.0/24) or community is (56:78)

med eq 10 and (not destination in (10.1.3.0/24)) or community is (56:78 )


Sets

The term set is used in its mathematical sense to mean an unordered collection of unique elements. The policy language provides sets as a container for groups of values for matching purposes.

They are used in conditional expressions. The elements of the set are separated by commas.

There are four kinds of sets as-path-set, community-set, extcommunity-set and prefix-set .


Prefix, Community, AS-PATH Sets

prefix-set

A prefix-set holds IPv4/IPv6 prefix match specifications, each of which has

four parts: an address, a mask length, a minimum matching length, and a maximum matching length.

community-set

A community-set holds community values for matching against the BGP community attribute. A community is a 2 * 16-bit quantity. For notational convenience, each community value is expressed as two unsigned decimal integers in the range 0 to 65535, separated by a colon.

as-path-set

An as-path-set comprises operations for matching an AS path attribute. The

only matching operation is a regular expression match, compatible with the as-regexp provided by IOS in ip as-path access-list


Prefix Sets (prefix, mask length, minimum match length, maximum match length)

A prefix-set holds IPv4 and v6 prefix match specifications, each of which has four parts: an address, a mask length, a minimum matching length, and a maximum matching length.

The address is required, but the other three parts are optional.

Address: a standard format IPV4 or IPV6 address

mask length : is a nonnegative decimal integer in the range from 0 to 32 following the address and separated from it by a slash.

minimum matching length : is expressed as the keyword ge (mnemonic for greater than or equal to).

maximum matching length : is expressed by the keyword le (mnemonic for less than or equal to).

10.0.3.0/24 ge 28,

10.0.4.0/24 le 28,

10.0.5.0/24 ge 26 le 30,


AS-PATH Sets

An as-path-set comprises operations for matching an AS path attribute. The only matching operation is a regular expression match, compatible with the as-regexp provided by IOS in ip as-path access-list

as-path-set aset1

ios-regex ‟_42$‟,

ios-regex ‟_127$‟

end-set


Community Sets

A community-set holds community values for matching against the BGP community attribute. A community is a 2*16-bit quantity. For notational convenience, each community value is expressed as two unsigned decimal integers in the range 0 to 65535, separated by a colon.

community-set cset1

12:34,

12:78,

internet

end-set


Extended Community Set

An extended community-set is analogous to a community set only it contains extended community values instead of regular community values. It also supports named forms and inline forms.

extcommunity-set ?

cost EIGRP Cost Community type extended community

rt BGP Route Target (RT) extended community

soo BGP Site of Origin (SoO) extended community


Hierarchical Policy Structure

route-policy one

set weight 100

end-policy

route-policy two

set med 200

end-policy

route-policy three

apply two

set community (2:666) additive

end-policy

route-policy four

apply one

apply three

pass

end-policy


RPL BGP Attributes and Operations


AS-PATH

AS-PATH -- Match

AS-PATH -- Assignment

route-policy prepend-example

prepend as-path 2 3

prepend as-path 666 2

end-policy

if as-path in as-path-set-1 then

drop

endif


AS-PATH contd..

if (as-path is-local) then


endif

AS-PATH – is-local

AS-PATH – neighbor-is

if as-path neighbor-is ‟10‟ then ...

if as-path neighbor-is ‟$asnum‟ then ...

if as-path neighbor-is ‟10 20‟ then ..


AS-PATH contd..

if as-path passes-through ‟10‟ then ...

if as-path passes-through ‟$asnum‟ then ...

if as-path passes-through ‟10 11‟ then ...

if as-path passes-through ‟10 $asnum 12‟ then

AS-PATH – Passes-through

AS-PATH – Originates-from

if as-path originates-from „10‟ then

if as-path originates-from „11 10‟ then

if as-path originates-from $asnum then


AS-Path continued

as-path length unique-length

if as-path length is 10 then ...

if as-path length ge 10 and destination in (0.0.0.0/0 ge 24 le 32) then ...

if as-path unique-length is 10 then ...

if as-path uniquelength ge 10 and destination in (0.0.0.0/0 ge 24 le 32)

then ...


Community

Community -- Match

if community matches-any cs2 then

set med 12 Endif if community matches-every (10:12, internet, 10:33) then set med 33 endif

Community -- Assignment


set community (10:12) additive


Dampening

route-policy foo-damp if destination in (0.0.0.0/0 ge 25) then set dampening halflife 42 others default set dampening max-suppress 15 halflife 42 others default else set dampening halflife 15 max-suppress 60 reuse 750 suppress 2000 endif end-policy

Dampening -- Assignment


Destination

Destination -- Match

if destination in (10.0.0.0/8 ge 8 le 32) then


endif


Extcommunity

Extended Community -- Match

if extcommunity [rt|soo] [is-empty|matches-any|matches-every] …

Extended Community -- Assignment

set extommunity [cost|rt] ….


Local-Preference - Assignment

Local-Preference assignment



MED

MED -- Match

if (med eq 10) then ...

MED -- Assignment

set med 10

MED -- Increment/Decrement

set med +5

set med -2

MED -- Special Values

set med igp-cost

set med inaccessible

set med max-reachable


Next-Hop

Next-Hop -- Match

if next-hop in some-prefix-set then ...

if next-hop in (1.2.3.4, 2.3.4.5) then ...


Origin

Origin -- Match BGP origin attribute

if origin is igp or origin is incomplete then …

Origin -- Assignment

set origin [incomplete| igp | egp]


Rib-has-route

if rib-has-route (10.0.0.0/16 ge 16 le 32) then

Rib-has-route -- check if rib has route (default origination)


Route-Distinguisher

if rd in my-rd-set then

if rd in (11:11, 1.2.3.4:11, 22:*,10.0.0.0/8:10) then

Compare against VPN-IPv4 routes.


Source

Source -- Match source address

if source in my_prefix_set then ...


Suppress-route

Suppress-route is an action used to suppress more specific routes when an aggregate is built

If (destination in 10.0.0.0/16 ge 24 le 32) then

suppress-route

endif


Unsuppress-route

unsuppress-route is an action used to override the suppression of more-specific routes when an aggregate is built.

If (destination in 10.0.0.0/16 ge 16 le 24) then

unsuppress-route

endif


Tag

Tag -- Match

used in route redistribution

if tag eq 10 then …

Tag -- Assignment

set tag 20


Traffic-Index

Traffic-Index -- Assignment

supports bgp policy accounting feature

set traffic-index 10


Weight

Weight -- Assignment

set weight 100


RPL-Specific Show Commands


show rpl policy

RP/0/0/0:ios#show rpl policy example_three uses all

Policies directly and indirectly applied by this policy:

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

example_one set-comms

Sets referenced directly and indirectly

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

(via applied policies) in this policy:

type prefix-set:

ten-net too-specific


show rpl <policy-type> <policy-name> attachpoints

RP/0/0/CPU0:ios#show rpl route-policy my_policy attachpoints

BGP Attachpoint: Network

Network afi/safi vrf name

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

80.21.10.32/27 IPv4/uni default

80.21.10.160/27 IPv4/uni default


show rpl <policy-type> <policy-name> detail

RP/0/0/CPU0:ios#show rpl route-policy my_policy

route-policy my_policy


set community (1276:4, 1276:1000, 1276:1009, no-export) additive

end-policy

!


show rpl <policy-type> states

RP/0/0/CPU0:ios#show rpl route-policy states

ACTIVE -- Referenced by at least one policy which is attached

INACTIVE -- Only referenced by policies which are not attached

UNUSED -- Not attached (directly or indirectly) and not referenced

The following policies are (ACTIVE)

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

route-policy my_policy


set community (1276:4, 1276:1000, 1276:1009, no-export) additive

end-policy

!

The following policies are (INACTIVE)

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

None found with this status.

The following policies are (UNUSED)

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

route-policy FR_STATIC

# Customer Global aggregation

if (tag eq 10700) then


set origin igp


# public specific addresses

elseif (tag eq 21000) then


set origin igp


endif

end-policy


show bgp policy route-policy <name>

RP/0/0/1:router#show bgp route-policy sample

BGP router identifier 172.20.1.1, local AS number 1820

BGP main routing table version 729

Dampening enabled

BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, S stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

* 10.13.0.0/16 192.168.40.24 0 1878 704 701 200 ?

* 10.16.0.0/16 192.168.40.24 0 1878 704 701 i

NOTE – only prefixes already installed in the BRIB that match the policy will be shown


Other Show Commands

Show rpl policy <name> detail

Show rpl policy <name> attachpoints

Show rpl policy <name> references

Show rpl policy <name> uses


Rules of RPL


RPL

Verification

Control Flow

Default-Drop

Semantics to be aware of

Hierarchy and Parameterization


RPL Verification

Verification

Beyond syntax verification

Per attachpoint verification ensures all statements in a policy are sane for this protocol.

Statements which cannot be executed are not silently skipped


RPL Verification continued

When does verification occur

At policy definition time

incomplete policies are allowed for user input

At AttachPoint bind time

Policy must be completely defined -

no incomplete references.

All statements must be valid for protocol and AttachPoint


RPL Verification continued

Policy Definition change

When a policy definition is changed or a component of the policy is changed, the change must be acceptable for all locations in the system where the policy is currently in use

The change is verified against all existing attachpoints, and any failure causes the change to be rejected


RPL Control Flow

Control passes sequentially statement to statement with logic following user defined if then else-if else paths.

With route-maps typically you have the strictest match cases followed by more and more general cases due to the first match clause wins rule. This can lead to inefficient configs


Control Flow continued

Nesting if‟s allows preconditions to be specified once.

May allow faster execution as well.

If ((destination in allowed-prefixes) and (not destination in rfc-1918)) then

If (community matches-any (10:102)) then


elseif (community matches-any (10:103)) then


elseif (community matches-any (10:104) then


endif

endif


Control Flow continued

All statements are executed unless a “drop” is encountered. Drop is the only statement that stops continued execution of the policy

Applied policies are analogous to an inline insertion of the policy text

A given attribute can be set more than once, which allows one to override previous values for attributes which can only take on a single value


Default Drop

Like route-maps, RPL has a default drop condition.

In general if the route is not accepted it is dropped.

In route-maps this is controlled by a “successful match”.

In RPL this is controlled by an attempt to modify a route attribute or hitting the pass statement.

Any attribute set at any level of hierarchy is sufficient to defeat default drop.

An explicit drop is always honored.

Processing stops at an explicit drop.


RPL Semantics continued

MED/cost/metric

In RPL, the attribute metric is NOT overloaded in each protocol. Per-Protocol metrics are specified explicitly.

Protocol Keyword

BGP med

OSPF ospf-metric

ISIS metric(deprecated)

isis-metric

EIGRP eigrp-metric

RIP rip-metric


RPL Semantics continued

All matches are performed on original route data not intermediate results

Thus a policy which sets the med to 42 and then checks to see if the med is 42 in the next statement, will only execute the true branch of the if statement if the route originally had a med of 42 before any policy was applied

if med eq 12 then set med 42 if med eq 42 then drop endif endif

This policy will never execute the drop statement, because the

second test (med eq 42) sees the original, unmodified value

(med eq 12) of the MED in the route.



When any policy or set is modified, that change affects all instances of policy hierarchies that reference the modified policy or set

Thus changing a martians policy which may be used at several attachpoints can have a large effect on the box



Looping/recursion is not allowed

As many layers of hierarchy or parameters that you want

Parameters can be passed through a policy block

Parameters are passed by value only (passed by reference in 3.5)


EBGP peers must have Policy

It is now a requirement that all eBGP peers must have a policy applied or no routes are sent or received. There is no receive and install all routes if no policy is applied

Some providers do this as a matter of course. When turning up peers they first use a drop everything policy until the peer is stable

The failure case is also better wrt the rest of the network


Policies/Sets as Configuration objects

All route-policies and sets are treated as individual objects rather than a group of related but independent lines of config so a complete policy or set is entered stored verified run etc.


No Nested Denies

Sets in RPL don‟t carry the notion of permit and deny

Permit and deny are controlled explicitly by policy execution

You can‟t have something like a route-map with a deny clause in it that refers to a prefix-list with both permit and denies in the prefix-list

Sets are simply containers of data which are referred to by policies


RPL AttachPoints


Operators are Scoped to AttachPoints

All RPL operations are relative to the scope of the AttachPoint that the policy is attached to.

Not all operations are permitted at all attachpoints

For example:

Setting traffic-index can only be done at the table-policy AttachPoint

rib-has-route can only be used at the default-origination AttachPoint

Next-hop is the only attribute that can be set within a VRF-import policy.


Operators are Scoped to AttachPoints

AttachPoint semantics are enforced at the time the policy is verified.

Ensures all statements in a policy are sane for this AttachPoint

Statements which cannot be executed cause error(s).

The attachment fails and a warning is issued:

% Failed to commit one or more configuration items during an atomic operation, no changes have been made. Please use 'show configuration failed' to view the errors

RP/0/8/CPU0:TC-PE1(config-vrf-af)# sho conf fail

Mon Feb 20 10:23:46.104 UTC!! CONFIGURATION FAILED DUE TO SEMANTIC ERRORS

vrf OPNET


import route-policy GRX!!%

Could not find entry in list: Policy [GRX] uses 'assign local-preference'. 'set' is not a valid operator for the 'local-preference' attribute at the BGP import attach point.


BGP Attachpoints

BGP Process

Network command

Aggregation

Default-originate

Dampening

Redistribution

BGP Neighbor

Neighbor inbound

Neighbor outbound

Neighbor ORF

BGP Policy Accounting

Table policy

MPLS/VPN

VRF Import

VRF Export

Label-Allocate

Some BGP show commands


BGP AttachPoints Supported Operators/Attributes

AttachPoint/Attribute

pass / d

rop

destin

atio

n

orf-p

refix

next-h

op

weig

ht

local-p

refe

rence

med

orig

in

as-p

ath

as-p

ath

length

com

munity

ext c

om

munity

(cost)

ext c

om

munity

(rt)

ext c

om

munity

(so0)

suppre

ss

unsuppre

ss

dam

penin

g

traffic

-index

sourc

e

route

-type

rib-h

as-ro

ute

label

•Notes

m = match

s = set

•* = supported

neighbor in * m m/s s s m/s m/s m/s m m/s s m/s m m

neighbor out * m m/s m/s m/s m/s m m/s s m/s m s m

neighbor orf * m

netw ork * m s s s s s m/s s s s s

aggregation * m m/s s s m/s m/s m m m/s s s m „Set‟ attributes

applied only to

aggregate NLRI

default originate * s m

redistribute * s s s s s s s m

dampening * m m m m m m m s m

table policy * m m m m m m m s m

VRF import * m m/s m m m m m m m m

VRF export * m m s s m m m m m/s m/s m m

allocate-label * m m m m m m m s

Show cmd * m m m m m m m m m m


IGP Attachpoints

OSPF, OSPFv3

Default originate

IPV4 Redistribution

Area in/out (LSA-Type 3)

ISIS

Default originate

IPV4 Redistribution

EIGRP

Default (in/out)

IPV4 Redistribution

Global (in/out)

Interface (in/out)

RIP

Default originate

IPV4 Redistribution

Global (in/out)

Interface (in/out)


IGP AttachPoints Supported Operators/Attributes


pass / d

rop

destin

atio

n

next-h

op

tag

ospf-c

ost

rip-m

etric

isis

-metric

eig

rp-m

etric

level

metric

-type

pro

tocol

route

-type

rib-h

as-ro

ute

•Notes

m = match

s = set

•* = supported

OSPF

default originate * s s m

redistribute * m m/s s s m

area-in * m

area-out * m m

ISIS

default originate * m m m s s s m m

redistribute * m s m s s s m m


IGP AttachPoints Supported Operators/Attributes


pass / d

rop

destin

atio

n

next-h

op

tag

ospf-c

ost

rip-m

etric

isis

-metric

eig

rp-m

etric

level

metric

-type

pro

tocol

route

-type

rib-h

as-ro

ute

•Notes

m = match

s = set

•* = supported

EIGRP

redistribute * m m m/s s m m

default accept-in * m

default accept-out * m

global-inbound * m m m/s s

global-outbound * m m m/s s m

Interface-in * m m s

Interface-out * m m m/s s m

RIP

default originate * s s m

redistribute * s s

global-inbound * m m m/s s

global-outbound * m m/s s m

Interface-in * m m m/s s

Interface-out * m m/s s m


Route-Maps at AttachPoints

IOS-style Route-maps used to be allowed at AttachPoints.

Route-maps for certain applications are no longer supported.

Bug fixes and maintenance is not being done on IOX route-map code


Exploiting RPL


Exploiting RPL

To get the best advantages of RPL you‟ll need to spend some time looking at your router configs

Look for common subtasks that can exploit the power of parameterization and/or reuse

Convert them to hierarchical policy blocks or parameterized policy blocks which can be reused


Exploiting RPL

Replace small lists of prefixes or communities with inline forms

Look for ways of eliminating repeated matches by using nested if then else structures


Exploiting RPL

Look at control flow issues. Can a given policy be re-arranged to be more easily understood and/or require less repetition?

RPL allows you to set an attribute value more than once

Therefore you can set a default local preference and further in the policy change the local preference for a specific case which requires a different value


Exploiting RPL

Reevaluate the items within your access-lists, prefix-lists, as-path-lists, etc. Remove those that are no longer relevant.

To get the best conversions think about what does the policy do and what does it share in common with other policies

Don‟t be afraid to write the policies that you need rather than just doing a simple line for line translation of your route-maps

You‟ll be surprised about the historical cruft you may find


Converting Route-Maps into RPL


Converting Route Maps to RPL Policies

To convert a route-map to RPL we will use the following high-level process:

• Step 1. Do a simple syntax translation • Step 2. Nest Conditionals to Reduce Repetitive Comparisons • Step 3. Use Inline Sets to Remove Small Indirect Set References • Step 4. Parameterize to Reuse Common Structures


Step 1: Direct Syntax Translation

• Each Route-Map becomes a route-policy • Each clause in a route-map becomes a clause in an if-then-else sequence.

• For each clause:

• Map each „match‟ to the corresponding conditional. • Map each „set‟ to the corresponding „action‟.

route-map PROCESS_INBOUND deny 5 match as-path 150 ! route-map PROCESS_INBOUND permit 10 match as-path 10 match community 1 set local-preference 70 set community 100:500 100:505 100:999 additive ! route-map PROCESS_INBOUND permit 20 match as-path 10 match community 2 set local-preference 80 set community 100:500 100:505 100:999 additive ! route-map PROCESS_INBOUND permit 30 set local-preference 90 set community 100:500 100:505 100:999 additive !

route-policy PROCESS_INBOUND if (as-path in aspath_150) then drop elseif ((community matches-any comm_1) and (as-path in aspath_10)) then set local-preference 70 set community (100:500, 100:505, 100:999) additive elseif ((community matches-any comm_2) and (as-path in aspath_10)) then set local-preference 80 set community (100:500, 100:505, 100:999) additive else set local-preference 90 set community (100:500, 100:505, 100:999) additive endif end-policy


Step 2: Nest Conditionals

• Collect similar conditions into nested „if‟ statements.

route-policy PROCESS_INBOUND

if (as-path in as_path_150) then

drop

elseif (as-path in as_path_10) then

if (community matches-any comm_1) then


set community (100:500, 100:505, 100:999) additive

elseif (community matches-any comm_2) then



endif

else



endif

end-policy


Step 3: Use Inline Sets

• Small Sets (AS-Path-Set, Community-Set, etc.) can be replaced with inline sets.

route-policy PROCESS_INBOUND if (as-path in '_701_‟, '_3561_‟) then drop elseif (as-path in '^21409_') then if (community matches-any „5511:70‟) then set local-preference 70 set community (100:500, 100:505, 100:999) additive elseif (community matches-any „5511:80‟) then set local-preference 80 set community (100:500, 100:505, 100:999) additive endif else set local-preference 90 set community (100:500, 100:505, 100:999) additive endif end-policy


Step 4: Parameterize

• Similar actions can be grouped into a common policy with parameters.

route-policy set_attributes ($pref)

set local-preference $pref

set community (100:500:, 100:505, 100:999) additive

end-policy

!

route-policy PROCESS_INBOUND

if (as-path in '_701_‟, '_3561_‟) then

drop

elseif (as-path in ' 2̂1409_') then

if (community matches-any „5511:70‟) then

apply set_attributes (70)

elseif (community matches-any „5511:80‟) then


endif

else


endif

end-policy


Using Named Sets as Parameters

In 3.3.0, we added the ability to pass named sets as parameters.

prefix-set foo 10.0.3.0/24 ge 28, 10.0.4.0/24 le 28, 10.0.5.0/24 ge 26 le 30 end-set

route-policy my-neighbor

apply do-filtering(foo)

apply other-stuff

end-policy

route-policy do-filtering($set)

if not destination in $set then drop

endif

end-policy


Using BGP Global Variables as Parameters

In 3.2.0, we added the global variable $PEERIP (for BGP attach points) – the peer IP address from attach point.

Since this is a “global” it doesn‟t have to be a declared parameter.

We are targeting 3.5.0 for adding $PEERAS (for BGP attach points) – the peer AS number, for use in community expressions (limited to 16 bit communities).

NOTE: Extending RPL to support parameters can break BGP internal “update grouping”. These changes ARE coordinated with changes in BGP code, however, customers should verify the affects on convergence of parameters by comparing with non-parameterized policies.


Points to Ponder

When converting route-maps, some items require special consideration:

• Route-Maps which reference access-list(s)

• Route-Maps that reference policy-list(s) [Community, AS-Path, Prefix-List] with mixed entries.

• Combinations of policies specified via BGP cli & Route-Map(s).


• Route-Maps often use access-list(s) to reference NLRI (prefixes)

• There is no direct-equivalent to an ACL in RPL.

• The clause must be converted to something RPL can use: prefix-set

Route-Maps with access-list(s)

route-map BLOCK_BOGON deny 10 match ip address 199 ! access-list 199 permit ip host 0.0.0.0 any access-list 199 permit ip 127.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 access-list 199 permit ip 10.0.0.0 0.255.255.255 255.0.0.0 0.255.255.255 access-list 199 permit ip 172.16.0.0 0.15.255.255 255.240.0.0 0.15.255.255 access-list 199 permit ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 199 permit ip 128.0.0.0 0.0.255.255 255.255.0.0 0.0.255.255 access-list 199 permit ip 223.255.255.0 0.0.0.255 255.255.255.0 0.0.0.255 access-list 199 permit ip 224.0.0.0 31.255.255.255 224.0.0.0 31.255.255.255

prefix-set pfx_acl_199 0.0.0.0/32, 127.0.0.0/8 ge 8, 10.0.0.0/8 ge 8, 172.16.0.0/12 ge 12, 192.168.0.0/16 ge 16, 128.0.0.0/16 ge 16, 223.255.255.0/24 ge 24, 224.0.0.0/3 ge 3 end-set ! route-policy BLOCK_BOGON if (not destination in pfx_acl_199) then pass endif end-policy !


• Recall, that sets within IOX do not convey the concept of permit or deny - only membership.

• So, how does the following policy get converted ?

Policy Lists with mixed entries.

ip prefix-list martians seq 10 permit 0.0.0.0/0 ip prefix-list martians seq 20 permit 127.0.0.0/8 le 32 ip prefix-list martians seq 30 deny 10.192.0.0/10 ge 12 le 21 ip prefix-list martians seq 40 permit 10.0.0.0/8 le 32 ip prefix-list martians seq 50 permit 172.16.0.0/12 le 32 ip prefix-list martians seq 60 permit 192.168.0.0/16 le 32 ip prefix-list martians seq 70 permit 128.0.0.0/16 le 32 ip prefix-list martians seq 80 permit 192.0.0.0/24 le 32 ip prefix-list martians seq 90 permit 223.255.255.0/24 le 32 ip prefix-list martians seq 100 permit 224.0.0.0/3 le 32 ip prefix-list martians seq 110 permit 192.157.69.0/24 le 32 route-map CUST-FACE deny 10 match ip address prefix-list martians


Keep all of the „permit‟s ?


prefix-set pfx_martians 0.0.0.0/0, 127.0.0.0/8 le 32, 10.0.0.0/8 le 32, 172.16.0.0/12 le 32, 192.168.0.0/16 le 32, 128.0.0.0/16 le 32, 192.0.0.0/24 le 32, 223.255.255.0/24 le 32, 224.0.0.0/3 le 32, 192.157.69.0/24 le 32 end-set route-policy CUST_FACE if (destination in pfx_martians) then drop else pass endif end-policy !

prefix-set pfx_martians 10.192.0.0/10 ge 12 le 21, end-set route-policy CUST_FACE if (destination in pfx_martians) then pass else drop endif end-policy !

Keep all of the „deny‟s ?


The answer is: BOTH ! 1) Partition the prefix-list into separate

sections - each containing a string of „permit‟ or „deny‟ entries.

2) Create a prefix-set to correspond to each section.

3) Adjust the route-policy to process each partition in turn.

Keeping the partitions in order is

important to preserve the original logic with respect to overlapping entries.

The same process can be applied to

as-path-set(s) & community-set(s).


prefix-set pfx_martians_p1_permit 0.0.0.0/0 127.0.0.0/8 le 32 end-set ! prefix-set pfx_martians_p2_deny 10.192.0.0/10 ge 12 le 21 end-set ! prefix-set pfx_martians_p3_permit 10.0.0.0/8 le 32, 172.16.0.0/12 le 32, 192.168.0.0/16 le 32, 128.0.0.0/16 le 32, 191.255.0.0/16 le 32, 192.0.0.0/24 le 32, 223.255.255.0/24 le 32, 224.0.0.0/3 le 32, 192.157.69.0/24 le 32 end-set ! route-policy CUST_FACE if (destination in pfx_martians_p1_permit) then drop elseif (destination in pfx_martians_p2_deny) then pass elseif (destination in pfx_martians_p3_permit) then drop endif end-policy


• Remember, not all BGP policy is specified within Route-Maps. • Some policy can be specified as part of per-neighbor cli.

BGP Combinatorial policies

router bgp 200

neighbor 206.223.137.126 remote-as 666

neighbor 206.223.137.126 description XXXX

neighbor 206.223.137.126 prefix-list FR-ISP in

neighbor 206.223.137.126 route-map FR-ISP in

neighbor 206.223.137.126 filter-list 99 in

!

route-map FR-ISP permit 10

set metric 0

set community 1276:31000

!

ip prefix-list FR-ISP seq 5 deny 0.0.0.0/0 le 7

ip prefix-list FR-ISP seq 10 deny 0.0.0.0/0 ge 25


ip prefix-list FR-ISP seq 30 permit 172.205.128.0/17



ip prefix-list FR-ISP seq 90 permit 0.0.0.0/0 le 32

!


• IOX does not allow individual filter-items to be specified per-neighbor.

• A new policy must be created which incorporates ALL of the original items.

BGP Combinatorial policies

router bgp 200

neighbor 206.223.137.126

remote-as 666

description XXXX


route-policy policy_nbr_206_223_137_126__ipv4_unicast_in

!

route-policy FR_ISP

set metric 0


end-policy

!

route-policy policy_nbr_206_223_137_126__ipv4_unicast_in

if (as-path in aspath_99) then

if (destination in pfx_FR_ISP_p1_deny) then

drop

elseif (destination in pfx_FR_ISP_p2_permit) then

apply FR_ISP

elseif (destination in pfx_FR_ISP_p3_deny) then

drop

elseif (destination in pfx_FR_ISP_p4_permit) then

apply FR_ISP

endif

endif

end-policy

!


RPL Scale

RPL configuration:

Up to 5,000 policies

Up to 128K lines of configuration

Per route-policy object:

Up to 500 statements

Up to 512 nested if statements

Per if statement:

Up to 16 conditions

Up to 512 elseif clauses

Per statement execution time:

In the order of 1 to 5 micro sec


RPL Test Feature Feedback

We have under development a tool to test policy results from the CLI. The first test point is BGP attach point.

The idea to present a prefix with attach point specific parameters (in a pre-dictated format) and return BGP RIB formatted results.

In addition, it will be possible to use a text file (each line similarly formatted) to test a group of routes.

See proposal in notes.

96 96 96 © 2004, Cisco Systems, Inc. All rights reserved.

Presentation_ID

Documents

Rpl