Query for BGP

[mahesh-gohil]

Hi all,

I have a ISP customer with AS number :xxxx Now he come up with further customer xxxx AS. Presently we are doing prefix based filtering at my end.

Now i want to use regular expression with " ^xxxx_ ", so that any prefix ill be allowed with ASxxxx and behinf that AS Now with this regular expression threat is what happen if my customer will leak internet routes ?

Is there any other solution with which i can allow my customer (xxxx) prefixes other that prefix-list

Thanks in advance

[mheusing]

Hi,

The usage of AS path filters and prefix-lists targets different filtering scenarios. AS path lists will only filter based on AS path, but has not prefix specific component. prefix-lists do not have any AS specific component.

So it looks to me that in your case you should apply both as input filters. This can be done either separately with two statements "neighbor a.b.c.d filter-list 1 in" with a "ip as-path access-list 1" and "neighbor a.b.c.d prefix-list XYZ in" or you can combine both in a route-map:

neighbor a.b.c.d route-map customer in

route-map customer permit 10

match as-path 1

match ip address prefix-list XYZ

The two match statements in the route-map are ANDed and will only allow certain prefixes from the customer AS.

Hope this helps! Please use the rating system.

Regards,

Martin

[marikakis]

Hello,

You can limit the number of prefixes received from a neighbor using the neighbor maximum-prefix command:

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guide/ftbrsamp.html#wp1052454

However, using both as-path ACLs and prefix-lists is the safest choice. The prefix-list might be a burden, but it allows for tighter control of what the customer advertises, especially if they accidentally leak unacceptable more specific routes (e.g. any subnet smaller than a /24, such as a /30 or even a /32). To avoid such situations, prefix-list is your only choice, but you can make it less of a burden if you just deny all the smaller subnets, without specifying exact networks (e.g. deny 0.0.0.0/0 ge 25). Still, the recommended procedure is to control what customers advertise. It is not very flattering to be listed in the CIDR report with possible bogons.

Although as-path ACLs do not seam as tight as prefix lists, they can actually be tight in a different way. You can configure the exact AS_PATH the route should comply to. You can configure the as-path ACL to permit only routes that were locally originated in your direct customer or in a customer of your direct customer. This way, internet routes will be denied, because they fail the AS_PATH check (routes are known via customer AS as opposed to being locally originated in customer AS). For a way to accomplish this, have a look at the following post:

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40.2cc251a6/4#selected_message

Kind Regards,

M.

[mahesh-gohil]

Prefix list is OK. Presently I am doing same. But it seems more burden to us.

Now scenario is My AS- Customer AS--Customer AS- Customer AS.

Even if i use ^xxxx_customerAS_CustomerAS$ again it adds burden. no doubt this burden is little low.

so solution require here is to minimise provide effort + tighter security

--Mahesh

[marikakis]

Hello,

"minimise provide effort + tighter security" seams like a trade-off. A prefix-list together with a proper as-path ACL is as tight as it gets. I think IOS cannot help us more with this than it already does. I suppose you are actually looking for a way to automate your procedures (and effort will be minimized as a result). I have not used many automated tools to suggest one, but others here might.

I have only tested a couple of prefixes in a prefix-list sanity checker (requires account, easy to setup one), which can be found at: https://prefix.pch.net/applications/prefix-sanity/main.php

You enter the prefixes in various possible formats, and the tool checks if a prefix is e.g. a private address. It can then generate prefix-lists in various vendor formats.

There is another level of automation, besides a tool generating configuration. You can have it afterwards login to the router and apply the configuration. We were doing this with plain ACLs, but I do not have the script code anymore.

If you decide on using some level of automation, other people here might be able to direct you to tools they have actually used. Depending on your automation requirements, you might or might not have to invest some time in tool development.

Kind Regards,

M.