BGP Multihop across Fortigate

[j_a_m_e_s]

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.

[Toshi_Esumi]

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]

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]

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

[j_a_m_e_s]

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]

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

[j_a_m_e_s]

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.