I have two bgp routers. OSPF as IGP and on Loopback's iBGP. Both routers have different peers, but both receive full routing table.

I have to connect client through BGP and give him full table. Client have one ASN and one prefix /24. What is good practise for filters? to block client from ridistribute wrong prefix.

Client have also other ISP that gives him full table. So if client will stop redistribution to me, I should also stop to redistrubute client prefixex further. How to accomplish it?

  • Did any answer help you? if so, you should accept the answer so that the question does not keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer.
    – Ron Maupin
    Dec 23, 2021 at 16:06

2 Answers 2


Given the customer of yours is a single ASN with a /24 prefix, it would be in your best interest to simply apply a prefix-list (Always better to assign the prefix-list within a route-map to allow further attributes to be set on ingress (local pref, communities, etc)) to your customers session. Here is an example route-map you can apply to your customers session that will only allow their prefix and deny anything else:

ip prefix-list ASXXX-PREFIXES permit x.x.x.x/24

route-map ASXXX-IN permit 10
 description Allow Customer Prefixes from ASXXX
 match ip address prefix-list ASXXX-PREFIXES

route-map ASXXX-IN deny 20
 description Block Everything Else

The above route-map will ensure the customer prefixes are allowed over the session while ensuring everything else is blocked. Being as specific as you can on route-maps/prefix-lists is the best practice.

Regarding your query around prefix redistribution to your upstream, you should only being doing this if the clients prefix has been received over the downstream session. A good way of doing this is via BGP Communities. On the ingress route-map listed above, you can apply a BGP community to the allowed prefix (e.g. 111:444). Now on your upstream route-maps you can have a statement that will send prefixes tagged with 111:444 as you know the only prefixes tagged with this community will be your clients. This route-map facing your upstream should still ALWAYS contain a prefix-list aswell.


Small-scale BGP customer prefix filtering

At this small scale, manually configuring a prefix-list for your BGP customer is appropriate.

What larger transit networks do

Larger transit networks consume IRR database(s) (RADB FAQ link) to automatically generate such prefix-lists. However, for just one BGP customer having one prefix-list entry, that kind of automation investment would be unwise.

What your upstream transit providers do, and how that affects you now

Note that you may need to think about this from your transit providers' perspective as well -- how are they managing your prefix-list on their equipment; and how does your new BGP customer's entry get into that list?

Do you manually request they update the list; or do you publish the appropriate IRR entries, and they consume them?

If your transit providers require you maintain IRR entries

If the later, you'll want to add your new BGP customer to an IRR as-set: object containing both your ASN and theirs; and ensure appropriate route: objects exist matching each origin ASN.

If they require it and do it on your behalf

If your transit providers simply do this on your behalf, it will create an IRR database maintenance headache for you in the future. It's best to control your own IRR objects; not have to email former ISPs to get them updated / deleted later on.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.