Thomson Gateway...This is shown in the diagram below: Equal routes RIP-RIB BGP-RIB OSPF-RIB t route...

Po

wer

Eth

ern

et

WLA

N

Plu

g-i

n

ISD

N

Inte

rnet

DS

L

Thomson GatewayIP Routing Configuration Guide

Thomson GatewayIP Routing Configuration Guide

Copyright

Copyright ©1999-2007 THOMSON. All rights reserved.

Distribution and copying of this document, use and communication of its contents is not permitted without written authorization from THOMSON. The content of this document is furnished for informational use only, may be subject to change without notice, and should not be construed as a commitment by THOMSON. THOMSON assumes no responsibility or liability for any errors or inaccuracies that may appear in this document.

Thomson Telecom BelgiumPrins Boudewijnlaan, 47 B-2650 Edegem Belgium

http://www.thomson-broadband.com

Trademarks

The following trademarks are used in this document:

> DECT is a trademark of ETSI.

> Bluetooth® word mark and logos are owned by the Bluetooth SIG, Inc.

> Ethernet™ is a trademark of Xerox Corporation.

> Wi-Fi® and the Wi-Fi logo are registered trademarks of the Wi-Fi Alliance. "Wi-Fi CERTIFIED", "Wi-Fi ZONE", "Wi-Fi Alli-ance", their respective logos and "Wi-Fi Protected Access" are trademarks of the Wi-Fi Alliance.

> UPnP™ is a certification mark of the UPnP™ Implementers Corporation.

> Microsoft®, MS-DOS®, Windows® and Windows NT® are either registered trademarks or trademarks of Microsoft Corpo-ration in the United States and/or other countries.

> Apple® and Mac OS® are registered trademarks of Apple Computer, Incorporated, registered in the United States and other countries.

> UNIX® is a registered trademark of UNIX System Laboratories, Incorporated.

> Adobe®, the Adobe logo, Acrobat and Acrobat Reader are trademarks or registered trademarks of Adobe Systems, Incor-porated, registered in the United States and/or other countries.

Other brands and product names may be trademarks or registered trademarks of their respective holders.

Document Information

Status: v1.0 (April 2007)Reference: E-DOC-CTC-20060306-0001Short Title: Config Guide: IP Routing R6.2 (and higher)


Contents

About this IP Routing Configuration Guide ............................. 1

1 Concepts and terminology ......................................................... 3

1.1 Routing versus Forwarding ............................................................................. 4

1.2 Scalable Routing: Domains and Types ............................................................ 6

1.3 Route Types .................................................................................................... 7

2 The Thomson Gateway Routing Structure ............................... 9

2.1 Routing Information Base ............................................................................. 10

2.2 Route Selection............................................................................................. 11

2.3 Route Redistribution ..................................................................................... 12

2.4 Martian Packet Filtering ............................................................................... 13

3 Global Configuration and Routing Policies ............................. 15

3.1 Global Router Configuration ......................................................................... 16

3.2 Syslog Configuration .................................................................................... 17

3.3 Routing Policies ............................................................................................ 18

4 Routing Information Protocol (RIP).......................................... 19

4.1 An Introduction to RIP .................................................................................. 20

4.1.1 General Concepts ................................................................................................................................. 21

4.1.2 RIP Version 2......................................................................................................................................... 23

4.1.3 The RIP Model....................................................................................................................................... 25

4.2 Supported Use Cases .................................................................................... 27

4.2.1 Conventional RIP: Standard IP Router ................................................................................................ 28

4.2.2 RIP in High-Speed Internet Access DSL Configuration ..................................................................... 29

4.2.3 RIP and ATM VPNs ............................................................................................................................... 30

4.2.4 RIP and Tunnel Technology (IP VPNs)................................................................................................ 31

4.2.5 RIP and Floating Static Routes ............................................................................................................ 32

4.2.6 RIP and Multi Protocol Label Switching (MPLS) VPNs...................................................................... 33

4.3 RIP Configuration.......................................................................................... 34

E-DOC-CTC-20060306-0001 v1.0i

Contents

5 Border Gateway Protocol (BGP)............................................... 35

5.1 An Introduction to BGP................................................................................. 36

5.1.1 Basic Concepts...................................................................................................................................... 37

5.1.2 The BGP Model..................................................................................................................................... 39

5.1.3 Thomson Gateway Implementation Details....................................................................................... 40

5.2 Supported Use Cases .................................................................................... 41

5.2.1 Simple Interior BGP.............................................................................................................................. 42

5.2.2 Simple Exterior BGP............................................................................................................................. 43

5.2.3 BGP and Layer 2 VPNs ......................................................................................................................... 44

5.2.4 BGP and Multi Protocol Label Switching (MPLS) VPNs.................................................................... 45

5.2.5 BGP with Floating Static ...................................................................................................................... 46

5.2.6 Multi-homing & Traffic Engineering ................................................................................................... 47

5.3 BGP Configuration ........................................................................................ 49

5.3.1 Configuration Procedure...................................................................................................................... 50

5.3.2 Global BGP Configuration ................................................................................................................... 51

5.3.3 Additional Global Settings................................................................................................................... 53

5.4 Peer configuration ........................................................................................ 54

5.4.1 Creating a peer ..................................................................................................................................... 55

5.4.2 Modifying a Peer .................................................................................................................................. 56

5.4.3 Clearing peers....................................................................................................................................... 60

5.5 Policies.......................................................................................................... 61

5.5.1 Route Redistribution ............................................................................................................................ 62

5.5.2 Applying Route Filters.......................................................................................................................... 63

5.5.3 Network Statement .............................................................................................................................. 64

E-DOC-CTC-20060306-0001 v1.0ii

About this IP Routing Configuration Guide


About this GuideThis IP Routing Configuration Guide explains how to configure the Thomson Gateway routing functions. Static routes, the Routing Information Protocol (RIP) and the Border Gateway Protocol (BGP) are the main items discussed. Also how routes from these and other origins are used in the Thomson Gateway routing structure, and how they result in the functional forwarding behaviour will be described.

All examples start from a default Thomson Gateway configuration.

ScopeThis guide focuses on IP routing and its configuration. For more information on IP forwarding and how to configure it, refer to the Thomson Gateway IP Forwarding Configuration Guide.

Used Symbols

Typographical ConventionsFollowing typographical convention is used throughout this manual:

> Sample text indicates a hyperlink to a Web site.

Example: For more information, visit us at www.thomson-broadband.com.

> Sample text indicates an internal cross-reference.

Example: If you want to know more about guide, see “1 Introduction” on page 7”.

> Sample text indicates an important content-related word.

Example: To enter the network, you must authenticate yourself.

> Sample text indicates a GUI element (commands on menus and buttons, dialogue box elements, file names, paths and folders).

Example: On the File menu, click Open to open a file.

> Sample text indicates a CLI command to be input after the CLI prompt.

Example: To obtain a list of all available command groups, type help at the top level.

> Sample text indicates input in the CLI interface.

> Sample text indicates comment explaining output in the CLI interface.

i A note provides additional information about a topic.

! A caution warns you about potential problems or specific precautions that need to be taken.

E-DOC-CTC-20060306-0001 v1.01



Example:

Documentation and software updatesTHOMSON continuously develops new solutions, but is also committed to improving its existing products.

For suggestions regarding this document, please contact [email protected].

For more information on THOMSON's latest technological innovations, documents and software releases, visit us at http://www.thomson-broadband.com.

=> language list

CODE LANGUAGE VERSION FILENAMEen* english 4.2.0.1 <system> Only one language is available

Output

Input

Comments

E-DOC-CTC-20060306-0001 v1.02

mailto:[email protected]?subject=Documentation feedback


Chapter 1Concepts and terminology

1 Concepts and terminology

Scope This document is intended for readers familiar with the Internet Protocol (IP) and the described routing protocols. The scope of this document is to explain how the Thomson Gateway has implemented these protocols, and how it functions in routing environments.

For purposes of clarity, some concepts are explained. For more information on IP forwarding, refer to the Thomson Gateway IP Forwarding Configuration Guide.

In this chapter

Topic Page

1.1 Routing versus Forwarding 4

1.2 Scalable Routing: Domains and Types 6

1.3 Route Types 7

E-DOC-CTC-20060306-0001 v1.03


1.1 Routing versus Forwarding

Forwarding versus RoutingThere is a fundamental difference between Forwarding and Routing.

Forwarding is the actual action of handling (forwarding) packets. An IP-packet arrives, the forwarding function inspects the packet, performs a lookup in the forwarding table, and ‘forwards’ the packet to the next hop.

Routing however, is the process of determining the network topology, and building the forwarding table. This typically relates to routing protocols such as RIP, BGP, and so on, but equally relates to adding static routes, handling auto-generated routes from interface definition etc.

ForwardingThe forwarding process performs a forwarding action per packet. This implies that for every packet to be forwarded, it tries to find the best match between the packet's destination address and the available destinations in the forwarding table. For the best matching destination it retrieves the corresponding router-port and the next-hop information and then sends the packet.

Routing Routing is the process of distributing network reachability information amongst a collection of routers. This is accomplished via routing protocols such as Routing Information Protocol (RIP), Border Gateway Protocol (BGP) or Open Shortest Path First (OSPF). All reachability information is kept in a routing table.

Routing table or Routing Information base (RIB)The routing table or Routing Information Base (RIB) contains a number of entries with routes to certain destinations. Typically, a Routing Table Entry (RTE) contains the destination IP address, the Next Hop IP address and a metric for that route. In some cases, such as for Multi-Protocol Label Switching (MPLS), an RTE may contain information about the next several hops. Each protocol has its own RIB.

The task of a routing table is to hold all reachability information exchanged between routing peers via routing protocols such as RIP, BGP or OSPF.

Forwarding table or Forwarding Information Base (FIB)A forwarding table contains destination network, router-port/next-hop entries. A popular term for an entry is called a route. These are typically sorted from most specific destination to least specific.

MetricsSome routes are better than others. To compare them, each route is given a metric. These metrics can be based on several parameters, depending on the routing protocol used, e.g. hop count for RIP.

RIB versus FIBThe RIB contains a number of entries with routes to certain destinations. Each protocol has its own RIB. The FIB contains only the best route for each destination from all available protocols.

E-DOC-CTC-20060306-0001 v1.04


Metric Handling in the FIBIn a multi-protocol environment, the different protocols, such as RIP, BGP and OSPF, each have a separate RIB. Best route selection for a given destination is handled by that protocol and the related RIB logic.

All best routes are then entered into the Master RIB. Since each protocol may provide its own best route, the Master RIB may contain several “routes for a given destination. The Master RIB logic will then select the best route among them (using longest prefix matching and lowest metric) and transfer this route to the FIB, which is used for routing packets.

This is shown in the diagram below:

Equal routes

RIP-RIB BGP-RIB OSPF-RIB

t route selection based on RIP metric(Hop-count)

Best route selection based on BGP Attributes e.g.shortest AS-Path

Best route selection based on OSPFshortest path

CONNECTED

STATIC

RIP

EBGP

IBGP

OSPF

ICMP

0

1

100

20

170

200

240

Route Type Distance

Best route selection based on LowestAdministrative Distanceon OSPF shortest

Per packet best route selection based on LongestPrefix Matching and Lowest Metric

CONNECTED

STATIC

RIP

EBGP

IBGP

OSPF

ICMP

0

1

1

1

1

1

1

Route Type FIB Metric

MASTERRIB

FIB

Towards outbound interface

The FIB route metrics

0 per default, non-configurable1 per default, configurable via CLI1 per default non-configurable1 per default.In case of multiple identical routes in the DHCPoption, metric increases w.r.t. the position of the routerelative to the others. First route gets metric 1.

Connected routesStatic routes

Dynamic routesDHCP routes

E-DOC-CTC-20060306-0001 v1.05


1.2 Scalable Routing: Domains and Types

Routing DomainsNetworks and routers are typically organised in routing domains for the purpose of routing scalability. All hosts under control of a single administrative authority, form a domain. A Routing Domain is often referred to as an Autonomous System (AS). Every public AS is identified by a globally unique number, an autonomous System Number (ASN). For non-global Autonomous Systems, a range of private ASNs is available.

Routing TypesThe Internet as a whole is a collection of interconnected hosts.In order to support each domain’s autonomy, routing, and consequently routing protocols, is divided in two types:

> Intra-domain routing, which supports the transmission of routing information between hosts within the same domain. Well known protocols in this environment are RIP and OSPF.

> Inter-domain routing, which provides support to exchange routing information throughout multiple domains. The hosts that forward packets across domain borders are called border routers. A well known protocol in this environment is BGP.

E-DOC-CTC-20060306-0001 v1.06


1.3 Route Types

basic route typesThe Thomson Gateway routing process deals with routes from various types, coming from several origins. There are three basic route types:

> Connected routes

> Static routes

> Dynamic routes

Connected RoutesConnected routes are the result of configuring IP addresses on IP interfaces. These routes are the most important amongst all types, as they represent the directly connected hosts and/or networks.

Static RoutesStatic routes are the result of administrative configuration trough any kind of configuration interface (as CLI, Web,...).

Depending on the parameters defined during the configuration, static routes can be further divided into following categories:

> Standard routes,

also referred to as ‘next-hop-routes’ or ‘gateway routes’, actually are the routes typically used. They are defined by (DestinationPrefix, GatewayIP), where GatewayIP must be directly reachable via any of the connected networks.

> Interface routes

are routes which to not define an IP address as a next hop, but just an interface on which to send out the packet in transit. Typically this kind of route is used on point-to-point interfaces where only one device exist on each connected interface. Interface routes are typically defined by (DestinationPrefix, InterfaceName).

> Extended routes

are an extension on standard routes to overrule the basic concept that the next-hop has to be in one of the subnets the router is a member of itself. With an extended route, gateway IP addresses can be defined that are out of the subnet of an interface, but of which the administrator knows it is directly reachable anyhow. An extended route is defined by (DestinationPrefix, GatewayIP, InterfaceName)

> Label routes

Essentially, label routes are static routes with an extra field called a ‘label’. Label routes are a Thomson Gateway proprietary way to configure policy based IP forwarding. A label contains a set of traffic selectors, which relate to parameters available in the TCP/IP protocol headers. When a packet enters the Thomson Gateway, the labelling process tags the packet with a matching label. When the packet is to be forwarded, route lookup is performed on label first, and subsequently on longest prefix matching.

i Redistribution of static routes via routing protocols has its limitations. For interface and Extended routes, their specific configuration is translated to a standard route. Labelled routes however, are completely out of the scope for redistribution, as their definition cannot be translated to a generic standard route.

E-DOC-CTC-20060306-0001 v1.07


Dynamic RoutesIn the context of this document, dynamic routes originate from routing protocols. Also routes that are generated locally as a result from route computations, are classified as a dynamic route.

E-DOC-CTC-20060306-0001 v1.08

Chapter 2The Thomson Gateway Routing Structure

2 The Thomson Gateway Routing Structure

In This Section

Topic Page

2.1 Routing Information Base 10

2.2 Route Selection 11

2.3 Route Redistribution 12

2.4 Martian Packet Filtering 13

E-DOC-CTC-20060306-0001 v1.09


2.1 Routing Information Base

Flow of RoutesEach routing process, related to a routing protocol, in the Thomson Gateway has its own RIB. This protocol RIB holds all routes received via that particular protocol. Each routing process is responsible to delegate its best routing entries towards the Master-RIB. Each routing process has its own logic on filtering out the routes that are to be injected in the Master-RIB.

The Master-RIB holds all best routes from every single route source. As such, there is no guarantee that all routes are unique. For example, there might be a default route that originates via BGP, but also one learned via RIP. The Master routing process selects the best routes to every unique destination, and puts all of these ‘single best routes’ in the Forwarding Information Base (FIB).

The figure below provides a simplified view on how routes flow between the different components of the routing implementation.

For additional information, refer to “ Metric Handling in the FIB” on page 5.

Special flow of Static and Connected routesFor historical reasons, the Thomson Gateway routing process processes static and connected routes in a special way. In a general model, these routes would be injected in the Master-RIB, pass the filtering mechanisms, and eventually end-up in the FIB if considered best routes.

In the Thomson Gateway routing structure however, static and connected routes are directly injected in the FIB, and are subsequently propagated towards the Master-RIB. From there on they are handled equally, and could be announced to the world via any routing protocol (depending on the set redistribution configuration).

Table Dimensioning and Overflow BehaviourThe size of the FIB has been restricted towards a value that offers a good balance between practical needs and limiting route lookup-times (a larger routing table means a longer time to find the best route).

Currently the maximum amount of records that can exist in the FIB is set to 256.

When the Master-RIB holds more ‘single best routes’ that should go into the FIB, only the first 256 will succeed. All remaining entries will end-up in a FIFO-queue and will be injected in the FIB when space becomes available.

Routing Information Base

RIP Process

BGP Process

OSPF Process

Forwarding Information Base Static & Connected Routes

E-DOC-CTC-20060306-0001 v1.010


2.2 Route Selection

Selection ProcessThe Master-RIB maintains all routes and relies on administrative policies to select the ‘best’ routes that will be installed in the FIB.

If there is only one route to a given destination, the selection policy is quite simple: install the route into the FIB, irrespective its ‘quality’, as it is better to have a route to a destination than to have no route.

If multiple routes exist to a given destination, policy rules must make sure the best route is installed in the FIB.

Local PreferenceTo discriminate between different routes to the same destination, each route holds a certain ‘preference’. This value is set for each route that exists in the M-RIB.

By default this preference is related to the origin of the route. Following table gives an overview of the default values each route gets assigned:

Some routing protocols offer the possibility to force some attributes of routes, typically referred to as ‘traffic engineering’. By configuration, values as the default Preference can be set to a specified value. An example of configuration option could be found in “ Inbound Traffic Engineering” on page 57

Floating StaticA typical principle of combining routes originating from routing protocols with routes that are manually configured, is called “floating static”.

In this configuration, the routes that originate from routing protocols are the primary routes. As a backup, a (default) route with a high metric is configured towards a backup-link. Like this, the static route will never be used (it is floating), unless all dynamic routing entries disappear.

Origin Value

Connected Routes 0

Static Routes 5

OSPF Internal 10

RIP Routes 100

Aggregates 130

OSPF NSSA 150

OSPF ESA 150

BGP 170

E-DOC-CTC-20060306-0001 v1.011


2.3 Route Redistribution

ConceptThe configuration of the route redistribution settings is set per routing protocol. All routes that enter the protocol-RIB (BGP-RIB, RIP-RIB,...) are always injected in the Master-RIB (if they pass all policies and the tie-braking logic).

It is necessary to configure, for each specific protocol, which routes should be distributed via that particular protocol. This is a policy setting on the protocol level (e.g.:router BGP policy), set by a ‘redistribute’ command.

ExampleIt is possible to configure that all Static, RIP and OSPF routes are ‘redistributed’ via BGP (in the BGP policy command group). This is done with the redistribute command in the BGP policy command group:

This command specifies which routes to export from the M-RIB to the BGP database. Thus, the command:

will redistribute all OSPF routes via BGP, i.e. export these routes from the M-RIB to the BGP database.

router bgp policy redistribute proto = <{aggregate | connected | ospf | rip | static}>

router bgp policy redistribute proto = ospf

E-DOC-CTC-20060306-0001 v1.012


2.4 Martian Packet Filtering

Martian PacketsIn a computer network, packets with source addresses not routable by some computer on a network segment are referred to as Martians or "Martian Packets", on the grounds that they are of no evident "terrestrial" (i.e. normal) source. Martian packets can arise from network equipment malfunction, misconfiguration of a host, or simple coexistence of two logical networks on a single physical layer. For instance, if the IP networks 192.168.34.0/24 and 10.2.3.0/24 operate on the same Ethernet segment, packets from 10.2.3.4 are Martians to the computer at 192.168.34.9, and vice versa.

Martian IP AddressesRFC1122 and RFC1812 define a number of Martian addresses. The table below provides an overview:

Martian Packet FilteringThe Thomson Gateway contains a route filtering mechanism that filters out these Martians.

RFC Notation From (dotted decimal) To (dotted decimal) Comments

{0,0} 0.0.0.0 NA Default Address

{0,h o stID} NA NA Shortest netmask= /8Longest netmask= /30

{netID,0} NA NA Shortest netmask= /8Longest netmask= /30

{netID,-1} NA NA Ditected broadcast

{127, Any} 127.0.0.1 127.255.255.254 Loopback Net

{224...239, Any} 224.0.0.0 239.255.255.254 Multicast

{240.0.0.0 ... 255.255.255.254}

240.0.0.0 255.255.255.254 Experimental

{-1,-1} 255.255.255.255 NA Limited Broadcast

E-DOC-CTC-20060306-0001 v1.013


E-DOC-CTC-20060306-0001 v1.014

Chapter 3Global Configuration and Routing Policies

3 Global Configuration and Routing Policies

In this section

Topic Page

3.1 Global Router Configuration 16

3.2 Syslog Configuration 17

3.3 Routing Policies 18

E-DOC-CTC-20060306-0001 v1.015


3.1 Global Router Configuration

About Global ParametersGlobal parameters are parameters that impact all available routing protocols.

Autonomous System Number (ASN)An ‘Autonomous System’ is an IP network controlled as a single entity, with a clearly defined external routing policy. External routing protocols, such as BGP, are used to exchange routing information between these Autonomous Systems.

When peering with a single Service Provider, you may need to use a private ASN offered by that Service Provider. Your network will effectively become part of your providers network.

In case you peer with multiple Service Providers, you may need to obtain your own ASN and IP address space.

Example:

Execute following CLI command to set the AS-number to 65000:

To view the configured ASN, run the following CLI command:

Router IDThis parameter forces the value for the BGP and OSPF Router Identifier.

Example:

Execute the following CLI command to set the router-ID to 25.0.0.100:

To view the configured router ID, run the following CLI command:

:router config as=65000

[router]=>config:router config as=65000 routerid=10.0.0.138 syslog_eme...

:router config routerid=25.0.0.100


E-DOC-CTC-20060306-0001 v1.016


3.2 Syslog Configuration

SyslogThe Thomson Gateway syslog automatically logs events on the gateway. The log can be accessed using the GUI (Speedtouch > Event logs) or via CLI. It can be configured via CLI only. For more information, refer to the CLI Guide.

ConfigurationOn the global router configuration, you can configured what type of syslog messages originating form the routing process should be sent out.

Example:

Execute following CLI command to activate the generation of routing syslog messages from the ‘debug’ level:

This configuration command exists for all eight levels of syslog messages: emergency, alert, critical, error, warning, notice, info and debug.

:router config syslog_debug = enabled

E-DOC-CTC-20060306-0001 v1.017


3.3 Routing Policies

About routing PoliciesRouting policies can be used when configuring communication options with other routing peers. They can be used to perform route filtering in any routing protocol. This part of the configuration of routing policies is also often referred to as configuring Access Lists.

ProcedureProceed as follows to create and configure an Routing Policy:

1 Create an Access List

2 Add rules to the Access List

3 Bind the Access List has to a specific peer configuration.

Creating an Access ListExecute following CLI command to create a new Access List named MyAccLst1:

The actual definition of the Access List happens by adding rules to it.

Adding a rule to an Access ListA rule is a definition of a network prefix. You can define for each rule if a prefix is to be accepted or rejected.A rule consists of a definition of a network prefix, and some additional options. The configurable parameters in a rule definition are:

> Network Prefix (addr & netmask) : the network identifiers that routes will be compared against.

> Sequence number (seqnbr) : to specify the place (or order) of the rule in the Access List. A first hit will stop the processing of the Access List.

> Hit Action (action): to specify if a route that matches this rule would be permitted or denied.

> Subnet/Supernet matching (ge & le) : to make subnets (or supernets) of the given prefix also hit the rule. With the ‘ge’ parameter (Greater or Equal), it can be configured that also subnets (up to a certain mask value) of the given network prefix should match this rule.

Only an exact match on this prefix definition will result in a hit! This means that when for example prefix 20.0.0.0/8 is set to be denied, a route towards 20.20.20.0/24 will be accepted. To make sure none of the 20.0.0.0/8 subnets are accepted, configure the ‘Subnet/Supernet matching’.

[router policy accesslist]=>add name MyAccLst1

E-DOC-CTC-20060306-0001 v1.018

Chapter 4Routing Information Protocol (RIP)

4 Routing Information Protocol (RIP)

IntroductionRIP is an implementation of a distance-vector, or Bellman-Ford, algorithm. Standardized in 1988, it has since evolved into RIPv2 to include extra features such as support for Classless InterDomain Routing and authentication.

In this ChapterThis chapter covers the following topics:

Topic Page

4.1 An Introduction to RIP 20

4.2 Supported Use Cases 27

4.3 RIP Configuration 34

E-DOC-CTC-20060306-0001 v1.019


4.1 An Introduction to RIP

In this SectionA full description of RIP is beyond the scope of this document. This section covers the following topics:

Topic Page

4.1.1 General Concepts 21

4.1.2 RIP Version 2 23

4.1.3 The RIP Model 25

E-DOC-CTC-20060306-0001 v1.020


4.1.1 General Concepts

Router Types in RIPRIP classifies routers as active and passive (silent):

> Active routers advertise their routes (reachability information) to others;

A router running RIP in active mode sends updates at set intervals. Each update contains paired values, where each pair consists of an IP network address and an integer distance to that network.

> passive routers listen and update their routes based on advertisements, but do not advertise. Typically, routers run RIP in active mode, while hosts use passive mode.

RIP MetricsRIP uses a hop count metric to measure the distance to a destination. In the RIP metric, a router advertises directly connected networks at a metric of 1 by default. Networks that are reachable through one other gateway are 2 hops, etc. Thus, the number of hops or hop count along a path from a given source to a given destination refers to the number of gateways that a datagram would encounter along that path.

Using hop counts to calculate shortest paths does not always produce optimal results. For example, a path with a hop count 3 that crosses three Ethernets may be substantially faster than a path with a hop count 2 that crosses two slow-speed serial lines. To compensate for differences in technology, many routers advertise artificially high hop counts for slow links.

The RIP protocol suffers from slow convergence. To keep convergence times within reasonable limits, the value of the metric is limited to 15. A metric of 16 is called Infinity. Route metric validation during protocol operation is done by verifying that the value of the metric is below 16.

RIP Updates & Response PacketsRIP dynamically builds on information received through RIP updates. When started up, RIP issues a request for routing information and then listens for responses to the request. If a system configured to supply RIP hears the request, it responds with a response packet based on information in its routing database. The response packet contains destination network addresses and the routing metric for each destination. When a RIP response packet is received, the routing daemon takes the information and rebuilds the routing database, adding new routes and “better” (lower metric) routes to destinations already listed in the database.

RIP also deletes routes from the database if the next router to that destination reports that the route contains more than 15 hops, or if the route is deleted. All routes through a gateway are deleted if no updates are received from that gateway for a specified time period.

In general, routing updates are issued every 30 seconds. In many implementations, if a gateway is not heard from for 180 seconds, all routes from that gateway are deleted from the routing database. This 180- second interval also applies to deletion of specific routes.

E-DOC-CTC-20060306-0001 v1.021


Forwarding Information Base (FIB) route typesNot all routes are equal, so routes are tagged with various flags allowing network administrators to assess network situations. One of these flags is the route type, which is assigned based on the origin of the route, or its perceived stability. Some examples are:

> Connected routes,

> Static routes,

> Dynamic routes,

> Link local routes,

> Multicast routes,

> Semi-dynamic routes,

> Interface routes.

Routing Table Entry (RTE)In RIP, an Routing Table Entry or RTE contains a single route. Up to 25 RTEs can be contained in a RIP Protocol Data Unit (PDU). An RTE contains:

> An IP prefix,

> IP address of a Gateway (optional), and

> A metric.

Some special RTEs exist:

> An RTE containing an Address Family Identifier od 0x0000 and a Metric equal to infinity must be interpreted as a request to send the entire routing table.

> An RTE containing an Address Family Identifier od 0xFFFF must be interpreted as authentication information.

RIP Message TypesThere are two types of RIP messages:

> RIP Request

If a RIP implementation needs information from its neighbours, it issues a RIP request.

> RIP Response

A RIP implementation announces reachability information to its neighbours via RIP responses. There are two types:

solicited: when it is the consequence of a RIP request, or

unsolicited: when a response is transmitted without a previous request.

An unsolicited RIP Response containing one or more RTEs is called a RIP Update. In general, the RIP daemon issues a RIP update every 30 seconds.

E-DOC-CTC-20060306-0001 v1.022


4.1.2 RIP Version 2

DescriptionRIP version 2 (more commonly known as RIP II) adds additional capabilities to RIP. Some of these capabilities are compatible with RIP I and some are not. To avoid supplying information to RIP I routes that could be misinterpreted, RIP II can use only non compatible features when its packets are multicast. On interfaces that are not capable of IP multicast, RIP-I-compatible packets are used that do not contain potentially confusing information.

Some of the most notable RIP II enhancements are:

> Next hop

> Network mask

> Authentication

> Route tag field

Next hopThe 4-byte Next Hop field contains the forwarding IP address (also known as the gateway address) for the network ID in the IP Address field. If the next hop is set to 0.0.0.0, the forwarding IP address (the next hop) for the route is assumed to be the source IP address of the route announcement.

The Next Hop field is used to prevent non-optimal routing situations. For example, if a router announces a host route for a host that resides on the same network as the router interface advertising the route and the Next Hop field is not used, the forwarding IP address for the host route is the IP address of the router's interface, not the IP address of the host. Other routers that receive the announcement on that network forward packets destined for the host's IP address to the announcing router's IP address rather than to the host. This creates a non-optimal routing situation.

Using the Next Hop field, the router announces the host route with the host's IP address in the Next Hop field. Other routers receiving the announcement on that network forward packets destined for the host's IP address to the host's IP address rather than forwarding them to the announcing router.

Because the Next Hop field becomes the Gateway Address field in the IP routing table, the IP address in the Next Hop field should be directly reachable using a router interface.

Network maskRIP I assumes that all subnetworks of a given network are classful (Class A,B,C). RIP I uses this assumption to calculate the network masks for all routes received. This assumption prevents subnets with classless netmasks from being included in RIP packets. RIP II adds the ability to specify the network mask with each network in a packet. Because RIP I routers will ignore the network mask in RIP II packets, their calculation of the network mask will quite possibly be wrong. For this reason, RIP-I-compatible RIP II packets must not contain networks that would be misinterpreted. These networks must be provided only in native RIP II packets that are multicast.

RIP I derives the network mask of received networks and hosts from the network mask of the interface via which the packet was received. If a received network or host is on the same natural network as the interface over which it was received, and that network is subnetted (the specified mask is more or less specific than the natural netmask), the interface’s subnet mask is applied to the destination. If bits outside the mask are set, it is assumed to be a host; otherwise, it is assumed to be a subnet. On point-to-point interfaces, the netmask is applied to the remote address. The netmask on these interfaces is ignored if it matches the natural network of the remote address, or is all ones. Unlike previous releases, the zero subnet (a subnetwork that matches the natural network of the interface, but has a more specific, or longer, network mask) is advertised. If this is not desirable, a route filter may be used to reject it.

E-DOC-CTC-20060306-0001 v1.023


AuthenticationRIP II packets may contain one of two types of authentication strings that may be used to verify the validity of the supplied routing data. Authentication may be used in RIP-I compatible RIP II packets, but be aware that RIP I routers will ignore these packets (unless ignore-must-be-zero is configured off). The first method is a simple password in which an authentication key of up to 16 characters is included in the packet. If this key does not match what is expected, the packet will be discarded. This method provides very little security because it is possible to learn the authentication key by monitoring RIP packets.

The second method uses the MD5 algorithm to create a crypto-checksum of a RIP packet and an authentication key of up to 16 characters. The transmitted packet does not contain the authentication key itself; instead, it contains a crypto-checksum, called the “digest” The receiving router will perform a calculation using the correct authentication key and discard the packet if the digest does not match. In addition, a sequence number is maintained to prevent the replay of older packets. This method provides a much stronger assurance that routing data originated from a router with a valid authentication key.

Two authentication methods can be specified per interface. Packets are always sent using the primary method, but received packets are checked with both the primary and secondary methods before being discarded. In addition, a separate authentication key is used for non-router queries.

Route Tag FieldThe Route Tag field is used as a method of marking specific routes for administrative purposes. Its original use as defined by RFC 1723 was to distinguish routes that were RIP-based routes (internal to the RIP environment) from non-RIP routes (external to the RIP environment). The Route Tag is configurable on routers that can support multiple routing protocols.

E-DOC-CTC-20060306-0001 v1.024


4.1.3 The RIP Model

ModelThe general RIP model is shown below:

Functional BlocksThe model above has the following functional blocks:

RIPRX

RIP Requests

RIP Responses

Inbound RIP PDUs

Inbound RTEProcessing

OutboundRTE

Processing

RIP Responses

RIPTX

RIP Requests

RIP Responses

RIP&

RIBManagement

Destination Prefix Next-Hop Life-TimeMetric Change Flag

RIP Requests

RIB Route injection

Routing Information Base (RIB)

Route Summarization

Split Horizon & | Poisoned Reverse processing

Martian RTE Filtering

RTE Processing (Route Calculation)

Interface Prefix Interface IP Cost

Router Interface Table

Solicited RIP Responses

Triggered RIP Responses*

RIP Request (Start-Up only)

Outbound RIP PDUs

1

2

3

4

6

7

5

CLICMDs

WEBAPI

SNMPCMDs

RIP Message construction

RIP Message addressing

Optionally RIP Message authentication (v2 only)

RIP TX Version handling

Unsolicited RIP Responses

RIP Requests

RIP Responses

Inbound RIP Request handling

Unsolicited RIP Response handling

Triggered RIP Response handling

Solicited RIP Response handling

Outbound RIP Request handling (@ Start-up only)

RIP Route aging

RIP Deletion

RIP State Machine

Management Plane interaction

RIP Role handling

Inbound IP/UDP/RIP PDU validation

IP Layer

Destination IP validation

Source IP validation (including On-Link verification):

Inbound interface verification

UDP Layer validation (UDP 520/520 check)

RIP Layer

Version check

Authentication verification (v2 only)

RIP Command Type check

Overall Next-Hop derivation

Overall NetMask derivation (v1 only)

MBZ check (v1 only)

* Not to be confused with Triggered RIP per RFC2091

The IP/RIP packet itself

Inbound IP/RIP PDU containing:

The inbound interface ID tag on which the packet was received

Towards Master RIB

8

Block Name

1 RIP RX Section

2 Inbound Router Table Entry (RTE) processing

3 RIP State machine, RIB (Router Information Base) management

4 RIP Routing Information

5 IP Interfaces Table

6 Outbound RTE processing (e.g. SPH & PR handling, Route Summarization)

7 RIP TX section

E-DOC-CTC-20060306-0001 v1.025


The RIP Routing ProcessThe RIP routing process is as follows:

1 At startup, the RIP implementation issues a RIP request to all of its neighbours for the contents of their RIBs.

2 The RIP neighbours respond and the routers RIB gets populated.

3 Subsequently, the RIP router issues a RIP Update every 30 seconds containing its complete RIB.

4 For each received update after startup, the RIB management system analyses all RTEs and retains only the best route per destination, i.e. the route with the best metric.

5 After some time, the system converges to a stable state in which RIBs only contain the best routes towards destinations.

6 To cope with changing network topologies, routes are removed from the RIB via ageing.

E-DOC-CTC-20060306-0001 v1.026


4.2 Supported Use Cases

About the use casesAlthough the Thomson Gateway RIP implementation can handle all possible network use cases, it was tested for a specific set of use cases. These use case were selected because they use the Thomson Gateway in a special way.

These use cases are an illustration of the following network dynamics:

> A DSL node goes up and down: through RIP, the remote nodes are informed about this and can drop packets destined for this node earlier in the network

> Local topology changes: since the network behind the Thomson Gateway is often a simple stub network, this is not very likely to happen.

> Remote topology changes: a DSL node can use RIP to learn about changes in remote topology.

> Multi-link topology: a link may fail, but connectivity remains assured because it is a toplogy change that is handled by RIP.

In this sectionThis section covers the following Use Cases:

Use Case Page

4.2.1 Conventional RIP: Standard IP Router 28

4.2.2 RIP in High-Speed Internet Access DSL Configuration 29

4.2.3 RIP and ATM VPNs 30

4.2.4 RIP and Tunnel Technology (IP VPNs) 31

4.2.5 RIP and Floating Static Routes 32

4.2.6 RIP and Multi Protocol Label Switching (MPLS) VPNs 33

E-DOC-CTC-20060306-0001 v1.027


4.2.1 Conventional RIP: Standard IP Router

DescriptionIn a conventional RIP case, using a standard router, all IP addresses are static, even on PPP links. The router is a transparent device, and uses neither a Firewall, nor address or port translation. RIP operates on different Layer3/Layer 2 combinations. In this case, RIP is carried over all possible link layer technologies, proving RIP‘s Layer 2 independency.

DiagramThe diagram below illustrates this use case:

ST

RIP Updates

NetA

NetB

RIP Updates

ATM PVC1

ATM PVC2

R

R

NetC

NetD

RIP Updates

RIP Updates

RIP Updates

E-DOC-CTC-20060306-0001 v1.028


4.2.2 RIP in High-Speed Internet Access DSL Configuration

DescriptionThis use case differs from the previous one on the following points:

> The interface on which RIP is enabled operates mostly with a dynamic IP address e.g. PPP-IPCP or DHCP.

> In most cases, the configuration will operate with NAPT and a stateful firewall

> RIP is operated in Passive Mode, meaning that it receives and processes RIP updates, but it is never a source of RIP updates itself.


ST

NA(P)T Enabled on thisIP interface

RIP Updates

RIP Enabled in Passive Mode

NetA

NetB

RIP Updates

E-DOC-CTC-20060306-0001 v1.029


4.2.3 RIP and ATM VPNs

DescriptionThis use case is close to the conventional one of “4.2.1 Conventional RIP: Standard IP Router”. The latter, however, is merely a hypothetical use case, with the emphasis on carrying RIP over all possible link layer technologies. In this case, however, ATM VPNs typically rely on a single type of ATM-Link Layer technology (e.g. EthoA and IPoA). RIP handles all possible looping situations resulting from the full mesh ATM.


ST

RIP Updates

NetAATM PVC1

ATM PVC2

R

R

NetB

NetC

RIP UpdatesATM PVC3

E-DOC-CTC-20060306-0001 v1.030


4.2.4 RIP and Tunnel Technology (IP VPNs)

DescriptionSince RIP operates hop-by-hop, RIP peers must be on-link with each other, i.e. IP packets can be freely exchanged between the peers without router intervention. In some situations, it is not possible to fulfil this requirement. This can be solved using Layer 3 tunnelling. In essence, a Layer 3 tunnel is the Layer 3 equivalent of a Layer 2 point-to-point link, and is treated as such by RIP. The Thomson Gateway RIP implementation operates with IP in IP tunnels, GRE tunnels and GRE tunnels protected with IPSec


STR

RIP Updates

NetA

R

R

IP Network

R

R

R

E-DOC-CTC-20060306-0001 v1.031


4.2.5 RIP and Floating Static Routes

DescriptionIn the event that multiple routes to the same destination exist in the Master RIB, the routes administrative distances are used to select routes: the route with the lowest administrative distance is preferred.

In general, compared to dynamic routes, static routes have a lower administrative distance and are therefore preferred over dynamic routes.

In redundancy use-cases, this behaviour may be unwanted. To remedy this, the administrative distance of specific static routes can be increased to such an extent so that the dynamic route is preferred over the static one. If the dynamic route fails, the static route pops up from the bottom of the routing table and provides an alternative path for packet forwarding. These routes are called floating static routes and are used in the Thomson Gateway RIP implementation for RIP-ISDN Backup.

This use case uses one dynamic and one static route, both referring to the same destination. The FIB metric for static routes is set higher than the FIB metric for dynamic routes. The primary sorting key in the FIB is Destination prefix and subsequently the FIB metric.

Here, RIP is used as a link integrity mechanism: traffic is forwarded over the main link, as long as regular RIP updates are received from this link. As soon as 3 consecutive RIP updates are missing, the RIP route is removed from the FIB and traffic will be sent via an identical static route with a lower FIB metric.

Via the “Dial on Demand” setting, the local PPP daemon is configured to establish a session with its link peer as soon as packets are being sent via the backup route. Packets are sent via the backup route until the main route (with the lower FIB metric) is injected again. The PPP link goes down if user traffic is absent for a configureable amount of time.


STR

RIP Updates

NA(P)T

Internet BRASDSL Line: main

NBRASISDN Line: backup

E-DOC-CTC-20060306-0001 v1.032


4.2.6 RIP and Multi Protocol Label Switching (MPLS) VPNs

DescriptionVPNs based on MPLS technology are gaining importance compared to VPNs based on ATM or layer 2 leased lines. The network elements involved are:

> Customer Edge routers (CE)

> Provider Edge routers (PE)

> Provider routers (P)

MPLS based VPNs rely on internal BGP(iBGP) to distribute VPN reachability information and MPLS labels within the MPLS network. iBGP must be configured with the VPN prefixes (Redistribute Static). It is also possible to learn the information from the CE router via RIP.


STR/ CE1

PE

PE

PE

CE4

CE2

CE5

CE3

RIP Updates

MPLSNetwork

P

P

P

E-DOC-CTC-20060306-0001 v1.033


4.3 RIP Configuration

IntroductionRIP can be configured using CLI. This section provides an overview of the commands needed to do this. For more information on these commands, refer to the CLI command reference guide.

OverviewBelow is an overview of RIP related CLI commands:

Command Description

router rip config Activate/deactivate and/or configure the RIP daemon

router rip ifconfig Configure an interface the RIP daemon will run on.

router rip ifprimauthconfig Specify the used primary interface authentication.

router rip ifsecauthconfig Specify the used secondary interface authentication.

router rip list Show the RIP configuration settings.

router rip rtlist Show the RIP present in the RIB.

router rip flush Flush the complete RIP configuration.

router rip debug traceconfig Configure the RIP daemon tracepoint.

router rip neighbor addunicast

Configure a RIP unicast neighbor.

router rip neighbor deleteunicast

Delete a RIP unicast neighbor.

router rip neighbor addtrusted

Configure a RIP trusted neighbor.

router rip neighbor deletetrusted

Delete a RIP trusted neighbor.

router rip neighbor list Display the status of the neighbouring routers.

router rip policy distlistin Configure a RIP policy to apply to incoming updates.

router rip policy nodistlistin Delete the specified RIP import policy.

router rip policy distlistout Configure a RIP export policy.

router rip policy nodistlistout Delete the specified RIP export policy.

router rip policy redistribute Specify which routes to export from RIB to RIP database.

router rip policy noredistribute

Specify which routes not to export from RIB to RIP database

router rip policy list Display the import/export policy configuration.

E-DOC-CTC-20060306-0001 v1.034

Chapter 5Border Gateway Protocol (BGP)

5 Border Gateway Protocol (BGP)

About BGPThe Border Gateway Protocol is the Internet‘s core routing protocol. Although its configuration is far more complex than simpler protocols such as RIP, it offers a number of advantages over them.

In this ChapterThis chapter covers the following topics:

Topic Page

5.1 An Introduction to BGP 36

5.2 Supported Use Cases 41

5.3 BGP Configuration 49

5.4 Peer configuration 54

5.5 Policies 61

E-DOC-CTC-20060306-0001 v1.035


5.1 An Introduction to BGP

About BGPThe Border Gateway Protocol is the core routing protocol of the Internet. The BGP routing protocol inside the CPE has some noticeable advantages compared to other (more simple) routing protocols like RIP:

> It provides a greater flexibility and scalability

> It offers a more stable ISDN backup behaviour; It offers a better interoperability with large scale MPLS VPN networks, as these networks typically use BGP for route distribution. When the Customer equipment uses the same routing protocol as the core MPLS network, the full capabilities of the protocol can be exploited as no information will be lost during protocol translation.

> It allows to support customers with multiple exit links. To improve availability or capacity, more than one xDSL connection from the customer to the Internet could be used. To keep the Internet aware via which ISPs his network is reachable, he will have to participate in the Internet’s intra-domain routing, being BGP.

> It allows load balancing and redundancy.

In this sectionThis section covers the following topics:

Topic Page

5.1.1 Basic Concepts 37

5.1.2 The BGP Model 39

5.1.3 Thomson Gateway Implementation Details 40

5.3.1 Configuration Procedure 50

E-DOC-CTC-20060306-0001 v1.036


5.1.1 Basic Concepts

About BGPBGP is widely known as the core routing protocol of the Internet. It is based on exchanging network reachability information with other networks (other Autonomous Systems). BGP is not based on metrics, but uses policies and rules to make routing decisions. Essentially, BGP is a routing process that exchanges routes with a corresponding process in another router.

Typical BGP EnvironmentBelow is a diagram of a typical BGP network environment:

This diagram show the following elements:

> Autonomous Systems (AS) or routing domains

> Routers (R)

> Border Routers (BR) located on the edge of an AS. This is the natural placement for DSL routers such as the Thomson Gateway.

BR BR

BR

BR

BR BR

BR

BR

BR BR

BR

R R R

R

R

R

R

BR

RR

EBGP EBGP

Multihop-EBGP

EBGP

IBGP

IBGP

IBGP

Full IBGP mesh

Directly connectedBorder routers

IGP(“Static”, RIP, OSPF ..)

Autonomous System (AS)

AS1

AS2AS3

AS4

AS5

AS6

AS7

Legend:

AS

BR

R

EBGP

IBGP

IGP

Autonomous System

Border Router

Router (non-BGP router)

Exterior Border Gateway Protocol

Interior Border Gateway Protocol BGP

Interior Gateway Protocol (RIP, OSPF, “Static”, ...

E-DOC-CTC-20060306-0001 v1.037


Internal versus External BGPBGP can be used for both inter- as intra domain routing:

> BGP between peers in the same AS is called Internal BGP (iBGP)

> BGP between peers in different ASs is called External BGP (eBGP)

Routing Loop Detection in eBGPAlthough iBGP and eBGP rely on the same protocol, slightly different rules apply during their operation. A clear example of this difference is the “routing loop detection mechanism” in eBGP. When a router receives routing records via eBGP, it scans all messages for its own AS-number (ASN). If it detects its own ASN in a route record, the record will be dropped (as this means this route record was originally forwarded by that router).

Since in iBGP the routing information comes from within the same AS, this detection mechanism makes no sense. To make sure all routing information is distributed between internal peers, the protocol demands full-meshed peer connections. Routing information from an internal peer is not redistributed to the other internal peers.

Connectivity between internal BGP peersInternal BGP peers are not necessarily on-link with each other. For BGP sessions to get established, IP connectivity between the internal peers must be assured either via static routes or via an Interior Gateway Protocol (e.g. RIP - refer to “4.2.6 RIP and Multi Protocol Label Switching (MPLS) VPNs” on page 33).

Connectivity between external BGP peersBecause it is the “natural” form of BGP, there are less restrictions on eBGP. In most cases, BGP peers will be on-link. However, if this is not the case, and non-BGP routers are in between the BGP peers, eBGP must be configured explicitly, e.g. via options such as eBGP multi-hop.

E-DOC-CTC-20060306-0001 v1.038


5.1.2 The BGP Model

ModelThe figure below shows the BGP model:

ProcessBGP exchanges routing information as follows:

1 The BGP routing process from Router R1 establishes a BGP session with its peer in Router R2.

2 The routing processes exchange route records. Each route record consists of an IP prefix and accompanying route information. This information is called BGP Route Attributes.

3 Upon receiving Route Attributes, each BGP process analyses them and validates them for correctness.

4 After validation, the BGP process transfers control to the BGP Route Computation Algorithm (RCA).

If there is only a single route to a destination, the BGP RCA accepts the route.

If there are multiple routes to the same destination, the BGP RCA compares all attributes and rejects routes with less preferred attribute values until a single route remains. This process is called Route Tie-Breaking.This process is illustrated below:

The remaining route is accepted.

5 The BGP Process includes all accepted routes in its announcements to other BGP peers and installs them in the FIB.

BGP Process

RR

BGP ProcessRoute Record

RR

R1 R2

Route Record = Prefix + Attributes

BGP RIB

Local Preference 1

Multi-Exit-Discriminator 1

AS Path 1

EBGP/IBGP

Origin 1

Cost to Next-Hop 1

RouterID 1

Local Preference 2

Multi-Exit-Discriminator 2

AS Path 2

EBGP/IBGP

Origin 2

Cost Next-Hop 2

RouterID 2

Route Tie-breaking process

Peer IP Peer IP

Route Record 1 Route Record 2

E-DOC-CTC-20060306-0001 v1.039


5.1.3 Thomson Gateway Implementation Details

IntroductionAlthough BGP is a standardised protocol, usually each implementation has its own characteristics. This section describes some details of the Thomson Gateway BGP implementation.

Tie-Breaking ProcessAlthough a basic route selection algorithm is defined in the BGP specifications (draft-ietf-idr-bgp4-26.txt), there is no ‘generic’ tie-breaking mechanism. Each implementation has additional steps or alternative flows, to allow optimal tuning of the selection process.

Next is an overview of all steps taken in the Thomson Gateway decision process. Following list will allow you to understand which routes will be selected to be propagated from the BGP-RIB towards the M-RIB.

1 Prefer the route with the lowest Preference. This value has only local significance. By default this Preference is linked with the route origin (“2.2 Route Selection”). For routes learned via BGP the value is set to 170. Optionally this parameter can be influenced by the inbound traffic engineering options.

2 Prefer the route with the lowest Preference2. This value has only local significance. By default it is set to 0, but it can be influenced by the inbound traffic engineering options.

3 Prefer the route with the highest LOCAL_PREF value. This value is one of the BGP attributes sent with route records.

4 Prefer the route with the shortest AS_PATH value. This value is one of the BGP attributes sent with route records, containing a list of all AS-numbers the record passed before it ended up in our AS.

5 Prefer the route with the “best” Origin. IGP is better than EGP, which is better than Incomplete. Prefer any routes that do not have an inferior MED. Routes are considered to have an inferior MED if two routes to the same destination have been learned with the same neighbour AS, and one of the routes being considered does not have the lowest MED received for routes to that destination for the same neighbour AS. Prefer the route with the lowest IGP cost to the BGP next hop. The IGP cost is determined by comparing the Preference, then Preference2, then the Metric, and finally the Metric2 of the two resolving routes.

6 Prefer routes received from external peers.

7 Prefer the route with the lowest neighbour IP address.

E-DOC-CTC-20060306-0001 v1.040


5.2 Supported Use Cases

In this sectionThis section covers the following Use Cases:

Use Case Page

5.2.1 Simple Interior BGP 42

5.2.2 Simple Exterior BGP 43

5.2.3 BGP and Layer 2 VPNs 44

5.2.4 BGP and Multi Protocol Label Switching (MPLS) VPNs 45

5.2.5 BGP with Floating Static 46

5.2.6 Multi-homing & Traffic Engineering 47

E-DOC-CTC-20060306-0001 v1.041


5.2.1 Simple Interior BGP

DescriptionIn this use case, two routers in the same AS establish a BGP session. The DSL router R1 announces its stub network to R2. Both routers will exchange reachability information.

DiagramBelow is a diagram for this use case:

R1 R2

AS1

IBGP

E-DOC-CTC-20060306-0001 v1.042


5.2.2 Simple Exterior BGP

DescriptionIn this use case, two routers in a different AS establish a BGP session. Both the DSL Router and the edge router are in a different AS.


Stub Domain BR

EBGP

BR

AS1AS2

Stub / Transit domain

E-DOC-CTC-20060306-0001 v1.043


5.2.3 BGP and Layer 2 VPNs

DescriptionIn this use case, BGP is used as a routing protocol in a layer 2 VPN created via ATM or VLAN cross-connects.


AS2

AS1

AS3

BR

BR

BR

IBGP

EBGP

E-DOC-CTC-20060306-0001 v1.044


5.2.4 BGP and Multi Protocol Label Switching (MPLS) VPNs

DescriptionMPLS technology is gradually replacing Leased Lines services. In this case, the DSL router is a Customer Edge (CE) router that connects to a VPN provider‘s Provider Edge (PE) router.

There are several methods to inject a VPN site‘s reachability information into the provider‘s routing protocol, which is Multi protocol BGP (MP-BGP). Amongst others, it is possible to use:

> an IGP protocol (RIP, OSPF)

> eBGP

This use case focuses on the use of eBGP.

DiagramsThe diagram below shows the interconnection of the routers and the protocols used in this use case:

It is also possible to combine this with ISDN backup, as shown in the diagram below:

PE

EBGP

P P PE

MP-IBGP MP-IBGP MP-IBGP EBGP

CE CE

ISDN

BGP/MPLS VPN

ppp user name and password

PE1 PE2 Radius DB

Framed IP 30.0.0.’Framed Route 20.0.0.0/24 PPP

ppp user name and password

PPoI Unnumbered

DSLeBGP

IPoA Unnumbered

30.0.0.1 on loopback 0

20.0.0.0/24 PPP

CE

E-DOC-CTC-20060306-0001 v1.045


5.2.5 BGP with Floating Static

DescriptionRedundancy can be achieved by combining a routing protocol with a static route. To do this, the static route is given a higher administrative distance than that of BGP. If an identical dynamic route arrives via BGP, it is propagated to the FIB due to its lower administrative distance (A in the example below). If that route fails, the static route becomes the preferred one and is in its turn propagated to the FIB (B in the example below). If the BGP route comes back up, it will have a lower administrative distance, and the static route is rejected in favour of the dynamic one.

In the example below, administrative distance for eBGP is set to 20, while that of the static route is set to 30.

DiagramBelow is an example for this use case:

BGP Update contains:Destination = 0.0.0.0/0Gateway = 20.0.0.254

M-RIB

Itf 1

Itf 2

RT AddDestination = 0.0.0.0/0Gateway = 30.0.0.254Adistance = 30

M-RIB

BGP

Itf 1

Itf 2

BGP

CLI

Destination Gateway Interface ADistance0/T

B

S

S

0.0.0.0/0

0.0.0.0/0

50.0.0.0/24

20.0.0.254

30.0.0.254

40.0.0.254

R 0.0.0.0/0 20.0.0.254 Itf 1

Itf1

Itf3

Itf2

20

30

1

Preference Table

Proto Distance

C

S

RIP

iBGP

eBGP

0

1

100

200

20

FIB Destination Gateway0/T Interface

B 0.0.0.0/0 20.0.0.254 Itf1

Destination Gateway Interface ADistance0/T

B

S

S

0.0.0.0/0

0.0.0.0/0

50.0.0.0/24

20.0.0.254

30.0.0.254

40.0.0.254

Itf1

Itf3

Itf2

20

30

1

FIB Destination Gateway0/T Interface

B 0.0.0.0/0 30.0.0.254 Itf2

R 0.0.0.0/0 30.0.0.254 Itf 2

Preference Table

Proto Distance

C

S

RIP

iBGP

eBGP

0

1

100

200

20

E-DOC-CTC-20060306-0001 v1.046


5.2.6 Multi-homing & Traffic Engineering

MultihomingIn all previous use cases, BGP is used with a single entry/exit point. BGP also handles multiple exit/entry points between two given AS numbers. This is called multi-homing a site.

There are three reasons for multi-homing:

> Implementing redundancy to achieve a higher overall reliability

> Service provider diversity in order to leverage better service offerings, service availability, pricing etc.

> Achieve higher aggregate bandwidth via Load Balancing of IP traffic in case multiple exit/entry points exist for redundancy reasons

Traffic EngineeringWhen a device has multiple external links over which it receives identical or almost identical reachability infornation, BGP can be applied to modify this information. Thus, the outcome of the BGP algorithm can be influenced.

Traffic presented at the input of a BGP device will be forwarded over the pathd residing in the FIB. By influencing BGP reachability information, certain desirable effects can be accomplished. This technique is called BGP Traffic Engineering (BGP TE).

Some examples:

> Use the low-bandwidth links only if the high bandwidth link fails

> Use the expensive provider only if the cheap provider fails

Diagram: Multi-homing at two providersThe diagram below illustrates multi-homing at two providers:

BR

BR

BR

AS1

AS2

AS3eBGP

eBGP

E-DOC-CTC-20060306-0001 v1.047


Diagram: Multi-homing at a single providerThis diagram illustrates multi-homing at a single provider:

BR BR

BR BR

BR

BR

BR

BR

AS1

AS1 AS3

AS3

AS3

eBGP

eBGP

eBGP

E-DOC-CTC-20060306-0001 v1.048


5.3 BGP Configuration


Topic Page

5.3.1 Configuration Procedure 50

5.3.2 Global BGP Configuration 51

5.3.3 Additional Global Settings 53

E-DOC-CTC-20060306-0001 v1.049


5.3.1 Configuration Procedure

OverviewBGP offers a lot of configuration options that are spread throughout different parameters and configuration commands. Most scenarios can be configured by following this procedure:

1 Set global BGP options

2 Define peer(s)

3 Define access lists (global router level)

4 Attach access lists to peers

5 Define which routes to spread via BGP

E-DOC-CTC-20060306-0001 v1.050


5.3.2 Global BGP Configuration

Enable BGP RoutingBy default the BGP system service is disabled on your platform. In order to use BGP, it must be enabled

Checking the status:

To see the status of the BGP system service, proceed as follows to have a brief or full overview:

Enabling the service:

To enable the Thomson Gateway BGP system service, proceed as follows:

Process logging:

To activate logging of eventing in the Thomson Gateway BGP system service, proceed as follows:

After this, BGP specific logs will appear in the CLI tracing (activated by <CTRL>+<Q>)

AS NumberAn ‘Autonomous System’ is an IP network which is controlled as a single entity and has a clearly defined external routing policy. External routing protocols as BGP are used to exchange routing information between these Autonomous Systems.

=>:service system list name=BGPIdx Name Protocol SrcPort DstPort Group State---------------------------------------------------------------------

1 BGP tcp 179 disabled=>=>:service system list name=BGP expand=enabledIdx Name Protocol SrcPort DstPort Group------------------------------------------------------------------

1 BGP tcp 179Description................ Border Gateway ProtocolProperties................. peerAttributes................. state port srcip aclip aclif

aclifgroup map logUser Managed Attributes.... state logAttribute Values :State...................... (administratively) disabledPort....................... 179Source Ip Selection........ autoIp Access List............. anyInterface Access List...... anyInterface Group Access List anyMap List................... 179Logging.................... disabled

=>

=>:service system modify name BGP state enabled =>

=>:service system modify name BGP log enabled =>

E-DOC-CTC-20060306-0001 v1.051


When you are peering with only one Service Provider, probably you will need to use a private ASN offered by your Service Provider. Your network will become ‘part of your providers network’.

In case you peer with multiple Service Providers, you might need to obtain your own ASN and IP address space.

Configuration Example:

The AS-number to which the Thomson Gateway belongs has to be configured. Execute following CLI command to set the AS-number to 65000:

Viewing the configuration:

To view the AS-number that is configured, execute following CLI command:

Default peer valuesWhen two BGP peers establish a BGP session and exchange reachability-information, they rely on configuration information. This configuration data is partially BGP-system-wide, but some parts can also be peer-specific. As the Thomson Gateway’s network environment is rather simple, some of the BGP parameters are forced to well chosen defaults, and are non-configureable.

As in many cases the parameters set on peer level are equal for many peers, it is interesting to have a part of the configuration at top level, so it can be cloned each time a peer is created.

Below is an overview of these parameters:

:router config as=65000

i The AS-number is set on global ‘router’ config rather than BGP config. This is because this unique ‘network identifier’ could be shared between BGP and other routing protocols


i Note that the values are copied at peer creation, and are subsequently no longer related to the ‘default peer values’. Changes made on global level will not be inherited to all peers!

Parameter Description

Holdtime The holdtime defines how long the BGP daemon waits for keep-alive messages before it defines a peer as unavailable. Default is 180 seconds

KeepAliveTime The Keep Alive time defines the time interval at which keep-alive messages are sent towards a peer. Defaults to 1/3th of the holdtime

Preference2 Preference2 defines what value should be set in the ‘Preference2’ field for BGP routes that end up in the Master RIB. Default is 0

LocalPrefIn This parameter allows to overwrite the ‘Local Pref’ BGP attribute in incoming route advertisements

LocalPrefOut This parameter allows to overwrite the ‘Local Pref’ BGP attribute for advertised routes, but only in iBGP sessions

MedOut This parameter specifies the value for the ‘MED’ attribute on advertised routes. A value of 4294967295 specifies that the MED attribute shouldn't be sent

E-DOC-CTC-20060306-0001 v1.052


5.3.3 Additional Global Settings

IntroductionSome additional BPG specific parameters that can be configured are looked at in this section.

BGP RIB SizeThe total amount of routes that will be accepted in the BGP Routing Information Base can be set on BGP configuration level. Execute following CLI command to adjust the table size to maximum 512 entries:

By default the BGP-RIB will accept up to 1024 routes. Routes that fail to pass the input filtering that is applied on peer level are not taken into account.

Graceful Restart timingThe Thomson Gateway BGP implementation supports intelligent routing updates after a peer performed a graceful restart. The maximum time that BGP waits for a peer that might be performing a graceful restart can be changed from its default 180 seconds. Execute following CLI command to set this timer to 360 seconds:

Whether graceful restart will be negotiated is to be configured on peer level. More details on this can be found in “5.4.2 Modifying a Peer”

Flush configurationTo erase all existing BGP specific configuration that is made, execute following CLI command:

:router bpg config maxroutes=512

:router bgp config stalepathstime=360

:router bgp flush

E-DOC-CTC-20060306-0001 v1.053


5.4 Peer configuration

IntroductionFor each network device with whom you wish to exchange routing information, a ‘peer’ will have to be configured. Routing information is transferred over a BGP session between two BGP peers. When the session is established, both peers exchange (a part) of their routing information.

The peer configuration not only holds the reachability information, but also what types of information (routes) to accept from this peer, how to adjust the information received (actually influencing the values received, often referred to as ‘traffic engineering’), and also what information to send to it.

Configuration stepsFollow these steps to define a peer:

1 Create the peer

2 Configure the peer, by setting:

State

Capability negotiation

Inbound traffic engineering

Outbound traffic engineering

Detailed options


Topic Page

5.4.1 Creating a peer 55

5.4.2 Modifying a Peer 56

5.4.3 Clearing peers 60

E-DOC-CTC-20060306-0001 v1.054


5.4.1 Creating a peer

IntroductionA peer is defined by its IP address and the AS it belongs to

Add commandProceed as follows to define a peer with IP-address 10.0.0.7, member of Autonomous System 65001:

Once a peer is created, both the remote IP address and the AS number are values that cannot be changed. If one of these values has to change, the peer has to be deleted, and a new peer has to be created.

Verify Proceed as follows to check the peers configured on your Thomson Gateway:

[router bgp peer]=>add remote-addr=10.0.0.7 remote-as=65001

[router bgp peer]=>listLocal configuration-------------------

AS number 65000BGP identifier 10.0.0.138

Peer AS Version State---------------------------------------------------------10.0.0.7 65001 4 Connect

E-DOC-CTC-20060306-0001 v1.055


5.4.2 Modifying a Peer

IntroductionWhen a peer is created, several configuration parameters can be used to tweak how the routing information that is exchanged should be handled. The settings can be divided in following groups:

> State

> Capability negotiation

> Inbound traffic engineering

> Outbound traffic engineering

> Detailed options

To identify the peer to which configuration changes are to be made, the remote IP address is used as a reference in the ‘modify’ command.

Peer StateWhether or not to exchange BGP information can be controlled on a per-peer basis. As such, a BGP peer does not have to be deleted if for any reason BGP peering is not required at a certain moment in time.

Execute following BGP command to disable the peer with remote-IP 10.0.0.7:

Execute following CLI command to verify the result:

[router bgp peer]=>modify peer=10.0.0.7 state=disabled

[router bgp peer]=>listLocal configuration-------------------

AS number 65000BGP identifier 10.0.0.138

Peer AS Version State---------------------------------------------------------10.0.0.7 65001 4 Idle

E-DOC-CTC-20060306-0001 v1.056


Capability NegotiationBy default the Thomson Gateway only advertises one capability, being the ‘Multi-protocol Extension’ capability. Per peer it is possible to configure which additional capabilities should be negotiated. Currently, these three capabilities can be set to be negotiated:

> Route Refresh (rrcap), to allow the use of ‘route-refresh’ messages. With this message a peer can be asked to resend all its routes. This allows smooth appliance of newly defined policies. When the other peer does not support this capability, the complete BGP sessions has to be stopped and re-established to apply a new policy (as that is the only way to receive all routes).

> Dynamic capability (dynamiccap), to allow both peers to send additional capability messages during an active BGP session. Normally capability negotiations are only performed at session start-up. When the ‘dynamic capability’ is agreed upon, the capability negotiations can be performed at any moment in time.

> Graceful Restart (grrestartcap), to reduce network disruption due to a BGP peer that is rebooting. Often the Thomson Gateway is having a BGP session with high-availability edge routers from the network provider. These devices typically support ‘non stop forwarding’ (they keep forwarding packets in case of a system reboot). For the Thomson Gateway this means that the BGP session will be lost, but packets will still be forwarded. So it might be a good idea to not drop all routes we know from this edge router, but to wait some time and see if it comes back on-line. When the remote router has rebooted, it will re-establish the BGP session and will mention in the session initialisation that it ‘gracefully restarted’. All routing information will be exchanged and will be completed with an ‘End-of-RIB’ message. How long the Thomson Gateway will wait for gracefully restarting peers can be configured in global BGP configuration, as mentioned in “5.3.3 Additional Global Settings”.

These CLI commands are an example on how to modify these additional capability negotiations for peer 10.0.0.7:

Inbound Traffic EngineeringIncoming route advertisements can be tuned on a per-peer basis. Each peer has a set of parameters which can influence the reachability information it receives. Firstly these parameters can overrule BGP attributes that are part of the received routes (MED, LocalPref), secondly values of local significance can be set (Pref, Pref2).

Currently following BGP route attributes can be overruled on a per-peer basis:

> Local Preference (localprefin): The value of the LocalPref attribute in all incoming routes can be set to a specified value.

> MED (medin): enable or disable the use of the received Multi-Exit Discriminator value. At the same time this parameter also defines if the MED will be used in sent updates.

Currently following Thomson Gateway internal route values can be overruled on a per-peer basis:

> Preference (preference), is a first internal indication of the preference of the route. By default this parameter is used to make a distinction between different route types. By setting this parameter, the default value of 170 that all BGP originated routes get, can be overwritten.

> Preference2 (preference2), is a second internal indication of preference of a route. By default this value is not set. By setting this parameter, another distinction can be made between routes entering from different peers.

[router bgp peer]=>modify peer=10.0.0.7 rrcap=enabled[router bgp peer]=>modify peer=10.0.0.7 dynamiccap=enabled[router bgp peer]=>modify peer=10.0.0.7 grrestartcap=disabled

i These values of local significance are often referred to as ‘Administrative Distance’. Their only use is to manipulate the priorities of routes in the local routing table.

E-DOC-CTC-20060306-0001 v1.057


Following CLI commands give an example on how to set some parameters to performs inbound traffic engineering for peer 10.0.0.7:

Outbound Traffic EngineeringIt is possible to tune sent out advertisements on a per peer basis. Some parameters in the peer configuration allow to set specific values for certain BGP attributes.

These BGP attributes can be set for outbound route advertisements:

> Local Preference (localprefout), to set a specific value in the Local Preference BGP attribute of the advertised routes. Note that this is only valid for iBGP sessions.

> MED (medout), to set a specific value for the Multi-Exit Discriminator BGP attribute of the advertised routes.

> AS-Path (asprepend), to specify how many times this router will prepend its AS number to the AS-Path BGP attribute of the advertised routes.

Following CLI commands give an example on how to set some parameters to performs outbound traffic engineering for peer 10.0.0.7:

Detailed OptionsNext to the previously described options, more detailed configuration can be made on peer specific level. These are some of the other parameters that can be set:

> Local IP Address (local-addr), to force the source IP address we will use to initiate a BGP sessions to this peer.

> HoldTime (holdtime), to define how many seconds the BGP daemon waits for keep-alive messages before it defines a peer as unavailable.

> Keep Alive time (keepalivetime), to define the time interval in seconds at which keep-alive messages are sent towards a peer. This value defaults to one third of the HoldTime.

> Maximum number of routes (maxroutes), to specify the maximum number of routes that will be accepted from this peer in the BGP routing table.

> Output delay (outdelay), to specify how many seconds a route has to be present in the Master-RIB before it will be sent out to this peer.

> Initialization Initiative (passive), to specify whether or not we will take the initiative to setup a BGP session to this peer.

Following CLI commands give an example on how to set some detailed parameters for peer 10.0.0.7:

[router bgp peer]=>modify peer=10.0.0.7 preference=100 preference2=50[router bgp peer]=>modify peer=10.0.0.7 medin=disabled[router bgp peer]=>modify peer=10.0.0.7 localprefin=50

[router bgp peer]=>modify peer=10.0.0.7 localprefout=50[router bgp peer]=>modify peer=10.0.0.7 medout=10[router bgp peer]=>modify peer=10.0.0.7 asprepend=2

[router bgp peer]=>modify peer=10.0.0.7 local-addr=10.0.0.138[router bgp peer]=>modify peer=10.0.0.7 holdtime=60 keepalivetime=15[router bgp peer]=>modify peer=10.0.0.7 maxroutes=256[router bgp peer]=>modify peer=10.0.0.7 outdelay=120[router bgp peer]=>modify peer=10.0.0.7 passive=enabled

E-DOC-CTC-20060306-0001 v1.058


VerifyExecute following CLI command to verify the complete configuration for peer 10.0.0.7:

[router bgp peer]=>list peer 10.0.0.7 expand enabledPeer AS Version State Type-------------------------------------------------------------10.0.0.7 65001 4 Idle External

Peer Admin State disabledPassive disabledPreference 170Preference2 0Loc_Pref_Import 100Loc_Pref_Export 100MED in usedMED out noneLocal Configured Hold Time 180 sNegotiated Hold Time 0 sKeep Alive Time 60 sRoute Out Delay 0 sMax Number of RIB BGP Routes Not Limited# AS Prepend 1Multi Protocol IPv4 Unicast sent ,notrecvRoute Refresh Cap notsent,notrecvGR Cap IPV4 preserving notsent,notrecvGR Cap receiver functionality notsent,notrecvDynamic Capability Advert sent ,notrecvRemote BGP Identifier 0.0.0.0Local BGP Identifier 10.0.0.138Restarting noLast State NoStateLast Event NoEventLast Error Sent 0Last Error Subcode 0# Sent Updates 0# Recv Updates 0# Sent Messages 0# Recv Messages 0

E-DOC-CTC-20060306-0001 v1.059


5.4.3 Clearing peers

IntroductionClearing a peer means to reset its session. The goal is to flush all routes learned from this peer and to restart from zero.

Typically this is done to apply new configuration as changed policies. Policies are only applied on reception of routes, so the peer has to be asked to re-send all its routing information.

Basic clearIf no specific configuration is made, it is not possible to ask a BGP peer to re-send all its routing information. The only option is to fully reset the BGP session. All routing information that was learned will be dropped, and a brand new session will be initiated.

Execute following CLI command to reset the BGP session to peer 10.0.0.7:

Route RefreshOne of the possible capabilities that can be negotiated in the beginning of a BGP session is called ‘route refresh’. When both peers support this capability, at any moment in time they can request to resend all routing information, without the need to tear down the BGP session.

Execute following CLI command to perform a ‘route refresh’ on peer 10.0.0.7:

[router bgp peer]=>clear peer 10.0.0.7

[router bgp peer]=>clear peer 10.0.0.7 routerefresh=enabled

E-DOC-CTC-20060306-0001 v1.060


5.5 Policies

IntroductionIn contrast to some other routing protocols, BGP has to be explicitly instructed on what local reachability information it should announce to its peers.

The first step is to define what parts of available routing information can be ‘redistributed’ via BGP. Only the statically configured routes, the connected routes, and so on.

Secondly, the flow of routes has to be controlled, as probably not ‘all’ of the redistributed routes actually should be transmitted. Several methods exist to control this flow:

> Route filters (blacklist: routes that should be filtered out)

> Network statement (whitelist: routes that are allowed)

In this section

Topic Page

5.5.1 Route Redistribution 62

5.5.2 Applying Route Filters 63

5.5.3 Network Statement 64

E-DOC-CTC-20060306-0001 v1.061


5.5.1 Route Redistribution

IntroductionVia the route redistribution policy it can be configured which (groups of) routes of the Master-RIB can be announced to other BGP peers.

Configuration procedurePer group of routes the redistribution command has to be issued. The routes are grouped as follows:

> aggregate, all routes

> connected, all routes towards directly connected networks (Logical IP Subnet and Point-to-Point interfaces)

> ospf, all routes received via the OSPF routing protocol

> rip, all routes received via the RIP routing protocol

> static, all standard, interface and extended routes.

Proceed as follows to configure the redistribution of connected and static routes via BGP:

VerifyExecute following CLI command to verify if the correct route groups are set for redistribution:

Stop redistributionThe redistribution of a group of routes can be stopped by issuing the ‘noredistribute’ command.

Proceed as follows to stop the redistribution of all connected routes:

[router bgp policy]=>redistribute proto connected[router bgp policy]=>redistribute proto static

[router bgp policy]=>list

Networks imported into BGP**************************

Proto Networks----- --------connected all networksbgp all networksstatic all networksany 30.0.0.0/24

[router bgp policy]=>noredistribute proto connected

E-DOC-CTC-20060306-0001 v1.062


5.5.2 Applying Route Filters

IntroductionRoute filters can be used twofold. First they can be used to filter the incoming route advertisements. Secondly they can be used to filter (and as such limit) the redistribution of our own routes.

Advantage of these prefix filters is that they can be configured on a per-peer level. As such different filtering can be set on every peer.

The creation of the access-lists as such is performed on global router configuration level, as they can be used by different routing protocols. This configuration is described in “3.3 Routing Policies”

Set Import FilteringTo activate an import route filter, all that we have to do is to activate an access-list, eventually peer specific.

To enable access-list ‘MyAccLst1’ on all route advertisements coming in from peer 10.0.0.7, execute following CLI command:

An import route filter can be disabled by executing the ‘nodistlistin’ command with the same parameters.

Set Export FilteringTo activate an export route filter, again only an access-list is to be activated, eventually peer specific, and protocol (route group) specific.

To enable access-list ‘MyAccLst1’ on all route advertisements that are being sent out towards peer 10.0.0.7, originating from ospf, execute following CLI command:

An export route filter can be disabled by executing the ‘nodistlistout’ command with the same parameters.

Verify Proceed as follows to verify the active BGP route filtering configuration:

[router bgp policy]=>distlistin peer 10.0.0.7 accesslist MyAccLst1

[router bgp policy]=>distlistout peer=10.0.0.7 accesslist MyAccLst1 protocol ospf


...

Prefix filters**************

Peer Type Access List Proto-----------------------------------------------------------all in - bgpall out - -10.0.0.7 in MyAccLst1 bgp10.0.0.7 out MyAccLst1 ospf

E-DOC-CTC-20060306-0001 v1.063


5.5.3 Network Statement

IntroductionThe ‘Network Statement’ is a routing policy that operates as a whitelist. Only routes that match the network prefixes that are explicitly defined will be sent out. All unknown routes passing the Network Statement policy will be dropped. Non-advertised prefixes are not sent out.

Configuration procedureExecute following CLI command to add the 30.0.0.0/24 prefix to the list of ‘prefixes to be advertised’:

VerifyExecute following CLI command the verify if the Network Statement is configured:

[router bgp policy]=>network addr 30.0.0.0 netmask 24

! Note that the ‘Network Statement’ is no more than a policy filter! This means that all prefixes defined via the Network Statement also have to exist in the Master-RIB! They type (static, connected,...) is not important

Never mix the use of Filtering policies with the Network Statement. Their uses are mutually exclusive!


Networks imported into BGP**************************

Proto Networks----- --------bgp all networksany 30.0.0.0/24

E-DOC-CTC-20060306-0001 v1.064

THOMSON Telecom BelgiumPrins Boudewijnlaan 472650 Edegem

www.thomson-broadband.com

© THOMSON 2007. All rights reserved. E-DOC-CTC-20060306-0001 v1.0.


Date post:	07-Oct-2020
Category:	Documents
Upload:	others
View:	6 times
Download:	0 times

Thomson Gateway...This is shown in the diagram below: Equal routes RIP-RIB BGP-RIB OSPF-RIB t route...

Documents