Routing utilities¶

Routing packets requires to handle the core element of a routing table : the prefix. Prefix is generally an IPv4 or an IPv6 address associated with a mask. There are needs on routing protocols to have tools that permit apply some filtering. This is true for BGP, but it is also true for OSPF. Some information is given about 2 useful tools that are used on the above mentioned routing protocols : IPv4 Access-Lists and IPv4 Prefix-List.

Also, this chapter presents the route-map object. This objects works on the match/set mechanism. It is feeded by input given by routing protocols, and it returns an output that is modified to be conform with the set rules contained in the route-map.

Finally, this chapter gives an overview about routing priorities between the various routing protocols, by explaining the distance.

IPv4/IPv6 Access-Lists
IP Prefix List
Route-Maps
Global Routing options per VRF
- Route-map filtering per protocol
- Nexthop Tracking
Routing Administrative Distance
Logging

IPv4/IPv6 Access-Lists ¶

Configure the IPv4 access-list

vsr running config# routing
vsr running routing# ipv4-access-list ACCESS-LIST-NAME {permit|deny} A.B.C.D/M [exact-match]
vsr running routing# commit

It is possible to give a description to an access list by typing the command

vsr running routing# ipv4-access-list ACCESS-LIST-NAME remark "comment between inverted commas"

As described, a prefix will match an access-list entry if that prefix is included in that access-list entry. It is possible to override the behaviour with the exact-match keyword so that the access-list will need to match the exact prefix value.

Conversely, it is possible to create IPv6 Access List:

vsr running config# routing
vsr running routing# ipv6-access-list ACCESS-LIST-NAME {permit|deny} X:X::X:X/M [exact-match]
vsr running routing# ipv6-access-list ACCESS-LIST-NAME remark "comment between inverted commas"
vsr running routing# commit

The below prefix-list should be preferred to the access-lists described here.

IP Prefix List ¶

A prefix filter is more powerful than an access-list filter to process the network prefixes.

In comparison to access-list prefix-list have the following advantages:

Can process a range of values
Performance improvement in prefix lookup of large lists
More flexible

Filtering by prefix list involves the following rules :

An empty prefix list permits all prefixes.
An implicit deny is assumed if a given prefix does not match any entries of a prefix list.
When multiple entries of a prefix list match a given prefix, the longest match is chosen.
The router prefix-list lookup begins at the top with sequence number 1, if a match occurs then the router do not go through the rest of the prefix list.

The syntax to define a prefix filter is:

vsr running config# routing
vsr running routing# ipv4-prefix-list PREFIX-LIST-NAME
vsr running ipv4-prefix-list# seq SEQ policy {permit|deny} [address PREFIX/M
                    [prefix-min A | prefix-max B]]
vsr running routing# ipv6-prefix-list PREFIX-LIST-NAME
vsr running ipv6-prefix-list# seq SEQ policy {permit|deny} [address PREFIX/M
                    [prefix-min A | prefix-max B]]

PREFIX-LIST-NAME

unique identifier name of the prefix list context

SEQ

Sequence of the rule named PREFIX-LIST-NAME Range varies from 1 to 4294967295

PREFIX/M

Network prefix and M the length of the mask. The format is an IPv4 address for an IPv4 prefix list, or an IPv6 address for an IPv6 prefix list.

A and B

A and B range goes from 0 to 32 for an IPv4 prefix list, while it goes from 0 to 128 for an IPv6 prefix list. Those integers up to 32 that can be used to form a block of prefixes. A, B and M are such as:

M < A

M < B

A ( B

M < A ( B ( 32

Example with IPv4 prefix list

Let P1/m be a network prefix that matches PREFIX/M. For example PREFIX/M could be 192.168.0.0/16 and P1/m could be 192.168.10.0/24.

Moreover, if A and B are defined, P1/M matches this rule if M is greater or equal than A and if M is less or equal to B (A ( M ( B). For example 192.168.10.0/24 matches the rule 5, however it does not match the rule 10.

vsr running routing# ipv4-prefix-list PREFIX-FILTER-NAME
vsr running ipv4-prefix-list# seq 5 policy permit address 192.168.0.0/16 prefix-min 17 prefix-max 25
vsr running ipv4-prefix-list#

The prefix lists can be used in many cases:

route-map:
         match ip address prefix-list FILTER-NAME
         match ipv6 address prefix-list FILTER-NAME
         match ip next-hop address prefix-list FILTER-NAME

neighbor configuration:
          neighbor A.B.C.D address-family ADDRESSFAMILY
               prefix-list {in|out} prefix-list-name FILTER-NAME

Note

The command ‘match ip/ipv6 address’ can be used with an access-list too. However, you can check that the syntax is not exactly the same: match ip address prefix-list FILTER-NAME vs. match ip address access-list ACCESS-LIST-NAME.

Route-Maps ¶

Route-Maps operate on the match/set mechanism. it applies a set of actions to the incoming entries that matches the set criteria. Incoming entries stand for routing information. For instance, BGP updates.

To create a route-map object, use the following command:

vsr running routing# route-map ROUTEMAP-NAME seq SEQ policy {permit|deny}
vsr running route-map SEQ#

ROUTEMAP-NAME: unique identifier name of the route-map context
SEQ: Sequence of the rule named ROUTEMAP-NAME. Range varies from 1 to 65535

The route-map introduces a sequence number that permits introducing several match/set rules sequentially. If the first sequence does not match the incoming entry, then the next sequence is looked up.

The match and set operations vary from one routing protocol to an other one. BGP gathers a wide variety of match/set combinations. Here below is depicted some basic examples:

To configure a route-map based on a peer criterion, and apply a weight to the routing entry, use the following command:

vsr running routing# route-map ROUTEMAP-NAME seq SEQ policy {permit|deny}
vsr running route-map SEQ# match peer A.B.C.D
vsr running route-map SEQ# set weight (0-4294967295)

Note

Some route-map actions and/or match conditions can be protocol-specific (for instance matching on community-id makes sense only for BGP). If the associated protocol is not configured and activated, the specific items will not be displayed in a show state but will still be visible on a show configuration.

Global Routing options per VRF ¶

Route-map filtering per protocol ¶

Before sending routes to the FIB, you can apply a route-map filter to routes originating from a given protocol in a specific vrf with the following command:

vsr running routing# / vrf VRF routing global {ipv4|ipv6}
vsr running ipv4# protocol PROTOCOL ROUTEMAP

Nexthop Tracking ¶

The ‘resolve-via-default’ command allows the routing services to resolve the reachability of their next hops by using or not any default route in the specified vrf.

vsr running routing# / vrf VRF routing global {ipv4|ipv6}
vsr running ipv4# nexthop-tracking resolve-via-default true

This option is set to false by default.

Routing Administrative Distance ¶

Actually, even if prefixes can be filtered, the origin of the route entry is kept, and a weight is associated to each route entry, according to the origin of the routing protocol. That weight is called the administrative distance. For instance, if the same prefix has 2 entries in both static routing table, and BGP routing table, the prefix with the least administrative distance will be chosen locally and installed in the system. Here it will be the static routing table.

We give here a reminder of the common routing protocols administrative distance:

Routing protocol	Administrative distance
Connected prefixes (routes)	0
Static routes	1
iBGP	200
eBGP	20
OSPF v2 and OSPF v3	110
IS-IS	115
RIP and RIPng	120

Logging ¶

Routing logging options are configurable from the global routing context:

vsr running config# routing logging

All logs are sent to the daemon syslog facility. By default, only messages of severity higher than error are logged. This can be modified by changing the level option:

vsr running logging# level LEVEL

LEVEL: Severity from which messages should be logged.

Here is the list of severities from the most serious to the least:

severity	description
emergency	System is unusable.
alert	Action must be taken immediately.
critical	Critical conditions.
error	Error conditions.
info	Informational messages.
notice	Normal but significant conditions.
warning	Warning conditions.
debug	Debug-level messages.

The verbosity of these logs is configurable per routing protocol. See the routing Root commands command reference guide for details.