Monthly Archives: April 2014

Fortinet BGP local Preference to influence outbound routing

Fortinet like all vendors supports BGP and has many ways to configure it. In this case almost all settings are configured VIA the CLI. In this post I will show how to configure the Local preference attribute to influence what routes a device will take to leave the network. For example, if you have two ISPs, and we use one for primary, and the second for a backup then we would want to change the local preference to make ISP 1 more a better choice.

Changing the local preference of routes from the default 100, to a higher value makes those routes the best choice when leaving the network. Also you can use a prefix-list to change just the preference of one or more routes, you do not have to do all routes advertised by the neighbor.

Steps needed are:

– Get BGP instance configured

– Configure neighbors

– Create route map

– assign preference in Route map

– Apply route map to neighbor

– Clear BGP routes, and check new preferences.


After you get BGP configured VIA CLI or GUI we can start with creating the route map.


You can name the Route map whatever you like, for example if you have two ISPs, you might say ISP-1-Local-Pref. Then modify the rule you want, and change the local preference. Remember the higher the local preference the more preferred.


config router route-map

edit name

config rule

edit 10

set local-preference X


Next we can apply the route-map to the neighbor we want to set preference on.


Once that is configured, we can check the perfernce of the routes with the command:

get router info bgp networks

You might notice that the preference has not changed. This is because we will need to clear the routes first. We can do this with a few different commands:

exe router clear bgp ip x.x.x.x out

This will clear all routes from this neighbor. If this is a live production network, it would be better to run the command:

exe router clear bgp ip x.x.x.x soft out

A soft reset uses stored prefix information to reconfigure and activate BGP routing tables without tearing down existing peering sessions. Soft reconfiguration uses stored update information, at the cost of additional memory for storing the updates, to allow you to apply new BGP policy without disrupting the network. Soft reconfiguration can be configured for inbound or outbound sessions.

Thats it! now we should see the new preference associated with our routes:


Notice the 500 instead of the default of 100. Everything is working, now all my routes going to the network will take the neighbor. Also notice the > symbol. This means it is the best route, and therefore the one put into the routing table. Other routes will not show up in the GUI routing table.

Fortigate BGP AS Path prepending is always the best place to get any Fortinet info.

Fortinet like most firewall vendors supports almost all Dynamic routing protocols. BGP is one, the GUI has simple to setup BGP options, but many do not exist in CLI, which might be for the best. In this post I will show how to create a Route-map and prepend the AS path influence ISP/neighbor routing.

First lets talk about why you would want to prepend an AS path. You would want to do this to influence how neighbors get to your routes. For example, if you had two ISPs, or neighbors and wanted to broadcast your routes to both neighbors, but wanted everyone to take neighbor 1 to get to your router, with a backup of Neighbor 2 you could prepend the AS path and make this happen.

BGP is a very deep protocol and there are many different ways to influence routing. Routers will always take the shortest AS path to get to its destination so that is the preferred method for this.


– Add BGP neighbors/networks – you can do this in GUI

– In CLI create route-map and use the commands to prepend YOUR AS path

– Assign Route-map to neighbor

– Clear BGP routes.


Create BGP in GUI.

This includes our AS number, the Neighbors and their AS numbers, and our networks we are advertising.


Route-map Creation

Lets then drop to CLI and create our Route-map



config router route-map

config “Name”  —- create route map

edit rule X — from there you can set your Prepend

set set-aspath “x x x “

set action permit — I did not add this in the image. Routes will be blocked if this is not added.


Assigning Route-map

Now lets assign the route map to our neighbor. Since we are wanting to control how routing will get to us, we will apply this route map to outgoing routes.


the command “set route-map-out” is what sets the route map on the outbound routes.

Last but not least, lets clear the IP routes so our prepend takes effect. You can do this through the command:

exe router clear bgp ip x.x.x.x out

This will clear all routes from this neighbor. If this is a live production network, it would be better to run the command:

exe router clear bgp ip x.x.x.x soft out

A soft reset uses stored prefix information to reconfigure and activate BGP routing tables without tearing down existing peering sessions. Soft reconfiguration uses stored update information, at the cost of additional memory for storing the updates, to allow you to apply new BGP policy without disrupting the network. Soft reconfiguration can be configured for inbound or outbound sessions.


So now we need to take a look at the routes we are sending out to see if our AS has actually be altered. After resetting the peer it might take a minute or two before this shows up correctly.


The command is:

get router info bgp neighbors x.x.x.x advertised-routes

That’s it!

Now we are controlling how devices will get to our networks in a Dual homed situation (two connections to ISPs). The querying devices will always take the lower AS path to get to its destination.

Fortigate TCP MSS

The maximum segment size (MSS) is the largest amount of data, specified in bytes, that a device can handle in a single non-fragmented piece. The MSS is essential in internet connections especially web surfing.

I once had a very crazy issue, where I could surf to almost all http websites, but many https sites such as, would not work. The header would come up, look like its working and .. nothing. After a few packet captures I noticed that it was fragmenting some of the https packets coming in.  The crazy thing is many websites worked perfect.

To troubleshoot I put a Cisco PIX I had laying around into production to replace the Fortigate. Everything worked no problem.

So after many hours researching, I changed the TCP-MSS to 1360 and boom, no issues.  I asked Fortinet support why this was happening in contrast to the Cisco PIX. They said that the cisco will automatically change its settings (I have not researched) but the Fortinet will not. Go figure.


So if you hear problems like : Can’t get to HTTPS sites , USPS will not load, Browser loads certificate but site does not come up. Check these commands:

In MR4:

config system interface

edit port X

set tcp-mss-sender 1360

set tcp-mss-receiver 1360



config system interface

edit port X

set tcp-mss 1350

Iperf for Bandwidth testing

Iperf is a great tool to test bandwidth on both UDP (connectionless) and TCP. Iperf does a great job of showing how much bandwidth it can push through the link between server and client, as well as delay and jitter of the UDP session. You can download it here:


default time it runs is 10 seconds, on port 5001 with a window size of 64k. All settings can be changed

Using Iperf

Using Iperf is simple, run one instance on a server (receiving client)  with the -s option and another instance on the testing client (sender) with the -c option.

On the server run:

iperf -s  – this will then start the server, listening to TCP port 5001 by default. You can change to any port you like. 

On the client run:

iperf -c x.x.x.x where x is the ip address of the listening server.

Thats it. Iperf will try to push as much traffic as it can with a 64k window size through TCP.

Images are below. Note, this was done on my local machine, so just replace with your test address.






Running a UDP test will usually result in higher bandwidth tests due to UDP not having any flow control mechanisms.

To use UDP instead of TCP use the switch -u.

Server: iperf -u -s

Client : iperf -u -c x.x.x.x






Notice, that the server has both Jitter and lost packets included. This could be very beneficial when troubleshooting link quality for VOIP.

More Bandwidth!

What if you want to completely saturate the link, full stress testing? you can use a combination of both the TCP window size (switch is -w), and parallel streams (Switch is -P ). I would recommend using a max window size of 1024k, and as lets say 7 Parallel streams (running at the same time).

Also, we can change when Iperf reports back to use , we will change it to 2 seconds (switch is -i). For laughs, lets also run  this from the default time of 10 seconds, to 30 seconds (Switch is -t). Here are the commands on both server and client:


iperf -w 1024k -P 8 -i 2 -t 30 -c


iperf -w 1024k  -s






Other Switches

Iperf has a lot important switches but here are a few I use a lot:

– B – Bind to a host/interface – Great to use if you have multiple IPs on the machine, and just want to test with one

– P – Runs more thread in parallel, can totally flood network with as much traffic as possible. Great for stress testing.

– D – used for testing both send and receive at the same time.

– i – how often iperf reports back to you about transfer

– t – amount of time iperf runs and sends data.

– w – Window size, can be specified in kb or mb.




Login to the Fortigate firewall with Active Directory accounts

Logging into the firewall with Active directory accounts can be a great thing. You can base login privileges on A.D. security groups, and track what the users do. For example if you had help desk users and only wanted them to only have read access, no problem. Also, what if you wanted to audit what a user does on the firewall, no problem. You can do this through a mix of Logins and admin profiles.

There are a few things we need to do, create the LDAP connection, create our security groups in A.D. to match in the firewall, create the user group in the FW and assign it the correct admin profiles.

1. Create the LDAP connection


You do not have to be a super user to query the LDAP account, I would just create a Fortinet service account, and use that to query with.

2. Create AD security groups. If you want domain admins to log in, great just match it in the firewall. If you have help desk users that you want to have restricted privilege than you would have to create that in A.D. and add the needed members.

3. Create local firewall groups that match the LDAP groups.


Here we create a “Firewall” Group, and add our remote server to the list. If you notice you can query LDAP from here, and select the group you want by clicking on the folder to the left side of the group name.

4. Add the group as a admin that can login

Under system – admin – administrators add a new admin.


Create the name you want, and select the group we just created. Then select the admin profile we want. This is for admins, so they will be super admins when they log in. If you wanted a custom profile, lets say restart the device, but that’s it then we can create that, then add it. There are more options here such as using Forti-token, and email.

Notice that the wildcard option is checked – A wildcard admin account is an administrator account with the wildcard option enabled. This option allows multiple different remote administration accounts to match one local administration account, avoiding the need to set up individual admin accounts on the FortiGate unit. Instead multiple LDAP admin accounts will all be able to use one FortiGate admin account.

5. Create a different admin profile for privileges.

In this example I will create a help desk account, that can only configure system settings (IP address, etc). Otherwise everything is read only.


After saving this, you can go back and add it to the admin group.

SNMPv3 on Ruckus 9.7

I was having some trouble getting SNMPv3 up and working on PRTG and Solarwinds. It was a straight forward config but something wasn’t working. The following steps will show how to configure SNMPv3 on Ruckus ZD, and pull info from it on PRTG. Why SNMPv3? it offers a lot of more features such as encryption and user authentication. Definition:

SNMP Version 3 (SNMPv3) adds security and remote configuration  capabilities to the previous versions. The SNMPv3 architecture  introduces the User-based Security Model (USM) for message security and  the View-based Access Control Model (VACM) for access control. The  architecture supports the concurrent use of different security, access  control, and message processing models. More specifically: Security

First we will configure the ZD

Enable the SNMPv3 agent, and create your user/pass/hash/encryption.


For some reason you have to have a R/W user in the ZD. This does not seem to be a requirement of v3.

Next lets configure PRTG, and find out where I made my mistake.


So everything is pretty straight forward, but I was putting admin in for my context name as well. This was breaking the connection.

The context name is a collection of management information accessible by an SNMP entity.  A context is identified by the snmpEngineID value of the entity hosting the management information (also called a contextEngineID) and a context name that identifies the specific context (also called a contextName).

That was it, everything worked fine after that.