Verifying traffic routing
Traffic may be reaching the internal network, but it may be using a different route than you think to get there. Use a browser to try and access the Internet.
If needed, allow traceroute and other diag ports to be opened until things are working properly. Then remove access for them again.
Look for slow hops on the traceroute, or pings to a location, as they may indicate network loops that need to be fixed.
Any locations that have an unresolved traceroute or ping must be examined and fixed. Use network packet sniffing to ensure traffic is being routed as you expect.
Verifying the dual-homed side of the configuration
Since there are two connections to the Internet in this example, theoretically you can pull the plug on one of the ISP connections, and all traffic will go through the other connection. Alternately, you may choose to remove a default route to one ISP, remove that ISP’s neighbor settings, or change the weightings to prefer other other ISP. These alternate ways to test dual-homing do not change physical cabling, which may be preferred in some situations.
If this does not work as expected, things to check include:
- Default static routes — If these are wrong or don’t exist, the traffic can’t get out.
- BGP neighbor information — If the ISP router information is incorrect, the FortiGate unit won’t be able to talk to it.
Redistributing and blocking routes in BGP
During normal BGP operation, peer routers redistribute routes from each other. However, in some specific situations it may be best to not advertise routes from one peer, such as if the peer is redundant with another peer (they share the same routes exactly), if it might be unreliable in some way, or some other reason. The FortiGate can also take routes it learns from other protocols and advertise them in BGP, for example OSPF or RIP. If your Company hosts its own web or email servers, external locations will require routes to your networks to reach those services.
In this example the Company has an internal network in an OSPF area, and is connected to a BGP AS and two BGP peers. Company goes through these two peers to reach the Internet. However, Peer 1 routes will not be advertised to Peer 2. The Company internal user and server networks are running OSPF, and will redistribute those routes to BGP so external locations can reach the web and email servers.
This section includes the following topics:
- Network layout and assumptions
- Configuring the FortiGate unit
- Testing network configuration
Network layout and assumptions
The network layout for the BGP redistributing routes example involves the company network being connected to two BGP peers as shown below. In this configuration the FortiGate unit is the BGP border router between the Company AS, and the peer routers.
The components of the layout include:
- There is only one BGP AS in this example — AS 65001, shared by the FortiGate unit and both peers.
- The Company’s FortiGate unit connects to the Internet through two BGP peers.
- The Company internal networks on the dmz interface of the FortiGate unit with an IP of 10.11.201.0/24.
- The FortiGate units’ interfaces are connected as follows:
- port1 (dmz) has IP 10.11.201.110 and is the internal user and server network
- port2 (external1) has IP 172.21.111.4 and is connected to Peer 1’s network
- port3 (external2) has IP 172.22.222.4 and is connected to Peer 2’s network
- Peer 1 has IP 172.21.111.5, and Peer 2 has IP 172.22.222.5.
- OSPF Area 1 is configured on the dmz interface of the FortiGate unit, and is the routing protocol used by the internal users and servers.
BGP network topology
Assumptions
The the BGP redistributing routes configuration procedure follows these assumptions:
- The FortiGate unit has been configured following the Install Guide
- Interfaces port1, port2, and port 3 exist on the FortiGate unit
- We don’t know the router manufacturers of Peer 1 and Peer 2
- We don’t know what other devices are on the BGP AS or OSPF Area
- All basic configuration can be completed in both GUI and CLI
- Access lists and route maps will only be configured in CLI
- VDOMs are not enabled on the FortiGate unit
Hi Mike,
if i configure the following on fortigate1:
config router bgp
set as 65000
set router-id 10.2.2.254
config neighbor
edit “10.2.2.253”
set next-hop-self enable
set remote-as 65000
set send-community6 disable
next
config redistribute “static”
set status enable
end
fortigate2 should get the default route 0.0.0.0 0.0.0.0 from fortigate1 as it is static ?
how can i redistribute the default route(fortigate1) to fortigate2 ?
thanks
regards
There is a really good KB article that explains how to do this. You can find it here
If you want to redistribute static routes you would enable the following
config router bgp
config redistribute static
set status enable
end
end
An example of the config would be like this
config router prefix-list
edit “only_dflt”
config rule
edit 1
set prefix 0.0.0.0 0.0.0.0
unset ge
unset le
next
end
next
end
config router route-map
edit “only_default_route”
config rule
edit 1
set match-ip-address “only_dflt”
next
end
next
end
config router bgp
set as 2
config neighbor
edit 10.142.0.110
set remote-as 1
set route-map-in “only_default_route”
next
end
set router-id 10.142.0.205
end
Let me know if this helped answer your question!
Thanks!
Hi,
thanks for the link and example, got it working!
Regards
Awesome to hear Piccolo!
config router bgp
set as 65041
set router-id 162.53.156.138
config neighbor
edit “10.104.55.1”
set ebgp-enforce-multihop enable
set soft-reconfiguration enable
set remote-as 64699
set send-community6 disable
next
edit “10.104.55.2”
set ebgp-enforce-multihop enable
set soft-reconfiguration enable
set remote-as 64699
set send-community6 disable
next
i am trying to accomplish above but i can see only one neighbour is establish and other is in ACTIVE state…
So you see both neighbors but only one is active?