BGP Multiple ISP VR Requirements

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

BGP Multiple ISP VR Requirements

L2 Linker

I'm attempting to wrap my head around a very critical piece of setting up BGP between 2 ISP's concerning how many Virtual Routers are required.

 

I currently have 1 ISP (A) up and running on BGP just fine and my other ISP (B) will be converted to BGP on Monday.  Both will be advertising my public IP space from ARIN.

 

So my question is, do I put both ISP A's and ISP B's interfaces on the same VR or do they need to be on their own separate VR's?

 

I'm receiving a few conflicted answers to this question, so I'm looking for real world experience.

 

Currently I'm still a strong believer in that I need to just add my ISP B as its own Peer Group to my current primary Virtual Router, add ISP B's own subinterface to the Resdistribution Profile along with ISP A's subinterface, configure a new Import Rule for ISP B plus an Export Rule with a Prepend of 2 if I choose to, and finally check ECMP for "load balancing".

 

All this sounded great until I was told the following from a Palo rep: "Two interfaces ( belonging to same VR ) cannot have IP addresses from the same subnet. x.x.x.x/24"

 

That threw a wrench into my whole thought process because both ISP's are advertising my /24 from ARIN, but are physically connected with 2 different /30's to each ISP's switch.

20 REPLIES 20


@RFalconer wrote:

In the Redist Rules, did you ever try with just entering your public space subnet instead of referencing the redistribution profile?

As long as there is an entry for the public space in the routing table of the PA, this should work fine. Having a subinterface on the ARIN assigned network will satisfy this or you can create a dummy route, sort of like routing a prefix to null0 on a router.

 


Was just wondering how you would set that up on the firewall?

Here's an example.

The direct connection to the isp is a /30, 10.1.1.2/30.

Your public IP space is 128.1.1.0/24 (This doesn't have to be BGP advertised. It can just be another subnet that the ISP has assigned to you that they route to 10.1.1.2)

Create a static route for 128.1.1.0/24. I usually set the interface to the untrust and the next hop to 'None'

 

By creating this static route, it puts the prefix in the routing table. BGP will only advertise prefixes that exist in the routing table. Also, when NAT statements are created for the public subnet, an entry for this public network must exist in the routing table or the processing of the traffic will fail.

Check out page 4 on this doc: 

https://live.paloaltonetworks.com/twzvq79624/attachments/twzvq79624/learning_tkb/189/2/DOC-1628.pdf

A forwarding lookup is done before NAT is even processed. If the destination doesn't exist, then traffic is discarded before it even gets to the NAT lookup. By having a route to null0, the prefix exists and the flow continues. 

From my testing, a static route isn't even needed when you specify the /24 subnet in the Redistribution tab instead of using a Redistribution Profile.

 

Thanks for the tip.

That's correct.

Have you tested passing traffic into the subnet you're advertising, using NAT rules bound to the interface on a different subnet? I've never been able to do this without either a loopback or a null route.

Can you provide details of what you are trying to accomplish?

 

I use bi-directional NAT rules to redirect different internal subnets to specific ranges of public IP addresses.

 

I do not bind any NAT rules to interfaces, but rather zones.

  • 9281 Views
  • 20 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!