BGP as Transit/IP Provider

RouterOS Forwarding Protocols
1

Hello All,

For years now I have been multi-homed with my own IP space. BGP setup was easy and I have not had to make very many changes except some filtering.

I now have a customer with their own AS that would like to purchase service from me. I’ve tested several setups in my lab however I’m unsure of what is the best way to accomplish this task.

The customer has a single /22 that they wish for me to advertise. Would it be proper for me just to advertise their /22 to both of my upstream providers or is there a better way to do this?

My other thought is to establish BGP session with customer. Accept only their /22 in this session and re-distribute the route to my providers. That way if their session goes down my router will automatically withdraw the route.

I’m good with most routing protocols however I’m not too familiar with BGP - especially when it comes to being a provider instead of customer.

Thank you in advance.

2

There are multiple ways to ‘skin this cat’…

a) If you are the only connection for the customer to the internet, then it does not matter if you ‘originate’ the routes via your router to your upstream, and do static IP to the customer or run bgp with your customer, if there is a problem on the customer connection then it is going to be down regardless.

b) If your customer is multi-homed, and you are one of the service providers, then you should do the following:-
a) Run BGP (or some form of routing protocol), setup appropriate filters to make sure the the customer route is not advertised to your upstream peers when the customer connection to you is down.
It is a common practice to do this via BGP, between yourself and customer (your customer may wish to get the full routing table from you …

b) setup filters to do the following:-
i) accept only the routes you need from the customer (protect your network from getting erroneous routes from your customer..
ii) send to the customer the routes as they need … (full table, or default route etc. )

iii) I suggest that you tag (an internal community) on the incoming prefixes from the customer … and use that along with a prefix list to advertise the routes to your peers…
(if you don’t do this, then it is possible to advertise your customer routes to your upstream, which you have learned from the 2nd upstream, while you connection to the customer is down…


Simple :slight_smile:

If you want specific examples do a search on the forums for my posts in regards to other bgp questions, and you will find the examples of the filters we use.

3

The deciding factor is whether the customer has their own ASN as well as the /22.
If they have no ASN, then they have been relying on their previous providers to originate routing for them, and switching to you just means that it’s now your turn to originate for them.

If they DO have an ASN, then they’re going to EXPECT you to run BGP with them because they’re almost certainly multi-homing.

If they originate the route themselves and peer BGP with you, here is the checklist:

Notify all of your upstream carriers of the additional /22 prefix that will be coming from your network so that they can update their routing filters / reverse path anti-spoofing filters. Once you have confirmation that both providers will accept packets with the /22 as the source address, and advertisements from your network for that /22 prefix, then you will need to update your outbound filters towards the providers so that customer /22 prefix-length 22-24 is allowed.

At this point, everything will work once the customer sends their route announcements to you.

You will need to establish with the customer whether they want default-only, partial routes, or full routes.
Create your outbound filters according to the customer’s request.

Create an inbound filter which allows only the customer’s /22 with prefix-length 22-24 from the customer. This way, they won’t be able to advertise Internet routes into your network.

Finally, build the neighbor in your BGP instance and apply the filters, and watch the session as it becomes active.

You may also need to redistribute the customer’s advertised prefixes into your OSPF as well so that your network will always use the direct connection to your customer, when available.

This is the basic setup. The more advanced and scalable way is to create a BGP community policy for your network (e.g. ASN:100 = internal routes, ASN:200 = customer routes, ASN:300 = peer routes, and ASN:400 = transit provider routes) and to apply communities to routes as you receive / originate them. Then you use the community strings as the primary criteria in your outbound filters.

4

Hello, I’m having a problem with this, because I’m advertising to my upstreams a prefix that my client is not advertising to me.

I think I’m advertising it because I have it accepted in the filters and it’s a prefix that appears in my full routing table.

How can I advertise it only if my client is advertising it to me?

Thanks! @faisali @ZeroByte

5

.

We have solved it by adding in the input filter (where we define the prefixes that we allow to our client) the parameters:

set-bgp-local-pref=300
set-distance=10

Then, in the output filters (where we announce the prefixes to our carriers), for the prefixes of our client, the parameter:

distance=10

6

I have a similar scenario, whereby my customer has his own prefix and ASN. I have created the filters and their prefix, do I have to specify their ASN anywhere on the filter? Because my upstream says they do not see the customers ASN and see the customers prefix through my ASN?

I have setup the BGP session with the customer, have an inbound filter so I only receive their prefix. I have the OSPF redistribute whereby the rest of my network can reach this customer directly.

7

I wouldn’t redistribute into OSPF for reachability. It would be better to build iBGP in your AS and then build a full table route reflector so that you can deploy a PE router to peer with customers.

Here is an example and the presentation I did last year:

https://mum.mikrotik.com/presentations/US19/presentation_6721_1554447941.pdf