Community discussions

MikroTik App
 
bbs2web
Member Candidate
Member Candidate
Topic Author
Posts: 232
Joined: Sun Apr 22, 2012 6:25 pm
Location: Johannesburg, South Africa
Contact:

Route filters

Fri Apr 07, 2017 10:15 pm

What are people doing to avoid the following? We mark customer routes with communities, set a higher local preference and weight.

IP transit customer peers with us on pe3 and pe4, we add bgp community (eg xxx:1000) and set local preference to 200. Customer advertises /22.
Provide edge routers pe1 and pe2 are also offered customer prefixes at a public internet exchange but our higher local preference wins out so:
- We only advertise prefixes to our upstreams when they contain community xxx:1000. This would withdraw their prefixes and subsequently their IP transit, should we not learn their prefix via the direct peering session.
- Local preference is higher for prefix received via direct peering link, so we can restrict customer to subscribed speed.

Customer now however additionally advertises /24 subnets via internet exchange but filters them from our direct peering session. Whilst his /24 subnets aren't advertised upstream to our providers, our infrastructure routes according to longest prefix match so we send customer traffic back via internet exchange where we don't have restrictions.

We're currently having to add prefix filters, to each router at public IXs, to discard routes containing customer's ASNs. This is very laborious, anyone have clever suggestions?
Last edited by bbs2web on Sat Feb 16, 2019 6:33 pm, edited 1 time in total.
 
faisali
Member Candidate
Member Candidate
Posts: 180
Joined: Fri Oct 08, 2010 5:11 am

Re: Route filters

Sun Apr 09, 2017 3:26 am

Well, now you know the reason why IP Transit providers do not 'peer' with their customers over the peering exchanges...

Having said that, keep in mind that this is a bit of a business position vs technical position balance on how to manage the traffic.
Chances are that the IP Transit being provided to customer is being billed for, while the traffic over the peering exchange is not ? Is that correct ?

In such a case, you can take a position such as..
--> Highest Local Pref = Direct peer, and tag that with communities and local pref.
--> 2nd highest local Pref = Customer route learned over the peering exchange, tag this with a different community and lower local pref.
---> You only advertise out to your upstream the routes learned from Direct Peer, and nothing else.

You can take a position that, you will allow traffic over the peering exchange, and consider that free traffic.. (technically good, but may not be so business wise)
or you can choose to filter out (drop their prefix) when learned over the peering exchange .. (technically not great position, but good for business).

:)

We build our filters modular...
eg... one chain (ASXXXX) which has all the prefixes associated with that ASN
and in all of our other filters we refer to these in the actual filter chains.

BTW, in many peering exchanges there are communities available to allow for not advertising to a particular member.. you might want to ask your peering exchange folks for this.

:)
 
bbs2web
Member Candidate
Member Candidate
Topic Author
Posts: 232
Joined: Sun Apr 22, 2012 6:25 pm
Location: Johannesburg, South Africa
Contact:

Re: Route filters

Sun Apr 09, 2017 11:03 am

Hrmmm... Filtering out routes on the IX towards our customers unfortunately wouldn't stop us learning a more specific route to the customer via a path we don't want to limit capacity on. I suppose I could jump to a chain which I could build via a script, which would filter out prefixes if they reside within them though. Essentially something like:
For each prefix which has customer community add it to IX filter chain, this way we could discard any more specific customer prefixes via the IX automatically.
Does Cisco or Juniper have anything to do this without scripting?
 
bbs2web
Member Candidate
Member Candidate
Topic Author
Posts: 232
Joined: Sun Apr 22, 2012 6:25 pm
Location: Johannesburg, South Africa
Contact:

Re: Route filters

Sun Apr 09, 2017 12:19 pm

We already do that, the prefix we learn directly has a higher local preference and community assigned by us. Only prefixes with 'customer' community is advertised to our upstream providers. The better matched prefix we learn from our customer is however preferred, although we don't advertise this on, as it doesn't have the 'customer' community added, when we learn it via the IX...
Chances are that the IP Transit being provided to customer is being billed for, while the traffic over the peering exchange is not ? Is that correct ?

In such a case, you can take a position such as..
--> Highest Local Pref = Direct peer, and tag that with communities and local pref.
--> 2nd highest local Pref = Customer route learned over the peering exchange, tag this with a different community and lower local pref.
---> You only advertise out to your upstream the routes learned from Direct Peer, and nothing else.
 
faisali
Member Candidate
Member Candidate
Posts: 180
Joined: Fri Oct 08, 2010 5:11 am

Re: Route filters

Sun Apr 09, 2017 8:57 pm

If I am understanding you correctly, then I think you are building filters which are prefix specific....

We build our filters in such a manner
e.g. chain=XYG:12345 prefix=xx.yy.zz.0/21 prefix-length=21-24 invert-match=no action=accept

the prefix-length option selects all prefix lengths from /21 to /24, as such you are covered irrespective of the prefix size being advertised.
 
faisali
Member Candidate
Member Candidate
Posts: 180
Joined: Fri Oct 08, 2010 5:11 am

Re: Route filters

Sun Apr 09, 2017 9:00 pm

Hrmmm... Filtering out routes on the IX towards our customers unfortunately wouldn't stop us learning a more specific route to the customer via a path we don't want to limit capacity on. I suppose I could jump to a chain which I could build via a script, which would filter out prefixes if they reside within them though. Essentially something like:
For each prefix which has customer community add it to IX filter chain, this way we could discard any more specific customer prefixes via the IX automatically.
Does Cisco or Juniper have anything to do this without scripting?

Keep in mind that filtering can be done on two sides for you... 1) Choosing to send your prefixes to them (a.k.a advertising your prefixes) you can stop those by using IX communities and 2) Choosing what you receive from them (this is what you can filter on incoming prefixes, and if you use prefix-length then you are covering from the smaller prefix length to the larger prefix length).
 
bbs2web
Member Candidate
Member Candidate
Topic Author
Posts: 232
Joined: Sun Apr 22, 2012 6:25 pm
Location: Johannesburg, South Africa
Contact:

Re: Route filters

Mon Apr 10, 2017 12:26 pm

Just to recap:
We learn customer prefixes via dedicated downstream routers which append a community xxx:1000 and set a high local
preference. These routers have queues applied, to limit customers to their subscribed service speed.
If a customers advertises eg 1.1.1.0/22 to us, this prefix is then correctly advertised to our upstream providers.
If clever customers then however additionally advetise 1.1.1.0/24 on an internet exchange where we peer with route servers , our
infrastructure would learn this route and whilst it wouldn't advertise it upstream (it doesn't contain community
xxx:1000) we would still prefer to route their traffic towards them via this more specific route.

We subsequently wrote a script which automatically maintains a prefix filter on our routers at various internet
exchanges, to discard any prefixes which match or fall within prefixes we learn from our customers.
/system script
  add name=bgp-build_customer_filter owner=admin policy=read,write \
    source=":log info \"BGP - Started building customer prefix filter\";\r\
    \n:local i;\r\
    \n:local destination;\r\
    \n:local nm;\r\
    \n\r\
    \n/routing filter set [ find where chain=customer-prefix-filter ] comment=\"deleteme:\";\
    \r\
    \n:foreach i in=[ /ip route find where active and bgp-communities ~ \"xxx:1000\" ] do={\
    \r\
    \n  :set destination [ /ip route get \$i dst-address ];\r\
    \n  :set nm [ :pick \$destination ([ :find \$destination \"/\" ]+1) [ :len \$destination \
    ] ];\r\
    \n  /routing filter add chain=customer-prefix-filter prefix=\"\$destination\" prefix-leng\
    th=\"\$nm-32\" action=discard;\r\
    \n}\r\
    \n/routing filter remove [ find where chain=customer-prefix-filter and comment=\"deleteme\
    :\" ];\r\
    \n:log info \"BGP - Finished building customer prefix filter\";\r\
    \n"

/system scheduler
  add interval=3h name="Build customer prefix filter" on-event="/system script run \"bgp-build_customer_filter\"" \
    policy=read,write start-date=jan/01/1970 start-time=00:30:00
Last edited by bbs2web on Sun Feb 17, 2019 1:46 am, edited 2 times in total.
 
faisali
Member Candidate
Member Candidate
Posts: 180
Joined: Fri Oct 08, 2010 5:11 am

Re: Route filters

Mon Apr 10, 2017 5:10 pm

If it works for you, great.... we do this in a simpler way..

we build our filters chains for all of our down-stream BGP customers with the prefix-length option..
e.g. chain=XYZASN prefix=xx.yy.zz.0/21 prefix-length=21-24 invert-match=no action=accept etc..


all of our bgp sessions have in filters and out filters...
for our down-stream customers, we add a bgp community on received routes...
e.g. chain=xyzbgp-in match-chain=XYZASN invert-match=no action=accept set-bgp-local-pref=200 append-bgp-communities=yyyy:115 etc

this allows us to control the bgp advertisements to our peers (upstream or over the IX)
we build our 'out' filters ref both the XYZASN chain, and the bgp-communities-yyy:115

if we wanted to not not receive any prefixes from one of the IX members, with whom we are peering, we can simple do that in our 'in' filter for the bgp peer/session
e.g. chain=someixpeer-in match-chain=XYZASN invert-match=no action=discard

that only leaves one issue.. if these folks are peering over the Route Server (IXP's) then there is nothing you can do to advertise your prefixes to them... unless you have a BGP Community provided by the IXP that allows you to not advertise your prefixes to a particular ASN/IXP member. (otherwise they can /will send traffic to you over the IXP and the return path will be via the ip transit connection).

The key is when you are using prefix-length=xx-24 then you have a variable filter which catches everything..
additionally you should not be accepting anything larger than a /24 prefix unless you have a special need..

Regards
 
bbs2web
Member Candidate
Member Candidate
Topic Author
Posts: 232
Joined: Sun Apr 22, 2012 6:25 pm
Location: Johannesburg, South Africa
Contact:

Re: Route filters

Mon Apr 10, 2017 11:43 pm

I don't want to have to update every BGP peering router every time a customer announces a new prefix though, only the routers they peer with.
This way the downstream routers can accept eg 10.0.0.0/21 prefix-length=21-24 with an authorised AS path, add our customer community and apply a higher preference.
Upstream routers, which are separate, now automatically filter any prefixes that match or fall within customer prefixes...
I have not found a method to do this automatically on Cisco or Juniper; essentially to not accept a prefix if it is more specific that one already present in the routing table (prefixes with equal netmasks would lose against those with higher local preference).
PS: Unless you're filtering and peering with your customer on an IXP and 'customer port' via the same router you would need to manually update filters on various devices or also be at risk of providing free IP transit...
 
faisali
Member Candidate
Member Candidate
Posts: 180
Joined: Fri Oct 08, 2010 5:11 am

Re: Route filters

Tue Apr 11, 2017 1:51 am

ok... let's play devil's advocate for a moment...

You said, you don't want to update filters on all of your upstream routers when a client announces/adds a new prefix..
.. In reality doing so would be considered a best practices, because it will force you to keep your filters updated and clean..
besides, you would need to take some action to make sure that the Upstream also open up their filters.

-------------------------
I have not found a method to do this automatically on Cisco or Juniper; essentially to not accept a prefix if it is more specific that one already present in the routing table (prefixes with equal netmasks would lose against those with higher local preference).
-------------------

For many networks doing so would be considered wrong, and will break routing...
e.g. we have ourselves and others, who take out a /24 out of their block and have us route it at a different geographical POP, as such if our Upstream router was setup as per your suggestion then most likely it will break routing for that /24.

It is debatable, if building filters based on AS path is the proper thing to do... for many Tier2 or Tier3 folks such as ourselves, doing so will break stuff and not provide a good method of control..

I agree with you that peering with your customer on an IXP along with IP Transit can potentially have a negative affect on the business side, however a lot of it depends on what type of business arrangement you have... e.g. in case of full port Flat Rate pricing , it may not matter .. or if you have some sort of flow accounting in place.... but in general yes, I agree with you..

Easiest way to fix this, in my opinion, is to not advertise your prefixes to the customer and not to accept their prefixes on the IXP.

There are many ways to skin this cat, they can all achieve the same results, myslef, I am not a huge fan of scripting such solutions, when there is a change in personnel or updates in the code, troubleshooting them can become a chore.. :)

Who is online

Users browsing this forum: No registered users and 11 guests