Remover the tag 666 from you

Evgeny Khorokhorin · ‎04-10-2015

Hi all, I'm using Cisco 6513, Sup720-3bxl,

Cisco IOS Software, s72033_rp Software (s72033_rp-ADVIPSERVICESK9_WAN-M), Version 12.2(33)SXJ2, RELEASE SOFTWARE (fc4)

I'm trying to implement BGP blackhole mechanism so that our clients could use it via setting community 65000:666 on their prefixes.

In this example: client with AS65001 has BGP peer address 192.168.10.10 and it is multihop bgp session (192.168.10.10 is routed via 192.168.9.2).

router bgp 65000
...
 redistribute static route-map blackhole
 neighbor 192.168.10.10 remote-as 65001
 neighbor 192.168.10.10 route-map client_in in
 neighbor 192.168.10.10 ebgp-multihop 10
 neighbor 192.168.10.10 disable-connected-check
 neighbor 192.168.10.10 update-source Loopback0
!

 address-family ipv4
  redistribute static route-map blackhole
  neighbor 192.168.10.10 activate
  neighbor 192.168.10.10 send-community both
  neighbor 192.168.10.10 soft-reconfiguration inbound
  neighbor 192.168.10.10 route-map client_in in
...
  no auto-summary
  no synchronization

...
ip community-list standard clients-blackhole permit 65000:666
...
ip route 192.0.2.1 255.255.255.255 Null0 tag 666
...
route-map client_in permit 10
 match community clients-blackhole
 set ip next-hop 192.0.2.1
!
route-map client_in permit 100
 match ip address prefix-list client
 match as-path 30
 set local-preference 300
 set weight 3000
 set ip next-hop 192.168.9.2
!
route-map blackhole permit 10
 match tag 666
 set origin igp
 set community 65000:666

sh ip bgp nei 192.168.10.10 ro
BGP table version is 246438222, local router ID is 1.2.3.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.10.10.0/24   192.168.9.2            0    300   3000 65001 i
*  10.10.10.4/32   192.0.2.1                0             0 65001 i

Total number of prefixes 2
#sh ip bgp 10.10.10.4
BGP routing table entry for 10.10.10.4/32, version 246438764
Paths: (2 available, no best path)
  Not advertised to any peer
  65001
    192.0.2.1 (inaccessible) from 192.168.10.10 (192.168.10.10)
      Origin IGP, metric 0, localpref 100, valid, external
      Community: 65000:666
  65001, (received-only)
    192.168.10.10 (metric 20) from 192.168.10.10 (192.168.10.10)
      Origin IGP, metric 0, localpref 100, valid, external
      Community: 65000:666
#sh ip bgp 192.0.2.1    
BGP routing table entry for 192.0.2.1/32, version 246291206
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups:
     2          8         
  Local
    0.0.0.0 from 0.0.0.0 (1.2.3.4)
      Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, best
      Community: 65000:666
#sh ip route 192.0.2.1 
Routing entry for 192.0.2.1/32
  Known via "static", distance 1, metric 0 (connected)
  Tag 666
  Redistributing via ospf 1, bgp 65000
  Advertised by ospf 1 subnets
                bgp 65000 route-map blackhole
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1
      Route tag 666

As you can see BGP router is receiving 2 prefixes: 10.10.10.0/24 and 10.10.10.4/32. Second is with blackhole community 65000:666. So I need that packects going to 10.10.10.4 to be sent to Null0. In this example show ip bgp 10.10.10.4 says that next-hop 192.0.2.1 is inaccessible so Blackhole mechanism doesn't work and traffic with dst ip 10.10.10.4 is sending to a client.

Please tell me where is my fault?

Chris Dixon · ‎04-13-2015

Hi,

I think you could do this more easily by blackholing it directly from the route-map but theres probably a much easier way of achieving what you want.

However, specifically In terms of the above, it seems you're receiving another bgp route (10.10.10.0/24) which does not have the community attribute set on it and hence is not matching your route-map, the /32 wont get installed in the route table (pls verify this with sh ip route 10.10.10.4) as its not valid/best so your routing table is probably using the .24 route to get to that destination

Thanks

Evgeny Khorokhorin · ‎04-13-2015

Hi Chris,

So I'm trying to blackhole it directly from route-map (set ip next-hop 192.0.2.1).

No there is no another bgp route to 10.10.10.0/24. Only from this peer. As route to 10.10.10.4/32 is not installed to FIB, show ip route 10.10.10.4 shows this:

sh ip route 10.10.10.4
Routing entry for 10.10.10.0/24
  Known via "bgp 65000", distance 20, metric 0
  Tag 65001, type external
  Last update from 192.168.9.2 5d00h ago
  Routing Descriptor Blocks:
  * 192.168.9.2, from 192.168.10.10, 5d00h ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65001
      MPLS label: none

Chris Dixon · ‎04-13-2015

Hi,

maybe Im getting confused.... dont you want the 10.10.10.0/24 to have matched this route-map:

route-map client_in permit 10
 match community clients-blackhole
 set ip next-hop 192.0.2.1
!

It looks like the /32 is having the community attribute and hence matching it, but the /24 is not

Evgeny Khorokhorin · ‎04-13-2015

Yes, you're right.

route-map client_in permit 10 - matches /32 (that should be blackholed)

route-map client_in permit 100 - matches the rest prefix /24 (that should goes normally)

So I try to blackhole the traffic going to 10.10.10.4/32 via route-map client_in permit 10.

mauricio.andrade81 · ‎04-13-2015

Remover the tag 666 from you static ip null route. You dont need redistribute into BGP.

Evgeny Khorokhorin · ‎04-13-2015

It doesn't help and affect on needed effect.

I think that the needed blackhole route get "accessible" when it routes to ip next-hop that is directly connected to some L3 interface. But what is the right way to blackhole clients' traffic?

Chris Dixon · ‎04-14-2015

I think Mauricio is correct and you dont need to redistribute the static into BGP -after all thats only there to blackhole the traffic on the local router.

it looks like the problem you have is that the route to be blackhole doesnt get installed in your rib as its not valid, therefore instead of routing it to null0 you route to the shorter match (/24) which is the best match as it is installed in your route table.

If you take the redist static out, what do you see? Can you show us sh ip bgp and sh ip route afterwards?

Evgeny Khorokhorin · ‎04-14-2015

I removed redistribute static route-map blackhole but as I wrote earlier - it doesn't help:

#sh ip bgp 10.10.10.4
BGP routing table entry for 10.10.10.4/32, version 246438764
Paths: (2 available, no best path)
  Not advertised to any peer
  65001
    192.0.2.1 (inaccessible) from 192.168.10.10 (192.168.10.10)
      Origin IGP, metric 0, localpref 100, valid, external
      Community: 65000:666
  65001, (received-only)
    192.168.10.10 (metric 20) from 192.168.10.10 (192.168.10.10)
      Origin IGP, metric 0, localpref 100, valid, external
      Community: 65000:666

#sh ip route 192.0.2.1 
Routing entry for 192.0.2.1/32
  Known via "static", distance 1, metric 0 (connected)
  Tag 666
  Redistributing via ospf 1
  Advertised by ospf 1 subnets
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1
      Route tag 666

sh ip route 10.10.10.4
Routing entry for 10.10.10.0/24
  Known via "bgp 65000", distance 20, metric 0
  Tag 65001, type external
  Last update from 192.168.9.2 5d00h ago
  Routing Descriptor Blocks:
  * 192.168.9.2, from 192.168.10.10, 5d00h ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65001
      MPLS label: none

Chris, I didn't understand what exact you mean about "you route to the shorter match (/24) which is the best match as it is installed in your route table". Could you explain it?

Chris Dixon · ‎04-14-2015

I mean your /32 route is not valid and hence isnt being installed in your routing table.

The /24 is valid and installed in your routing table. Therefore when a packet comes in addressed to 10.10.10.4 the best match for it, and hence the one being used, is the 10.10.10.0/24, which is not what you want. You need to make sure the /32 that you're blackholing is valid so it can be installed in your RIB and hence be used.

Evgeny Khorokhorin · ‎04-14-2015

Heh, it is the main question HOW to make /32 valid and accessible so I could blackhole needed prefixes via it.

mauricio.andrade81 · ‎04-14-2015

Hi Evgeny, I see you configuration and the BGP session is multihop. Why are you configuring disable-connected-check? this is only for direct connect neighbords. When you disabled connected check in IOS you perform this actions in BGP (CEF recursion disabled):

- Disable next-hop learned for /32 mask routes.

- Disable next-hop for directly connect.

Remove your "disable-connected-check" and test.

regards,

Mauricio

Evgeny Khorokhorin · ‎07-06-2015

Mauricio,

I tried to uncofigure "disable-connected-check". This didn't make any changes to me.

Chris Dixon · ‎07-04-2015

How about if you ask the customer on their side to redistribute the /32 into bgp with the tag and the next hop of 192.0.2.1 at their end, then when they pass the route to you the next hop is 192.0.2.1, rather than you setting it with the route map i.e. You can remove the route-map line at your side that overrides the next hop

Evgeny Khorokhorin · ‎07-06-2015

Chris,

I tried this suggestion too and it didn't help too.

Cisco 6500 - BGP blackhole configuration problem