cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4743
Views
0
Helpful
8
Replies

filter out specfic routes from iBGP

paulkilcoyne
Level 1
Level 1

Hi Guys,

just looking for a start on this or any sort of guidance;

We got the following topology; central routes being advertised over our MPLS circuits to remote sites via eBGP, on the remote sites we are running iBGP. For one specific site we want to block certain routes from eBGP being advertised into our iBGP.

Any suggestions on how to go about this?

Many thanks,

PK

1 Accepted Solution

Accepted Solutions

Hi,

IMHO, a combination of both would be the safest way.

Let's say your HQ is using AS number 65001 and your iBGP neighbor is x.x.x.x.

You could configure something like this on your WAN routers on the remote site:

neighbor x.x.x.x route-map block_HQ out

!

ip as-path access-list 1 permit _65001$

!

ip prefix-list hq_prefixes seq 5 permit 10.20.30.0/20

!

route-map block_HQ deny 10

match ip address prefix-list hq_prefixes

match  as-path 1

route-map block_HQ permit20

!

This way  10.20.30.0/20 prefix originated from AS 65001 (=your HQ) would not be advertised to the neighbor x.x.x.x.

But if received originated from another AS, it would pass.

Is this what you need?

HTH,

Milan

View solution in original post

8 Replies 8

cadet alain
VIP Alumni
VIP Alumni

Hi Alain,

thanks for that, I'll look into it.

Regards,

Paul

Ven Taylor
Level 4
Level 4

If you're looking to filter out routes, you can also use regular expressions.

Let’s break some of the regular expressions down step-by-step.

The first one “.*” says to match any single character (“.”), and then find zero or more instances of that single character (“*”). This means zero or more instances or any character, which effectively means anything.

The next string “^$” says to match the beginning of the string (“^”), and then immediately match the end of the string (“$”). This means that the string is null. Within the scope of BGP the only time that the AS-Path is null is when you are looking at a route within your own AS that you or one of your iBGP peers has originated. Hence this matches locally originated routes.

The next string “^100_” says to match the beginning of the string (“^”), the literal characters 100, and then a comma, an open or close brace, an open or close, a parentheses, the start or end of the string, or a space (“_”). This means that the string must start with the number 100 followed by any non-alphanumeric character. In the scope of BGP this means that routes which are learned from the AS 100 will be matched, as 100 will be the first AS in the path when AS 100 is sending us routes.

The next string “_100$” is the exact opposite of the previous one. This string says to start with any non-alphanumeric character (“_”), followed by the literal characters 100, followed by the end of the string (“$”). This means that AS 100 is the last AS in the path, or in other words that the prefix in question was originated by AS 100.

The next string “_100_” is the combination of the two previous strings with some extra matches. This string means that the literal characters 100 are set between any two non-alphanumeric characters. The first of these could be the start of the string, which would match routes learned from AS 100, while the second of these could be the end of the string, which would match routes originated in AS 100. Another case could be that the underscores represent spaces, in which the string would match any other AS path information as long as “ 100 ” is included somewhere. This would match any routes which transit AS 100, and therefore “_ASN_” is generally meant to match routes that transit a particular AS as defined by the number “ASN”.

The final string “^[0-9]+$” is a little more complicated match. Immediately we can see that the string starts (“^”), and we can see later that it ends (“$”). In the middle we see a range of numbers 0-9 in brackets, followed by the plus sign. The numbers in brackets mean that any number from zero to nine can be matched, or in other words, any number. Next we have the plus sign which means one or more instances. This string “[0-9]+” therefore means one or more instance of any number, or in other words any number including numbers with multiple characters (i.e. 1, 12, 123, 1234, 12345678, etc.). When we combine these all together this string means routes originated in any directly connected single AS, or in other words, the routes directly originated by the peers of your AS.

Examples:

ip as-path access-list 100 permit .* (anything)

ip as-path access-list 101 deny .* (anything)

ip as-path access-list 110 permit ^$ (null string - match all locally originated routes)

ip as-path access-list 111 deny ^$
ip as-path access-list 111 deny _123456_ (all routes that transit AS 123456)
ip as-path access-list 111 permit .* (anything)


neighbor filter-list 111 in - Allow internal AS routes from an ISP IN, allow anything IN, deny any instance of 123456 IN
neighbor filter-list 110 out - Allow internal AS routes OUT


neighbor filter-list 111 in - Allow internal AS routes from SCP IN, allow anything IN, deny any instance of 123456 IN
neighbor filter-list 111 out  - Allow internal AS routes from SCP OUT, allow anything OUT, deny any instance of 123456 OUT

Ven

Ven Taylor

Great post Ven, thanks.

So to be more specific about what I'm trying to achieve:

We have a headquarters site that injects multiple routes into our MPLS cloud, at one specific remote office we have two mpls circuits to the cloud both receiving these routes.

The remote site has two WAN routers, one per mpls circuit, running eBGP to the cloud and iBGP to our two core LAN 6500 switches.

On the remote site WAN routers we want to block specific routes ( e.g. 10.20.30.0/20) from headquarters being injected into our iBGP.

Of the two options above which would be easier and more efficient to implement?

Thanks again,

PK

Hi,

IMHO, a combination of both would be the safest way.

Let's say your HQ is using AS number 65001 and your iBGP neighbor is x.x.x.x.

You could configure something like this on your WAN routers on the remote site:

neighbor x.x.x.x route-map block_HQ out

!

ip as-path access-list 1 permit _65001$

!

ip prefix-list hq_prefixes seq 5 permit 10.20.30.0/20

!

route-map block_HQ deny 10

match ip address prefix-list hq_prefixes

match  as-path 1

route-map block_HQ permit20

!

This way  10.20.30.0/20 prefix originated from AS 65001 (=your HQ) would not be advertised to the neighbor x.x.x.x.

But if received originated from another AS, it would pass.

Is this what you need?

HTH,

Milan

Hi Milan,

that's exactly what I'm trying to achieve.

Just one question regarding the route map:

route-map block_HQ deny 10

match ip address prefix-list hq_prefixes          ; so this matches the prefix & as number

match  as-path 1

route-map block_HQ permit 20                       ; Is this a permit all statement?

!

What would happen if we did not include the "route-map block_HQ permit 20" statement in the route map?

Many thanks,

PK

Hi Paul,

yes,

route-map block_HQ permit 20

is "permit all". In fact, "permit all which has not beeen denied by previous route-map entries".

If you don't include it, the route-map will not permit anything in this case.

So you would not advertise any prefix to your x.x.x.x iBGP neighbor - that's probably not your goal :-)

It's similar to the "implicit deny" rule in the end of Cisco access-lists.

HTH,

Milan

OK Milan,

I got it now. So there is an implicit deny in route maps too

This should be an easy implementation now thanks to all who contributed here.

PK

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: