Community discussions

MikroTik App
 
User avatar
burningbee
just joined
Topic Author
Posts: 13
Joined: Sat Aug 15, 2015 7:42 pm
Contact:

IXP only traffic

Wed Nov 29, 2023 10:16 pm

My setup is as follows
- CCR2216 peering with local exchange for local traffic (CDNs)
- Same CCR2216 peering with an IP Transit provider for non-local traffic


Some of the IXP traffic includes
- Meta
- Google
- Amazon
- Microsoft
- Netflix
- Akamai


I would like to push routes from the exchange to my downstream BGP clients without it failing over to the IP Transit provider when traffic goes down in the exchange. E.g. if Google goes down in the exchange, my downstream clients lose Google prefixes and do not pick them up from the IP transit provider
 
User avatar
netzwerghh
Frequent Visitor
Frequent Visitor
Posts: 75
Joined: Sun Aug 07, 2011 4:23 pm
Location: Hamburg, DE
Contact:

Re: IXP only traffic

Thu Nov 30, 2023 8:02 pm

You should use filters on incoming prefixes to assign self defined communities to the prefixes. So you could tag all prefeixes learned at an IXP with your "IXP community" and all prefiexes learned from your upstream with your "upstream community". Then you can define a filter to your customers that filters all prefixes tagged with "upstream community".
You can tag each prefix with multiple communites. In our network there are communities for type of prefix (own, customer, peering, upstream), each upstream provider get's it's own community. There is also a community for every IXP we are peering at and a community for the city where the prefix is learned. This gives as the possibility for fine grained filtering. This also helps us to not become transit for our upstreams or peerings.

If you have a 32bit ASN you shoul use large or extended communities.
 
alex_rhys-hurn
Member
Member
Posts: 353
Joined: Mon Jun 05, 2006 8:26 pm
Location: Kenya
Contact:

Re: IXP only traffic

Fri Dec 01, 2023 3:27 pm

Your post about communities was very illuminating for me, but reading the myManga post further, he is trying to handle a failover scenario as well.

The reality is that if your IXP goes down (I know what happened to the DC you use the other night BTW) then the routes you send to your customers will need to change.

It may be interesting to use a Route Reflector with BFD between your peering router and your RR. So your RR would hold all the routes both from the IPT and from the IXP and because of shortest AS Path the IXP will be preferrred, but when IXP goes down BFD will kill those routes quickly leaving only the remaining IXP routes available.

I am a beginner in BGP too, so thats my Idea, I would lover other gurus to comment, as I am on the same journey as MyManga.

Cheers,

Alex
 
User avatar
burningbee
just joined
Topic Author
Posts: 13
Joined: Sat Aug 15, 2015 7:42 pm
Contact:

Re: IXP only traffic

Sat Dec 02, 2023 12:38 pm

You should use filters on incoming prefixes to assign self defined communities to the prefixes. So you could tag all prefeixes learned at an IXP with your "IXP community" and all prefiexes learned from your upstream with your "upstream community". Then you can define a filter to your customers that filters all prefixes tagged with "upstream community".
You can tag each prefix with multiple communites. In our network there are communities for type of prefix (own, customer, peering, upstream), each upstream provider get's it's own community. There is also a community for every IXP we are peering at and a community for the city where the prefix is learned. This gives as the possibility for fine grained filtering. This also helps us to not become transit for our upstreams or peerings.

If you have a 32bit ASN you shoul use large or extended communities.
Thank you for this. Trying it out this weekend. Will give feedback when done

NB: A lot of us (like me :D ) in the industry are learning as we go
 
User avatar
netzwerghh
Frequent Visitor
Frequent Visitor
Posts: 75
Joined: Sun Aug 07, 2011 4:23 pm
Location: Hamburg, DE
Contact:

Re: IXP only traffic

Sat Dec 02, 2023 1:37 pm

Good to hear.

We are using large communities. We tag incoming routes this way: own-as:information-id:value

Example:
Say our AS is 65536

We use following information types:
40: Country
40:1 Germany
40:2 Netherlands

41: City
41:1 Frankfurt
41:2 Amsterdam

42: Internet-Exchange
42:1 De-CIX FRA
42:2 AMS-IX

48: Upstream Provider
48:1 Upstream 1 (Might be Arelion)
48:2 Upstream 2 (Might be Level3)

49: Peering-Type
49:1 Customer
49:2 Transit/Upstream
49:3 IXP-Peer
49:4 PNI-Peer

So a route learned at AMS-IX will get:
append bgp-large-communities 65536:40:2,65536:41:2,65536:42:2,65536:49:3;

Or a route learned from an upstream in Frankfurt will get:
append bgp-large-communities 65536:40:1,65536:41:1,65536:49:2,65536:48:1;

So when you announce routes to a customer that should only get IXP routes, you can let only routes pass, that have the community 65536:49:3 and filter out all other routes.
Likewise to your upstream and IXP peers you can filter all routes but those that are your own and those tagged with community 65536:49:1

You can even filter by a certain IXP if you are at different IXPs or only those routes from a certrain upstream.


For learning, I can recommend you this book: "BGP (Border Gateway Protocol): from theory to practice" https://www.amazon.de/dp/B0CMV2Q2GJ?psc ... ct_details
It's mainly Cisco and Juniper. But you should be able to adopt the concepts to Mikrotik. And if you can't Mikrotik should fix their BGP implementation :)
 
User avatar
burningbee
just joined
Topic Author
Posts: 13
Joined: Sat Aug 15, 2015 7:42 pm
Contact:

Re: IXP only traffic

Sat Dec 02, 2023 5:31 pm

Your post about communities was very illuminating for me, but reading the myManga post further, he is trying to handle a failover scenario as well.

The reality is that if your IXP goes down (I know what happened to the DC you use the other night BTW) then the routes you send to your customers will need to change.

It may be interesting to use a Route Reflector with BFD between your peering router and your RR. So your RR would hold all the routes both from the IPT and from the IXP and because of shortest AS Path the IXP will be preferrred, but when IXP goes down BFD will kill those routes quickly leaving only the remaining IXP routes available.

I am a beginner in BGP too, so thats my Idea, I would lover other gurus to comment, as I am on the same journey as MyManga.

Cheers,

Alex
The failover is phase two once this is done. I don't want it automatic, that's how it is at the moment. My IP Transit pipe is more expensive and smaller. I want to manually enable/disable filters to allow this. I'm trying to get fine-grained control over all my traffic. I've been losing traffic, mostly google as they do their upgrades from 10G lags to 100G, and I would rather have the google traffic down, than saturate mu uplink pipe
 
User avatar
ahmdzaki18
just joined
Posts: 12
Joined: Fri Oct 06, 2023 7:52 pm
Location: Jakarta, Indonesia
Contact:

Re: IXP only traffic

Sat Dec 02, 2023 11:54 pm

Use combine with filter in tag community and local preference will works. We also using it and transiting our cdn, ggc, ixp to our downstreams. Will happy to help you. Reach me out :)
 
User avatar
burningbee
just joined
Topic Author
Posts: 13
Joined: Sat Aug 15, 2015 7:42 pm
Contact:

Re: IXP only traffic

Sun Dec 03, 2023 2:39 pm

Good to hear.

We are using large communities. We tag incoming routes this way: own-as:information-id:value

Example:
Say our AS is 65536

We use following information types:
40: Country
40:1 Germany
40:2 Netherlands

41: City
41:1 Frankfurt
41:2 Amsterdam

42: Internet-Exchange
42:1 De-CIX FRA
42:2 AMS-IX

48: Upstream Provider
48:1 Upstream 1 (Might be Arelion)
48:2 Upstream 2 (Might be Level3)

49: Peering-Type
49:1 Customer
49:2 Transit/Upstream
49:3 IXP-Peer
49:4 PNI-Peer

So a route learned at AMS-IX will get:
append bgp-large-communities 65536:40:2,65536:41:2,65536:42:2,65536:49:3;

Or a route learned from an upstream in Frankfurt will get:
append bgp-large-communities 65536:40:1,65536:41:1,65536:49:2,65536:48:1;

So when you announce routes to a customer that should only get IXP routes, you can let only routes pass, that have the community 65536:49:3 and filter out all other routes.
Likewise to your upstream and IXP peers you can filter all routes but those that are your own and those tagged with community 65536:49:1

You can even filter by a certain IXP if you are at different IXPs or only those routes from a certrain upstream.


For learning, I can recommend you this book: "BGP (Border Gateway Protocol): from theory to practice" https://www.amazon.de/dp/B0CMV2Q2GJ?psc ... ct_details
It's mainly Cisco and Juniper. But you should be able to adopt the concepts to Mikrotik. And if you can't Mikrotik should fix their BGP implementation :)
This is probably the best reply I have ever gotten to a question in this forum. Specific to the point. Thank you. I never knew you could go 3 levels into a BGP community. I am trying to figure out the not-so-new, but different way of writing filters in ROS7. Care to share an example? Most examples I am coming across are from ROS6**

Who is online

Users browsing this forum: No registered users and 5 guests