Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
j_a_m_e_s
New Contributor III

BGP Multihop across Fortigate

Dear All,

 

I would like to understand how the packet flow works for BGP multihop through a firewall (i.e. how does the middle device in the multi-hop know what to do?). I realise the two devices either side of the firewall will dynamically learn the correct routes, but how can the firewall itself know where to write the packets it receives? It is really a case of configuring static routes on the FGT?

 

I have attached a diagram to help explain my question.

 

Many thanks in advance for any assistance.

 

Regards

 

James.

8 REPLIES 8
Toshi_Esumi
SuperUser
SuperUser

All middle devices sit between two iBGP peers just need to route BGP unicast packets from one side to the other. They just need to know which interface to route to based on the destination IP. If it's a FW like FGT, you just need to let it route without NAT in a pair of policies for both directions.

In your case 10.0.0.1 needs to see the source IP 192.168.0.1, and vice versa. Since they're directly connected to the FGT, you don't need to have any additional routes. Both /31 routes are already in the routing-table as directly connected routes.

j_a_m_e_s

Hi Toshi What about the other packet flows, in my example a packet from 10.99.0.1 to 10.99.100.1? If the FGT itself is not a BGP speaker how will it know which egress interface to route through? Regards James
j_a_m_e_s
New Contributor III

I guess the answer is that it won't work without static routes on the FGT, and that's simply not a scalable solution - I'm planning to have around 20 - 30 vdoms with the same route peering running though. 

 

Does anyone know whether virtual wirepairs might work? The trust/untrust interfaces would have a sub-interface for each vdom. Or is there some limitation where VWPs don't work with sub-interfaces?

Toshi_Esumi

If the FGT has a root vdom aggregating multiple tenant vdoms and an router in the upstream for the intnet, I would break it into two sections router<->root vdom, root vdom<->tenant vdoms, then set eBGP between them. With this way, each is a single hop and can learn all routes from the other vdoms via root vdom.

emnoc
Esteemed Contributor III

You wanted a stacked meshed vdom similar to the example within , but for ease you can do router bgp vrs static

http://socpuppet.blogspot.com/2014/09/a-stacked-vdom-concept-with-fortigate.html

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
j_a_m_e_s
New Contributor III

Thank you so much for the stacked-vdom suggestion. I wonder if there is a smart way to distribute routes between the VDOMs? My current thinking is to run a route-reflector on the root vdom.

 

Regards

James.

emnoc
Esteemed Contributor III

A RT reflector is for iBGP. iBGP by its self carries routes inject by eBGP peers. You need a route-reflector if you do not want to full mesh your iBGP peers. Not sure what you mean by redistribution.

Ken Felix

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
j_a_m_e_s
New Contributor III

Hi Ken,

 

Firstly thanks again for the stacked vdom suggestion and link, I do think this is the best option. The reason I mentioned a route-reflector is that I'm looking for a way (using iBGP) of getting routes from the normal vdoms to be known within the root vdom - the root vdom would be the route-reflector server. In your example, you used a static, but I would prefer iBGP. Presumably there is no problem running iBGP across the virtual links? Since the switches at either side of the FW use the same AS number, I believe we'll need a route-reflector because iBGP won't announce routes learned from another iBGP neighbor to upstream iBGP peers (the "full mesh" requirement)?

 

The background here is that I have an EVPN network with the FGT acting as an inter-vrf segmentation firewall (i.e. the firewall allows the traffic to hop VRF to exit the fabric via a default route). The reason for BGP is than EVPN requires it so I wouldn't need to redistribute into OSPF at any point. Your stacked approach would potentially allow N+1 external peerings, whereas the non-stacked approach would involve N*2 external peerings (where N is the quantity of VRFs on the fabric).

 

Thanks for your time.

 

James.

 

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors