I am new to BGP. I am attempting to configure BGP as layed out in the following documentation with the Active/Passive configuration. I've been given an AS number and a block of /24 from ARIN. Step 2 under "Configuration for the Active/Passive Pair" explains that there needs to be a 3rd interface configured with the internal network IP address/subnet. Is this the /24 that I was assigned? If so, I believe this is where my confusion surfaces. I have an interface that lives on a "routing subnet" that connects the firewall to the rest of the internal network (core switches). Does this 3rd interface, that I would put the /24 on, replace this "routing subnet" interface? Would I need to NAT traffic from the /24 to the routed subnet? Anybody willing to explain this or offer some help, I would greatly appreciate it. Thanks!
Solved! Go to Solution.
The document gives you an example where they are using 2 interfaces as external and 1 as internal interface. The /24 network you have configured should be assigned to your external interface as this will be a public ip address. You will need to figure out which interfaces should participate in BGP peering.
Thanks for the response. I still don't quite understand. If I use the /24 public IPs I've been assigned, on the external interfaces, how do I from a peer relationship with my ISP's routers, as the /24 IPs don't live on their network. My assumption was that the external interfaces would be configured with the IPs my ISP has given me so each respective interface lives on the ISP's networks, and I would configure an internal interface with the /24. So, traffic destined for my /24 from the internet would be routed via one of the ISPs peer routers (because of the BGP route advertisements) to my firewall, then switched over to the /24 interface configured internally, and translated via NAT and passed on the the local network. Is my assumption wrong? Thanks again.
You have the correct idea. If you are new to BGP, it sounds like you are needing to set up a multihomed ISP edge. 'Kbrazil' put together a really good PDF on the different designs that are possible.
Please reference this post:
Your main job to deploying the edge is to correctly route your company's public traffic to and from your ASN:
a) Announce your ASN to the Internet via one or more BGP-peered ISPs. (This is so that external, ingress traffic knows how to reach services that you'll publish on your ASN, that is, your allocated public /24 subnet)
b) Peer to one or more ISPs and receive BGP tables (routes). (This is so that internal, egress traffic can route to the correct Internet destination via the best AS path)
So to answer your original post, the BGP edge design you choose will dictate how the interfaces will be configured on the PANs, since there are a bunch of different ways depending on what you're trying to accomplish.
The main questions that you need to answer:
a) how many ISPs you want to peer to (via BGP, we assume)
b) if you have a single or pair of PAN firewall(s)
c) active/passive or active/active cluster configuration (if a pair)
d) BGP tables passed to you from each ISP:
You will need to collaborate with your ISPs to provide one of the following BGP table options (the same option for all ISPs)
i) Full Internet tables (you'll need to verify your PANs support this, and your BGP speakers (the PANs) cannot flap -unless the ISPs configure hold down timers (dampening) on your AS announcement to
prevent flapping BGP propagation)
ii) Partial tables with a default route (best method)
iii) Default route only
Once you've identified the above questions, post them here and we can define how you'll configure the various public and private networks on the PAN interfaces.
As a summary, your ISPs will each mostly likely give you a /30 public subnet that you will peer to them via BGP using 'external' interfaces. Then you will place your public AS /24 subnet on your PAN routing table, either with a static route, or locally connected on a interface (or preferably both-using metrics- for stability). Finally, you'll configure BGP to announce your ASN to each peer and implement BGP filter/export lists applied outbound toward each ISP to prevent transient routing between your ISPs (and so will they). You'll also need a metric of some type that will default or load balance internal, egress traffic, for example a filter/import list that applies a higher weight to one of the ISPs default route. The rest of your private networks can be configured on 'internal' interfaces, and your publicly published services (www, dns, mail etc) from those interface(s), (DMZ etc) can be NAT published to the public AS /24 subnet, which will then require a matching public DNS record to resolve each NAT'd service to the corresponding public IP.
Thanks a ton for your response. It was extremely helpful.
To answer your questions:
a) We have two ISPs we want to peer with.
b) We have a pair of PA500s. They're both setup with HA and tested and confirmed working.
c) Active/Passive configuration
d) As of right now we're only going to do default routes (if we decide we need full routing tables down the road we'll use a pair of Cisco 3925e routers)
We've been thinking of taking our /24 (the network we'll advertise via BGP) and cutting it down to a /27 and assigning that it's own interface on the PA. That interface will then connect to a newly created VLAN on our core switches where we can plug in other "internet" facing devices that we would like to have highly available using BGP. We also have an interface configured with a subnet we use to route traffic to our core switches. The core switches then have dozens of other VLANs and the network spreads out from there. Will BGP still provide internet redundancy to this (private) network between my two ISPs even though they don't live on the /27 (or /24) or does it have to live on that network or route traffic from it somehow?
Here are some screenshots of my partial configuration:
Attached is a example diagram for you. Study it and the design should start to come together for you...
The diagram is based on a production deployment that I implemented using almost identical criteria as you provided in answer to the questions, so I know this works flawlessly.
One suggestion I have is, in addition to a default route, it's best to have each ISP advertise their owned prefixes, since you are peering to them anyway. This will allow your ASN the most efficient outbound routing.
You do not want the ISPs directly connected prefixes, because ASNs in your local geography may also be multihomed to the same ISPs as your company. You can verify this by comparing a list of the BGP tables each ISP will send you, and if any of the subnets overlap that would indicate such.
In reply to your comments about the interface configuration of your public /24 subnet, there is really no need to physically configure it on a firewall interface. To announce your ASN, you can simply configure a static route with a next hop of "non", and then you will create a static Redistribution Profile for that static route and add it to BGP>Redistrib Rules tab in the VR.
And far as supernetting your AS /24 to a /27, remember that BGP will require the /24 present in the routing table to advertise it, otherwise you will need to aggregate as a classful subnet somehow in the redistribution. I would need to study how to do that so I can't suggest how right now, nor can I think of a need for you to do that anyway...
You don't need to place any hosts that will be publicly published directly on your /24 AS subnet. They can reside in private subnets on your internal interfaces protected by the firewalls. For example, we used a DMZ zone with its own AD domain that host our public services (www, dns, exchange edge servers, etc). To publish those hosts, you will create a public DNS record, a public-to-private NAT and the required security policies to allow the traffic from the public to private zones which are configured on those various external and internal interfaces.
Im not sure what you mean by "highly available using BGP"?
When I have more time I will put together a screenshots of the BGP configuration
Missouririver, wow! This is exactly the information I was looking for. Very very informative! Thanks a ton for the diagram and explanation.
I do have a couple more questions, however, if you don't mind. First of all, if I don't need a physical interface configured with the /24 subnet, then what is the purpose of having it? Just to advertise it to my peer routers? If that's the case why do I need so many IPs to do that?
Second, in regards to creating a static redistribution profile for the static route. Instead of using the type "connect" I would use "static" instead, correct? Do I leave the interface blank since I don't need the /24 configured on a firewall interface?
Screenshots of the BGP configuration would help immensely too.
As far as configuring a physical interface with the public /24, some would debate whether to do so or not. I have seen where some architects/engineers will place the publicly published hosts directly on the /24 subnet (which is configured on a physical interface). Personally I see no need to do that, and would prefer to hide published hosts behind a NAT and the firewall. I'm sure there are various designs which work well too. Sometimes it's handy to have a physical port on your CE or CPE devices to uplink a laptop for example, directly on your /24 public subnet, for performing penetration testing or traffic simulaiton etc. which is sourced externally of your firewalls. In that case you can configure a spare interface on the PANs with you public subnet, but be careful what public IPs the PANs learn via that interface, so that published traffic doesn't blackhole traffic to that interface. You will also have to evaluate how this affects the requirements of pre-NAT source on the routing table.
The purpose of having the public /24, is one of your ISPs most likely assigned you a /24 from their owned prefixes. Because you are obtaining a commercial ISP circuit, its easiest for them to require you to peer via BGP. Therefore, the /24 was most likely assigned to you because commercial BGP requires no less than a /24 per public eBGP speaker to keep Internet routing tables manageable. In essence, you secured a public /24, (which is quite difficult anymore) and you have a lot of flexibility to publish your public services at least while IPv4 is around :smileywink:.
For the high availability of your public services that you mentioned earlier, now what you can do is to throw a ADC (I recommend a F5 LTM) on a PAN interface, and publish each public IP/service from the ADC. The ADC will then load balance on the backend (routed through the PAN firewalls security) to your configured pool of servers for each published service.
Correct. You would use a "connect" for the Redist profile, and leave the interface blank. I'm working on a screenshot thing...need some more free time :smileyhappy:
So, I've turned up BGP with both ISPs. Right now our inbound traffic destined to our advertised /24 is coming in through our secondary ISP. We want it to all come through our primary ISP except in the case of primary ISP failure. I've fiddled around with the import configurations but I haven't been able to figure it out. What's the best way to do this?
Also, is it okay to leave our PBF (primary ISP route) and static route (secondary ISP route) rules in place for outbound traffic and just rely on BGP for inbound traffic?
I followed the documentation in this article but it isn't working for me. A simple traceroute from outside the network shows our traffic is going over our secondary ISP (Integra). I prepended the ASN 4 times for the secondary ISP export rule. I also changed the local preference under import rules to 500 for primary ISP (Veracity). Any ideas where I may have gone wrong? Attached are some screenshots of my configs.
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 Live Community as a whole!
The Live Community thanks you for your participation!