Hi guys,
I have some BGP peers and some of those aren't IP transit but a local IXP, I would like to know how can I "tag" the prefixes and advertise only those prefixes (the ones from a specific BGP peer) to another BGP peer? Is bgp communities the right way to do this?

Thanks,

BGP communities is where my head goes initially. Alternatively and depending on your architecture filtering out routes you don't want repeated may be better either at ingress or egress.

BGP communities is where my head goes initially. Alternatively and depending on your architecture filtering out routes you don't want repeated may be better either at ingress or egress.

Hi, can you give some examples?
At the moment, my filters for a BGP client session look like this:

IN: OUT:

You would want ZZ-in to have something like set-bgp-communities=xxx:yyy (instead of "")

"" means wipe the communities of all received prefixes.

If you set it to xxx:yyy (where xxx is usually your ASN, and YYY is some value you choose which means "learned from peers") then you can make an out-filter for the other peer which has rules as follows:

1) action=accept bgp-communities=xxx:yyy
2) action=discard

If you also want to send your own originated prefixes (regardless of communities), then you would add another rule which accepts your prefixes, and place it before rule 2. (before or after rule 1 doesn't matter)
e.g.: action=accept prefix=192.0.2.0/24

More about the :yyy part of the community.... this number is arbitrary and you determine whatever you want this number to mean. So you could have something like this:
2000 = all IXC (if you peer with multiple IXC and want to offer all such routes to other peers)
2001 = IXC 1 (if you want to be able to match prefixes from IXC1 specifically)
2002 = IXC2 (same)
etc...

In such a case, you might make your in-filter for each IXC add two communities:
xxx:2000 and xxx:2001 (for IXC1 in this example)
again, xxx would typically be your own ASN.

You would want ZZ-in to have something like set-bgp-communities=xxx:yyy (instead of "")

"" means wipe the communities of all received prefixes.

If you set it to xxx:yyy (where xxx is usually your ASN, and YYY is some value you choose which means "learned from peers") then you can make an out-filter for the other peer which has rules as follows:

1) action=accept bgp-communities=xxx:yyy
2) action=discard

If you also want to send your own originated prefixes (regardless of communities), then you would add another rule which accepts your prefixes, and place it before rule 2. (before or after rule 1 doesn't matter)
e.g.: action=accept prefix=192.0.2.0/24

More about the :yyy part of the community.... this number is arbitrary and you determine whatever you want this number to mean. So you could have something like this:
2000 = all IXC (if you peer with multiple IXC and want to offer all such routes to other peers)
2001 = IXC 1 (if you want to be able to match prefixes from IXC1 specifically)
2002 = IXC2 (same)
etc...

In such a case, you might make your in-filter for each IXC add two communities:
xxx:2000 and xxx:2001 (for IXC1 in this example)
again, xxx would typically be your own ASN.

Ok, i understand that set-bgp-communities should set up on incoming filters from the operator with whom I have a BGP session?
At this moment i have:

SESION BGP WITH PEER: Incoming filtr:
Outgoing filtr:
when 1.2.3.4 is my PI prefix.
And now where to add the community to the prefixes coming from this session to only send them to the end client.

re-read my answer, as I've already explained 100% of what you need to do to accomplish your goal.

Your existing in-filter is basically two rules that do the same thing... rule 1 is a passthrough rule - meaning that it will perform the BGP-ACTION stuff on the prefix, but will not make any filtering decisions. Essentially rule 1 wipes the prefixes clean of prepend-path (useless in an in-filter, by the way) and wipes the communities off of all prefixes, and finally appends nothing to the empty community list.
I just wanted to point out a common thing people don't know about Winbox GUI behavior. Notice the difference in the above two rules? That drop-down doesn't just hide/unhide the input field, it actually activates it. When the drop-down is expanded, then the blank input actually means: "set the community to nothing" - if you want to leave communities alone, then you need to close the drop-down expander (like in the right window).

Your input filter can be as short as one rule:
1) action=accept bgp-set-communities=xxxx:yyyy (whatever community value you want to use to indicate "learned from Orange", usually xxxx = your ASN, and yyyy can be whatever value makes sense for you to use)
This accepts everything from Orange (basically, trusting them not to send you a bunch of wrong routes) and flags them with your chosen community.

If you want to be a little less trusting, then you could also put some discard rules on your input filter from Orange - e.g. reject a default prefix perhaps, reject bogons, etc - but that's up to you to decide what you need to do filter-wise. If you want to apply the community to all prefixes but also do filtering, then you can do it in two ways - make the first rule apply the community, but have action=passthrough (keep processing) or else put all of your discard rules first, and make the last rule be an accept rule with the "set-communities" bgp-action as well.

For your output filters, just make the chain accept prefixes with the community you used in the IN-filter, and discard all others. (that would be in the BGP tab, not the BGP Actions tab)

But the short answer to your question - "where do I put the rule to match this community?"....
This is where you would put the community match requirement. Any rule with that value set will only match prefixes which have the community xxxx:yyyy (communities have to be numbers, which is why the screenshot has the red warning text color).

In a nutshell, all fields in "Matchers" and in "BGP" must be true, in order for the Actions and BGP Actions to be done.

Thank you very much everything works well.
It worked yesterday after your suggestions, but I just checked it wrong. It seemed to me that I was getting too many prefixes, and they just came from the parent operator.

Hi ZeroByte,
I have a similar situation whereby I have 2 upstream providers, my public ip prefix is x.x.0.0/22

Upstream 1:
- I have 100Mbps
- Prefix advertised x.x.0.0/22

Upstream 2:
- I have 30Mbps
- Prefix advertised x.x.1.0/24

Now my Upstream 2 says the their peers can not reach us, therefore we should advertise full /22 with them, however we explained them that if we do that we get chocked on bandwidth as we only have 30Mbps with them.

They came up with a work around that we should tag their bgp communities and advertise x.x.0.0/24, x.x.2.0/24 and x.x.3.0/24 since x.x.1.0/24 is already advertised and we shouldn't touch that. So that it won't chock these x.x.0.0/24, x.x.2.0/24 and x.x.3.0/24 as tagging will ensure no traffic to/from internet

We tried different methods suggested in the forums, but whenever we apply it. The entire network switches to Upstream 2 and get chocked.

Also advise if we can have simultaneous outbound routes for the above 2 upstream providers, because we want to split our outbound traffic and not just use 1. Like load balancing 7:3

The reason you're seeing that behavior is quite obvious when you take a moment to consider what's happening.

ISP1 gets a single /22 prefix announced to it.
ISP2 gets 4 /24 prefixes announced to it.

The first rule of route selection is to choose the most specific match (the longest matching prefix) - so for any given IP address from your block, there will be 2 routes in the global BGP table that match it - the /22 via ISP1 and the /24 via ISP2. No amount of traffic engineering metrics / AS-prepends will fix this because those never even come into play. Metrics are all nothing but tie breakers.

I would recommend announcing the /22 into both ISPs and simply apply a few AS-prepends towards ISP2, or if they support communities that cause their network to prepend your prefix when announcing it to their other peers, that's something else to consider (especially if ISP2 also peers with ISP1 directly).

As for outbound traffic, you can easily tune the preference of any ISP by using local_preference. Unfortunately it will require something more granular than just applying a lower local_pref to ISP2 because doing so would pretty much put 100% of traffic going to ISP1 due to the fact that you're going to be getting mostly the same list of prefixes from both carriers. If you have two border routers, then you can get a little mileage from the fact that one of BGP's tie breakers is to prefer eBGP prefixes over iBGP ones (two routers would use iBGP to share routes). This comes later in the decision process than AS-PATH, so for many prefixes you're going to have same-length AS-PATHs. Traffic going to router1 as the default GW would go out ISP1, whereas traffic using R2 as the default GW would go out via ISP2 for those same destinations. Clearly-superior paths will go the same way in all cases, though.

If you can analyze your egress traffic well enough to know which remote ASNs are getting what amount of traffic, then you could bump local_pref based on destination ASN and get some balance.

In general though, I'd say that balancing asymmetric links to diverse carriers is a tough activity to engage in, and you should have same-sized pipes if possible.

Upon re-reading your post, though, I think my solution in your shoes would be to simply keep the x.x.1.0/24 prefix in place, and then also announce x.x.0.0/22 with an AS-PREPEND of about 5x.