1

I have a network that resembles this

CUSTOMER - BT - SPRINT
           BT - CISCO

customer loopback 192.168.10.1 customer loopback1 192.168.1.1

BT loopback 192.168.50.1

CISCO loopback 192.168.100.1

SPRINT loopback 192.168.150.1

customer is connected to BT

BT is connected to SPRINT and CISCO

I am using Community values and I want to block the advertisement of 192.168.1.1/24 to SPRINT but allow it to appear in Cisco

This was my failed attempt:

CUSTOMER:
ip prefix-list ROUTE 192.168.1.0/24
neighbor 2.2.2.2 (bt) route-map BLOCKSPRINT out
neighbor 2.2.2.2 send-community

route-map BLOCKSPRINT p 10
match ip add prefix-list ROUTE
set community 500:500
route-map BLOCKSPRINT p 20

BT
ip prefix-list CISCO 192.168.150.0/24
ip community-list 1 500:500 
neighbor 1.1.1.1 Peer-CUST in
neighbor 1.1.1.1 send-communities
neighbor 3.3.3.3 send-communities

route-map Peer-CUST p 10
match ip add prefix-list CISCO
match community 1
set community no-advertise
route-map Peer-CUST p 20

The address still shows up on the SPRINT router.

1
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin
    Aug 11 '17 at 16:40
1

You have BT sending the route to Sprint with the no-advertise community so that the Sprint router will not advertise it. BT needs to filter the prefix to Sprint. Something like:

neighbor 3.3.3.3 distribute-list 1 out 
!
access-list 1 deny 192.168.1.1 0.0.0.255
access-list 1 permit any

or

neighbor 3.3.3.3 route-map BLOCKSPRINT out 
!
access-list 1 deny 192.168.1.1 0.0.0.255
access-list 1 permit any
!
route-map BLOCKSPRINT permit 10 
 match ip address 1
8
  • Sorry I was wanting help along the lines of prefix-lists and community attributes - I managed to get something working but instead of filtering ONE route it filtered all the routes from CUSTOMER
    – Daniel
    Dec 2 '16 at 18:27
  • The problem with your approach is that one AS cannot dictate to another AS. Any AS is free to ignore anything a peer AS wants. It requires a business arrangement between the ASes to achieve what you want. It is completely up to BT what prefixes it does or does not advertise to any peer, and CUSTOMER really has no say over that, absent a contractual arrangement.
    – Ron Maupin
    Dec 2 '16 at 18:30
  • Actually Ron some services do offer community attributes that block advertisements to certain geographical areas or other service providers
    – Daniel
    Dec 2 '16 at 18:31
  • See [onestep.net/communities/as1239/] for proof of blocking routes to certain areas or AS
    – Daniel
    Dec 2 '16 at 18:33
  • 1
    Your page is what sprint will or will not accept. The problem you have is that BT is advertising the prefix to Sprint with the no-advertise community. That means Sprint is getting the prefix, but Sprint, not BT, will not advertise the prefix. It is BT that is multi-homed, not the customer, and you are not even trying to prevent the advertisement of that prefix from BT, only from Sprint.
    – Ron Maupin
    Dec 2 '16 at 18:45
1

So a couple of points to this-

1.) NO_ADVERTISE is intended to prevent a given BGP speaker from propagating the route any further. So in this case adding this attribute to given route advertised to a peer will actually prevent the route from being pushed to the remainder of the carrier's network. You might want to consider NO_EXPORT, which is intended to restrict the propagation of a given prefix beyond a confederation (or an entire AS if confederations aren't in use). See RFC1997 for details on the behaviors of communities in general and well-known communities in particular.

2.) The well-known communities don't -have- to be honored but, in general, they are by default in most implementations (..unless you choose to explicitly strip these values). They tend to be all-or-nothing in nature, though - so, for example, signify that a given route can't propagate past the immediate peer router or past the peer router's ASN. In this case putting NO_EXPORT on a route would prevent BT from advertising to Cisco or Sprint, but would allow it to be present throughout any other routers inside the BT ASN.

3.) In this case the owners of the BT and Customer routers would have to agree upon a community value and its special meaning if you want the route to be selectively advertised (or not specifically not advertised) to a given upstream peer. Your carrier might also append communities indicating whether a given route is from one of their other direct customers or from an upstream transit (this is a handy way to pare down table sizes). Apart from the well-known values mentioned above everything else is potentially up for grabs and, also as mentioned, there's no standard guarantee (beyond what's negotiated with the carrier) of what behavior corresponds to what community. There's also no assurance that any carrier will preserve appended communities as prefixes cross their network.

So let's take a fairly simple example. On the BT router (let's call it ASN2856) we'll set up a filter on each of its peers to CUSTOMER (which we'll call ASN65400), Sprint (ASN1239) and Cisco (ASN109) such that only routes with xxx:ASN will be permitted. As such, if we put 65400:109 on the route but not 65400:1239 then the route will be allowed to Cisco but not Sprint. If both 65400:1239 and 65400:109 are appended to a prefix the route will go to both. If neither, then the route will stay inside ASN2856.

So on BT we'd have something like

ip community-list to-cisco permit .*:109
ip community-list to-sprint permit .*:1239
ip community-list to-customer permit .*:65400

route-map CISCO-PEER-OUT permit 10
   match community to-cisco
   set community none
route-map CISCO-PEER-OUT deny 20

route-map SPRINT-PEER-OUT permit 10
  match community to-sprint
  set community none
route-map SPRINT-PEER-OUT deny 20

route-map CUSTOMER-PEER-OUT permit 10
  match community to-customer
  set community none
route-map CUSTOMER-PEER-OUT deny 20

! Start the BGP section

neighbor 1.1.1.1 send-communities
neighbor 1.1.1.1 remote-as 109
neighbor 1.1.1.1 route-map CISCO-PEER-OUT out

neighbor 2.2.2.2 send-communities
neighbor 2.2.2.2 remote-as 1239
neighbor 2.2.2.2 route-map SPRINT-PEER-OUT out

neighbor 3.3.3.3 send-communities
neighbor 3.3.3.3 remote-as 65400
neighbor 3.3.3.3 route-map CUSTOMER-PEER-OUT out

On the CUSTOMER router you'd have something like this

ip prefix-list ROUTES-FOR-CISCO permit 192.168.1.0/24

route-map MARK-ROUTE permit 10
   match ip address prefix-list ROUTES-FOR-CISCO
   set community 65400:109
route-map MARK-ROUTE permit 20
   match any
   set community 65400:109 65400:1239

!BGP section

neighbor 3.3.3.4 remote-as 2856
neighbor 3.3.3.4 send-community
neighbor 3.3.3.4 route-map MARK-ROUTE out

This would set the prefix 192.168.1.0/24 with a community of 65400:109, which would allow the route to be sent only to ASN109. All other routes would have both 65400:109 and 65400:1239 - which would allow said routes to go to either carrier. On the BT router I've also set it to clear all communities on routes sent to peers - so, for example, the CISCO peer wouldn't see the 65400:109 community you included.

In practice the communities probably wouldn't be structured quite like this, of course, but this should hopefully give you a taste of what's possible.

Hope this helps-

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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