Chapter 4 – Authentication

This Handbook chapter contains the following sections:

Introduction to authentication describes some basic elements and concepts of authentication.

Authentication servers describes external authentication servers, where a FortiGate unit fits into the topology, and how to configure a FortiGate unit to work with that type of authentication server.

Users and user groups describes the different types of user accounts and user groups. Authenticated access to resources is based on user identities and user group membership. Two-factor authentication methods, including FortiToken, provide additional security.

Managing Guest Access explains how to manage temporary accounts for visitors to your premises. Configuring authenticated access provides detailed procedures for setting up authenticated access in security policies and authenticated access to VPNs.

Captive portals describes how to authenticate users through a web page that the FortiGate unit presents in response to any HTTP request until valid credentials are entered. This can be used for wired or WiFi network interfaces.

Certificate-based authentication describes authentication by means of X.509 certificates.

Single Sign-On using a FortiAuthenticator unit describes how to use a FortiAuthenticator unit as an SSO agent that can integrate with external network authentication systems such as RADIUS and LDAP to gather user logon information and send it to the FortiGate unit. Users can also log on through a FortiAuthenticator-based web portal or the FortiClient SSO Mobility Agent.

Single Sign-On to Windows AD describes how to set up Single Sign-On in a Windows AD network by configuring the FortiGate unit to poll domain controllers for information user logons and user privileges.

Agent-based FSSO describes how to set up Single Sign-On in Windows AD, Citrix, or Novell networks by installing Fortinet Single Sign On (FSSO) agents on domain controllers. The FortiGate unit receives information about user logons and allows access to network resources based on user group memberships.

SSO using RADIUS accounting records describes how to set up Single Sign-On in a network that uses RADIUS authentication. In this configuration, the RADIUS server send RADIUS accounting records to the FortiGate unit when users log on or off the network. The record includes a user group name that can be used in FortiGate security policies to determine which resources each user can access.

Monitoring authenticated users describes FortiOS authenticated user monitor screens.

Examples and Troubleshooting provides configuration examples and troubleshooting suggestions.

 

Intermediate System to Intermediate System Protocol (IS-IS)

This section describes the Intermediate System to Intermediate System Protocol (IS-IS). The following topics are included in this section:

• IS-IS background and concepts
• How IS-IS works Troubleshooting IS-IS Simple IS-IS example
• Network layout and assumptions
• Expectations
• CLI configuration Verification Troubleshooting

 

IS–IS background and concepts

Intermediate System to Intermediate System Protocol (IS-IS) allows routing of ISO’s OSI protocol stack Connectionless Network Service (CLNS). IS-IS is an Interior Gateway Protocol (IGP) not intended to be used between Autonomous Systems (ASes).

Background

IS-IS was developed by Digital Equipment Corporation and later standardized by ISO in 1992 as ISO 19589 (see RFC 1142—note this RFC is different from the ISO version). At roughly the same time, the Internet Engineering Task Force developed OSPF (see Open Shortest Path First (OSPF) on page 377). After the initial version, IP support was added to IS-IS and this version was called Integrated IS-IS (see RFC 1195). Its widespread use started when an early version of IS-IS was included with BSD v4.3 Linux as the routed daemon. The routing algorithm used by IS-IS, the Bellman–Ford algorithm, first saw widespread use as the initial routing algorithm of the ARPANET.

IS-IS is a link state protocol well-suited to smaller networks that is in widespread use and has near universal support on routing hardware. It is quick to configure, and works well if there are no redundant paths. However, IS- IS updates are sent out node-by-node, so it can be slow to find a path around network outages. IS-IS also lacks good authentication, can not choose routes based on different quality of service methods, and can create network loops if you are not careful. IS-IS uses Djikstra’s algorithm to find the best path, like OSPF.

While OSPF is more widely known, IS-IS is a viable alternative to OSPF in enterprise networks and ISP infrastructures, largely due to its native support for IPv6 and its non-disruptive methods for splitting, merging, migrating, and renumbering network areas.

The FortiGate implementation supports IS-IS for IPv4 (see RFCs 1142 and 1162), but does not support IS-IS for IPv6 (although this technically can be achieved using the ZebOS routing module).

 

How IS-IS works

As one of the original modern dynamic routing protocols, IS-IS is straightforward. Its routing algorithm is not complex, there are some options to allow fine tuning, and it is straightforward to configure IS-IS on FortiGate units.

From RFC 1142:

The routing algorithm used by the Decision Process is a shortest path first (SPF) algorithm. Instances of the algorithm are run independently and concurrently by all intermediate systems in a routing domain. IntraDomain routing of a PDU occurs on a hop-by-hop basis: that is, the algorithm determines only the next hop, not the complete path, that a data PDU will take to reach its destination.

IS–IS versus static routing

IS-IS was one of the earliest dynamic routing protocols to work with IP addresses. As such, it is not as complex as more recent protocols. However, IS-IS is a big step forward from simple static routing.

While IS-IS may be slow in response to network outages, static routing has zero response. The same is true for convergence—static routing has zero convergence. Both IS-IS and static routing have the limited hop count, so it is neither a strength nor a weakness.

Open Shortest Path First (OSPF)

This section describes OSPF routing.

The following topics are included in this section: OSPF Background and concepts

Troubleshooting OSPF Basic OSPF example

Advanced inter-area OSPF example

Controlling redundant links by cost

 

OSPF Background and concepts

OSPF (Open Shortest Path First) is a link-state interior routing protocol, that is widely used in large enterprise organizations. It only routes packets within a single autonomous system (AS). This is different from BGP as BGP can communicate between ASes.

This section includes:

• Background
• The parts and terminology of OSPF
• How OSPF works

Background

OSPF version 2 was defined in 1998 in RFC 2328. OSPF was designed to support classless IP addressing, and variable subnet masks. This was a shortcoming of the earlier RIP protocols.

Updates to OSPF version 2 are included in OSPF version 3 defined in 2008 in RFC 5340. OSPF3 includes support for IPv6 addressing where previously OSPF2 only supports IPv4 addressing.

The main benefit of OSPF is that it detects link failures in the network quickly and within seconds has converged network traffic successfully without any networking loops. Also OSPF has many features to control which routes are propagated and which are not, maintaining smaller routing tables. OSPF can also provide better load- balancing on external links than other interior routing protocols.

Border Gateway Protocol (BGP)

This section describes Border Gateway Protocol (BGP). The following topics are included in this section:

BGP background and concepts

Troubleshooting BGP

Dual-homed BGP example

Redistributing and blocking routes in BGP

 

 

BGP background and concepts

The border gateway protocol contains two distinct subsets — internal BGP (iBGP) and external BGP (eBGP). iBGP is intended for use within your own networks. eBGP is used to connect many different networks together, and is the main routing protocol for the Internet backbone. FortiGate units support iBGP, and eBGP only for communities.

The following topics are included in this section:

• Background
• Parts and terminology of BGP
• How BGP works

 

Background

BGP was first used in 1989. The current version, BGP-4, was released in 1995 and is defined in RFC 1771. That RFC has since been replaced by the more recent RFC 4271. The main benefits of BGP-4 are classless inter- domain routing, and aggregate routes. BGP is the only routing protocol to use TCP for a transport protocol. Other routing protocols use UDP.

BGP makes routing decisions based on path, network policies and rulesets instead of the hop-count metric as RIP does, or cost-factor metrics as OSPF does.

BGP-4+ supports IPv6. It was introduced in RFC 2858 and RFC 2545.

BGP is the routing protocol used on the Internet. It was designed to replace the old Exterior Gateway Protocol (EGP) which had been around since 1982, and was very limited. In doing so, BGP enabled more networks to take part in the Internet backbone to effectively decentralize it and make the Internet more robust, and less dependent on a single ISP or backbone network.

 

Parts and terminology of BGP

In a BGP network, there are some terms that need to be explained before going ahead. Some parts of BGP are not explained here as they are common to other dynamic routing protocols as well. When determining your network topology, note that the number of available or supported routes is not set by the configuration but depends on your FortiGate’s available memory. For more information on parts of BGP that are not listed here, see Dynamic Routing Overview on page 284.

 

BGP and IPv6

FortiGate units support IPv6 over BGP using the same config router bgp command as IPv4, but different subcommands.

The main CLI keywords have IPv6 equivalents that are identified by the “6” on the end of the keyword, such as with config network6 or set allowas-in6. For more information about IPv6 BGP keywords, see the FortiGate CLI Reference.

IPv6 BGP commands include:

config router bgp

set activate6 {enable | disable}

set allowas-in6 <max_num_AS_integer>

set allowas-in-enable6 {enable | disable}

set as-override6 {enable | disable}

set attribute-unchanged6 [as-path] [med] [next-hop] set capability-default-originate6 {enable | disable} set capability-graceful-restart6 {enable | disable} set capability-orf6 {both | none | receive | send} set default-originate-route-map6 <routemap_str>

set distribute-list-in6 <access-list-name_str> set distribute-list-out6 <access-list-name_str> set filter-list-in6 <aspath-list-name_str>

set filter-list-out6 <aspath-list-name_str>

set maximum-prefix6 <prefix_integer>

set maximum-prefix-threshold6 <percentage_integer> set maximum-prefix-warning-only6 {enable | disable} set next-hop-self6 {enable | disable}

set prefix-list-in6 <prefix-list-name_str> set prefix-list-out6 <prefix-list-name_str> set remove-private-as6 {enable | disable} set route-map-in6 <routemap-name_str>

set route-map-out6 <routemap-name_str>

set route-reflector-client6 {enable | disable}

set route-server-client6 {enable | disable}

set send-community6 {both | disable | extended | standard}

set soft-reconfiguration6 {enable | disable} set unsuppress-map6 <route-map-name_str> config network6

config redistribute6 end

 

Roles of routers in BGP networks

Dynamic routing has a number of different roles routers can fill such as those covered in Dynamic Routing

Overview on page 284. BGP has a number of custom roles that routers can fill. These include:

• Speaker routers
• Peer routers or neighbors
• Route reflectors (RR)

Speaker routers

Any router configured for BGP is considered a BGP speaker. This means that a speaker router advertises BGP

routes to its peers.

Any routers on the network that are not speaker routers, are not treated as BGP routers.

 

 

Peer routers or neighbors

In a BGP network, all neighboring BGP routers or peer routers are routers that are connected to your FortiGate unit. Your FortiGate unit learns about all other routers through these peers.

You need to manually configure BGP peers on your FortiGate unit as neighbors. Otherwise these routers will not be seen as peers, but instead as simply other routers on the network that don’t support BGP. You can optionally use MD5 authentication to password protect BGP sessions with those neighbors. (see RFC 2385).

You can configure up to 1000 BGP neighbors on your FortiGate unit. You can clear all or some BGP neighbor connections (sessions) using the execute router clear bgp command.

For example, if you have 10 routes in the BGP routing table and you want to clear the specific route to IP address 10.10.10.1, enter the command:

execute router clear bgp ip 10.10.10.1

To remove all routes for AS number 650001, enter the command:

execute router clear bgp as 650001

To remove route flap dampening information for the 10.10.0.0/16 subnet, enter the command:

execute router clear bgp dampening 10.10.0.0/16

In Figure 1, Router A is directly connected to five other routers in a network that contains 12 routers overall. These routers, the ones in the blue circle, are Router A’s peers or neighbors.

 

Router A and its 5 peer routers

As a minimum, when configuring BGP neighbors you must enter their IP address, and the AS number (remote- as). This is all the information the web-based manager interface allows you to enter for a neighbor.

The BGP commands related to neighbors are quite extensive and include:

config router bgp config neighbor

edit <neighbor_address_ipv4>

set activate {enable | disable}

set advertisement-interval <seconds_integer>

set allowas-in <max_num_AS_integer>

set allowas-in-enable {enable | disable}

set as-override {enable | disable}

set attribute-unchanged [as-path] [med] [next-hop]

set bfd {enable | disable}

set capability-default-originate {enable | disable}

set capability-dynamic {enable | disable}

set capability-graceful-restart {enable | disable} set capability-orf {both | none | receive | send} set capability-route-refresh {enable | disable}

set connect-timer <seconds_integer>

set description <text_str>

set distribute-list-in <access-list-name_str> set distribute-list-out <access-list-name_str> set dont-capability-negotiate {enable | disable} set ebgp-enforce-multihop {enable | disable}

set ebgp-multihop {enable | disable}

set ebgp-multihop-ttl <seconds_integer> set filter-list-in <aspath-list-name_str> set filter-list-out <aspath-list-name_str> set holdtime-timer <seconds_integer>

set interface <interface-name_str>

set keep-alive-timer <seconds_integer>

set maximum-prefix <prefix_integer>

set maximum-prefix-threshold <percentage_integer> set maximum-prefix-warning-only {enable | disable} set next-hop-self {enable | disable}

set passive {enable | disable}

set password <string>

set prefix-list-in <prefix-list-name_str> set prefix-list-out <prefix-list-name_str> set remote-as <id_integer>

set remove-private-as {enable | disable} set retain-stale-time <seconds_integer> set route-map-in <routemap-name_str>

set route-map-out <routemap-name_str>

set route-reflector-client {enable | disable}

set route-server-client {enable | disable}

set send-community {both | disable | extended | standard}

set shutdown {enable | disable}

set soft-reconfiguration {enable | disable}

set strict-capability-match {enable | disable}

set unsuppress-map <route-map-name_str> set update-source <interface-name_str> set weight <weight_integer>

end end

end

 

Route reflectors (RR)

Route reflectors in BGP concentrate route updates so other routers need only talk to the route reflectors to get all the updates. This results in smaller routing tables, fewer connections between routers, faster responses to network topology changes, and less administration bandwidth. BGP route reflectors are defined in RFC 1966.

In a BGP route reflector configuration, the AS is divided into different clusters that each include client and reflector routers. The client routers supply the reflector routers with the client’s route updates. The reflectors pass this information along to other route reflectors and border routers. Only the reflectors need to be configured, not the clients — the clients will find the closest reflector and communicate with it automatically. The reflectors communicate with each other as peers. FortiGate units can be configured as either reflectors or clients.

Since route reflectors are processing more than the client routers, the reflectors should have more resources to handle the extra workload.

Smaller networks running BGP typically don’t require route reflectors (RR). However, RR is a useful feature for large companies, where their AS may include 100 routers or more. For example, for a full mesh 20 router configuration within an AS, there would have to be 190 unique BGP sessions — just for routing updates within the AS. The number of sessions jumps to 435 sessions for just 30 routers, or 4950 sessions for 100 routers. From these numbers, its plain that updating this many sessions will quickly consume the limited bandwidth and processing resources of the routers involved.

The following diagram illustrates how route reflectors can improve the situation when only six routers are involved. The AS without route reflectors requires 15 sessions between the routers. In the AS with route reflectors, the two route reflectors receive route updates from the reflector clients (unlabeled routers in the diagram) in their cluster as well as other route reflectors and pass them on to the border router. The RR configuration only require six sessions. This example shows a reduction of 60% in the number of required sessions.

Routing Information Protocol (RIP)

This section describes the Routing Information Protocol (RIP). The following topics are included in this section:

RIP background and concepts

Troubleshooting RIP Simple RIP example RIPng — RIP and IPv6

 

RIP background and concepts

This section contains:

• Background
• Parts and terminology of RIP
• How RIP works

 

Background

Routing Information Protocol (RIP) is a distance-vector routing protocol intended for small, relatively homogeneous networks. Its widespread use started when an early version of RIP was included with BSD v4.3

Linux as the routed daemon. The routing algorithm used by RIP, the Bellman–Ford algorithm, first saw widespread use as the initial routing algorithm of the ARPANET.

RIP benefits include being well suited to smaller networks, is in widespread use, near universal support on routing hardware, quick to configure, and works well if there are no redundant paths. However, RIP updates are sent out node-by-node so it can be slow to find a path around network outages. RIP also lacks good authentication, can not choose routes based on different quality of service methods, and can create network loops if you are not careful.

The FortiGate implementation of RIP supports RIP version 1 (see RFC 1058), RIP version 2 (see RFC 2453), and the IPv6 version RIPng (see RFC 2080).

 

RIP v1

In 1988 RIP version 1, defined in RFC 1058, was released. The RFC even states that RIP v1 is based on Linux routed due to it being a “defacto standard”.

It uses classful addressing and uses broadcasting to send out updates to router neighbors. There is no subnet information included in the routing updates in classful routing, and it does not support CIDR addressing — subnets must all be the same size. Also, route summarization is not possible.

RIP v1 has no router authentication method, so it is vulnerable to attacks through packet sniffing, and spoofing.

 

RIP v2

In 1993, RIP version 2 was developed to deal with the limitations of RIP v1. It was not standardized until 1998. This new version supports classless routing, and subnets of various sizes.

Router authentication was added in RIP v2 — it supports MD5. MD5 hashes are an older encryption method, but this is much improved over no security at all.

In RIP v2 the hop count limit remained at 15 to be backwards compatible with RIP v1.

RIP v2 uses multicasting to send the entire routing table to router neighbors, thereby reducing the traffic for devices that are not participating in RIP routing.

Routing tags were added as well, which allow internal routes or redistributed routes to be identified as such.

 

RIPng

RIPng, defined in RFC 2080, is an extension of RIP2 designed to support IPv6. However, RIPng varies from

RIPv2 in that it is not fully backwards compatible with RIPv1.

• RIPng does not support RIPv1 update authentication, it relies on IPsec
• RIPng does not allow attaching tags to routes as in RIPv2
• RIPng requires specific encoding of the next hop for a set of route entries, unlike RIPv2 that encodes the next-hop into each route entry.

 

Parts and terminology of RIP

Before you can understand how RIP functions, you need to understand some of the main concepts and parts of RIP.

This section includes:

• RIP and IPv6
• Default information originate option
• Update, Timeout, and Garbage timers
• Authentication and key-chain
• Access Lists

 

RIP and IPv6

RIP Next Generation (RIPng) is a new version of RIP was released that includes support for IPv6.

The FortiGate unit command config router ripng is almost the same as config router rip, except that IPv6 addresses are used. Also if you are going to use prefix or access lists with RIPng, you must use the config router access-list6 or config prefix-list6 versions of those commands.

If you want to troubleshoot RIPng, it is the same as with RIP but specify the different protocol, and use IPv6 addresses. This applies to commands such as get router info6 when you want to see the routing table, or other related information.

If you want to route IPv4 traffic over an IPv6 network, you can use the command config system ip6- tunnel to configure the FortiGate unit to do this. The IPv6 interface is configured under config system interface. All subnets between the source and destination addresses must support IPv6. This command is not supported in Transparent mode.

For example, you want to set up a tunnel on the port1 interface starting at 2002:C0A8:3201:: on your local network and tunnel it to address 2002:A0A:A01:: where it will need access to an IPv4 network again. Use the following command:

config system ipv6-tunnel edit test_tunnel

set destination 2002:A0A:A01::

set interface port1

set source 2002:C0A8:3201::

end end

The CLI commands associated with RIPng include:

 

config router ripng

config router access-list6 config router prefix-list6 config system ipv6-tunnel get router info6 *

 

Default information originate option

This is the second advanced option for RIP in the web-based manager, right after metric. Enabling default- information-originate will generate and advertise a default route into the FortiGate unit’s RIP-enabled networks. The generated route may be based on routes learned through a dynamic routing protocol, routes in the routing table, or both. RIP does not create the default route unless you use the always option.

Select Disable if you experience any issues or if you wish to advertise your own static routes into RIP updates. You can enable or disable default-information-originate in Router > Dynamic > RIP, under Advanced

Options, or use the CLI.

The CLI commands associated with default information originate include:

config router rip

set default-information-originate end

IPv6 in dynamic routing

Unless otherwise stated, routing protocols apply to IPv4 addressing. This is the standard address format used. However, IPv6 is becoming more popular and new versions of the dynamic routing protocols have been introduced.

Dynamic routing supports IPv6 on your FortiGate unit. The new versions of these protocols and the corresponding RFCs are:

• RIP next generation (RIPng) — RFC 2080 – Routing Information Protocol next generation (RIPng). See RIP and IPv6.
• BGP4+ — RFC 2545, and RFC 2858 Multiprotocol Extensions for IPv6 Inter-Domain Routing, and Multiprotocol Extensions for BGP-4 (MP-BGP) respectively. See BGP and IPv6.
• OSPFv3 — RFC 2740 Open Shortest Path First version 3 (OSPFv3) for IPv6 support. See OSPFv3 and IPv6.
• Integrated IS-IS — RFC 5308 for IPv6 support. See Integrated IS-IS.

As with most advanced routing features on your FortiGate unit, IPv6 settings for dynamic routing protocols must be enabled before they will be visible in the GUI. To enable IPv6 configuration in the GUI, enable it in System > Admin > Settings. Alternatively, you can directly configure IPv6 for RIP, BGP, or OSPF protocols using CLI commands.

 

Dynamic routing terminology

Dynamic routing is a complex subject. There are many routers on different networks and all can be configured differently. It become even more complicated when you add to this each routing protocol having slightly different names for similar features, and many configurable features for each protocol.

To better understand dynamic routing, here are some explanations of common dynamic routing terms.

• Aggregated routes and addresses
• Autonomous system (AS)
• Area border router (ABR)
• Neighbor routers
• Route maps
• Access lists
• Bi-directional forwarding detection (BFD)

For more details on a term as it applies to a dynamic routing protocol, see one of Border Gateway Protocol (BGP) on page 338, Routing Information Protocol (RIP) on page 300, or Open Shortest Path First (OSPF) on page 377.

 

Aggregated routes and addresses

Just as an aggregate interface combines multiple interfaces into one virtual interface, an aggregate route combines multiple routes into one. This reduces the amount of space those routes require in the routing tables of the routers along that route. The trade-off is a small amount of processing to aggregate and de-aggregate the routes at either end.

The benefit of this method is that you can combine many addresses into one, potentially reducing the routing table size immensely. The weakness of this method is if there are holes in the address range you are aggregating you need to decide if its better to break it into multiple ranges, or accept the possibility of failed routes to the missing addresses.

For information on aggregated routes in BGP, see Border Gateway Protocol (BGP) on page 338, and Border Gateway Protocol (BGP) on page 338.

 

To manually aggregate the range of IP addresses from 192.168.1.100 to 192.168.1.103

1. Convert the addresses to binary

192.168.1.100	=	11000000	10101000	00000001	01100100
192.168.1.101	=	11000000	10101000	00000001	01100101
192.168.1.102	=	11000000	10101000	00000001	01100110
192.168.1.103	=	11000000	10101000	00000001	01100111

 

2. Determine the maximum number of matching bits common to the addresses.

There are 30-bits in common, with only the last 2-bits being different.

 

3. Record the common part of the address.

11000000 10101000 00000001 0110010X = 192.168.1.100

 

4. For the netmask, assume all the bits in the netmask are 1 except those that are different which are 0.

11111111 11111111 11111111 11111100 = 255.255.255.252

 

5. Combine the common address bits and the netmask.

192.168.1.100/255.255.255.252

Alternately the IP mask may be written as a single number:

192.168.1.100/2

 

6. As required, set variables and attributes to declare the routes have been aggregated, and what router did the aggregating.

 

Autonomous system (AS)

An Autonomous System (AS) is one or more connected networks that use the same routing protocol, and appear to be a single unit to any externally connected networks. For example an ISP may have a number of customer networks connected to it, but to any networks connected externally to the ISP it appears as one system or AS. An AS may also be referred to as a routing domain.

It should be noted that while OSPF routing takes place within one AS, the only part of OSPF that deals with the AS is the AS border router (ASBR).

There are multiple types of AS defined by how they are connected to other ASes. A multihomed AS is connected to at least two other ASes and has the benefit of redundancy — if one of those ASes goes down, your AS can still reach the Internet through its other connection. A stub AS only has one connection, and can be useful in specific configurations where limited access is desirable.

Each AS has a number assigned to it, known as an ASN. In an internal network, you can assign any ASN you like (a private AS number), but for networks connected to the Internet (public AS) you need to have an officially registered ASN from Internet Assigned Numbers Authority (IANA). ASNs from 1 to 64,511 are designated for public use.

NAs of January 2010, AS numbers are 4 bytes long instead of the former 2 bytes.

RFC 4893 introduced 32-bit ASNs, which FortiGate units support for BGP and OSPF.

 

Do you need your own AS?

The main factors in deciding if you need your own AS or if you should be part of someone else’s are:

• exchanging external routing information
• many prefixes should exist in one AS as long as they use the same routing policy
• when you use a different routing protocol than your border gateway peers (for example your ISP uses BGP, and you use OSPF)
• connected to multiple other AS (multi-homed)

You should not create an AS for each prefix on your network. Neither should you be forced into an AS just so someone else can make AS-based policy decisions on your traffic.

There can be only one AS for any prefix on the Internet. This is to prevent routing issues.

Choosing a routing protocol

One of that hardest decisions in routing can be choosing which routing protocol to use on your network. It can be easy to decide when static routing will not meet your needs, but how can you tell which dynamic routing protocol is best for your network and situation?

Here is a brief look at the routing protocols including their strongest and weakest points. The steps to choosing your routing protocol are:

1. Answer questions about your network

2. Evaluate your chosen protocol

3. Implement your dynamic routing protocol

 

Answer questions about your network

Before you can decide what is best for your situation, you need to examine what the details of your situation are such as what you have for budget, equipment, and users.

The following questions will help you form a clear idea of your routing needs:

 

How many computers or devices are on your network?

It matters if you only have a few computers, or if you have many and if they are all at one location or not as well. All routing protocols can be run on any sized network, however it can be inefficient to run some on very small networks. However, routers and network hardware that support dynamic routing can be more expensive than more generic routers for static routing.

 

What applications typically run over the network?

Finding out what application your users are running will help you determine their needs and the needs of the network regarding bandwidth, quality of service, and other such issues.

 

What level of service do the users expect from the network?

Different network users have different expectations of the network. Its not critical for someone surfing the Internet to have 100% uptime, but it is required for a stock exchange network or a hospital.

 

Is there network expansion in your near future?

You may have a small network now, but if it will be growing quickly, you should plan for the expected size so you don’t have to chance technologies again down the road.

 

What routing protocols do your networks connect to?

This is most often how routing protocol decisions are made. You need to be able to communicate easily with your service provider and neighbors, so often people simply use what everyone else is using.

 

Is security a major concern?

Some routing protocols have levels of authentication and other security features built in. Others do not. If security is important to you, be aware of this.

 

What is your budget — both initial and maintenance?

More robust and feature laden routing protocols generally mean more resources are required to keep them working well. Also more secure configurations require still more resources. This includes both set up costs, as well as ongoing maintenance costs. Ignore these costs at the risk of having to drop the adoption of the new routing protocol mid-change.

 

Evaluate your chosen protocol

Once you have examined the features of the routing protocols listed above and chosen the one that best meets your needs, you can set up an evaluation or test install of that protocol.

The test install is generally set up in a sandbox configuration so it will not affect critical network traffic. The aim of the test install is to prove that it will work on a larger scale on your network. So be sure that the test install mirrors your larger network well enough for you to discover any problems. If its too simplistic, these problems may not appear.

If your chosen protocol does not meet your goals choose a different protocol and repeat the evaluation process until either a protocol meets your needs, or you change your criteria.

 

Implement your dynamic routing protocol

You have examined your needs, selected the best matching dynamic routing protocol, tested it, and now you are ready to implement it with confidence.

This guide will help you configure your FortiGate unit to support your chosen dynamic routing protocol. Refer to the various sections in this guide as needed during your implementation to help ensure a smooth transition. Examples for each protocol have been included to show proper configurations for different types of networks.