Re: Changing next-hop for EBGP peer routes

alexandru.coles · ‎09-19-2006

Hello,

Is it possible to change the next-hop of some updates received through eBGP? Let's say the customer receives a flood and wants to advertise to the ISP a /32 prefix so the filtering occurs at the network edge. I was thinking something like:

PE config:

router bgp 100

bgp router-id 192.168.255.14

no bgp default ipv4-unicast

no bgp default route-target filter

bgp log-neighbor-changes

neighbor 192.168.2.2 remote-as 102

neighbor 192.168.2.2 update-source Ethernet0

!

address-family ipv4

neighbor 192.168.2.2 activate

neighbor 192.168.2.2 route-map InboundM in

...........

no auto-summary

no synchronization

...........

ip prefix-list prfx seq 5 permit 0.0.0.0/0 ge 32

!

route-map InboundM permit 10

match ip address prefix-list prfx

set ip next-hop 192.0.3.1

set origin igp

set community no-export

!

route-map InboundM permit 20

!

ip route 192.0.3.1 255.255.255.255 null 0

!

Unfortunately:

PE_XXX#sh ip bgp 69.0.0.1

BGP routing table entry for 69.0.0.1/32, version 3286

Paths: (1 available, no best path)

Not advertised to any peer

102

192.0.3.1 (inaccessible) from 192.168.2.2 (192.168.2.2)

Origin IGP, metric 0, localpref 100, valid, external

Community: no-export

PE_XXX#sh ip bgp 69.0.0.0

BGP routing table entry for 69.0.0.0/24, version 7

Paths: (1 available, best #1, table Default-IP-Routing-Table)

Advertised to non peer-group peers:

192.168.255.2 192.168.255.13

102

192.168.2.2 from 192.168.2.2 (192.168.2.2)

Origin IGP, metric 0, localpref 100, valid, external, best

I thought of propagating the route through iBGP, while having those static routes to Null0 configured on every PE.

Thanks,

Alexandru

mheusinger · ‎09-19-2006

Hi,

this should work. In fact there is a presentation on NANOG regarding triggered black hole routing (as they call it).

Have a look at:

Customer-Triggered Real-Time Blackholes. Level: Introductory

http://www.nanog.org/mtg-0402/morrow.html

ISP Security - Real World Techniques I - Remote Triggered Black Hole Filtering and Backscatter Traceback

http://www.nanog.org/mtg-0110/greene.html

A couple more interesting things can be found at "NANOG Security Curriculum"

http://www.nanog.org/ispsecurity.html

The above mentioned papers focus on BGP in the internet, but most practices can be applied in VRFs as well with only minor adjustments.

Hope this helps! Please rate all posts.

Regards, Martin

alexandru.coles · ‎09-19-2006

Hi Martin, and thanks for the reply.

I want to make a step further from the blackhole routing described in those docs, so I don't have to manually provision the static route(s) that gets redistributed by iBGP and trigger blackholing, and to also allow the customer to announce me long prefixes for me to filter out dynamically.

Still, it doesn't seem to work as expected, as you can see from the output the /32 prefix doesn't get advertised with the 192.0.3.1 next-hop to be filtered out at the edge.

PE_XXX#sh ip bgp 69.0.0.1

BGP routing table entry for 69.0.0.1/32, version 3286

Paths: (1 available, no best path)

Not advertised to any peer

102

192.0.3.1 (inaccessible) from 192.168.2.2 (192.168.2.2)

Origin IGP, metric 0, localpref 100, valid, external

Community: no-export

Thanks,

Alexandru

richard.ingram · ‎09-19-2006

Alexandru-

I believe your prefix-list should be "le" instead of "ge".

Best regards,

Rich

mheusinger · ‎09-19-2006

Hi,

the statement "192.0.3.1 (inaccessible)" tells you, that there is no route to 192.0.3.1 in the routing table. So either you configure the respective route to the Null0 interface or you announce the 192.0.3.1/32 through IGP or BGP.

Try

PE config:

router bgp 100

bgp router-id 192.168.255.14

no bgp default ipv4-unicast

no bgp default route-target filter

bgp log-neighbor-changes

neighbor 192.168.2.2 remote-as 102

neighbor 192.168.2.2 update-source Ethernet0

!

address-family ipv4

network 192.0.3.1 mask 255.255.255.255

neighbor 192.168.2.2 activate

neighbor 192.168.2.2 route-map InboundM in

route-map InboundM permit 10

match ip community-list 66

set ip next-hop 192.0.3.1

set origin igp

set community no-export

!

route-map InboundM permit 20

ip community-list 66 permit 100:66

So if the customer announces a network with community 100:66 packets for this network will be dropped. The customer can of course announce a /32 for a host under attack.

and this should achieve the desired result.

Hope this helps! Please rate all posts.

Regards, Martin

alexandru.coles · ‎09-19-2006

Hi,

The route to 192.0.3.1 actually is in the routing table.

5300_Readiness#sh ip route 192.0.3.1

Routing entry for 192.0.3.1/32

Known via "static", distance 1, metric 0 (connected)

Routing Descriptor Blocks:

* directly connected, via Null0

Route metric is 0, traffic share count is 1

5300_Readiness#sh ip bgp neigh 192.168.2.2 route

BGP table version is 8193, local router ID is 192.168.255.14

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

*> 5.5.5.0/24 192.168.2.2 0 0 102 i

*> 69.0.0.0/24 192.168.2.2 0 0 102 i

* 69.0.0.1/32 192.0.3.1 0 0 102 i

Total number of prefixes 3

5300_Readiness#sh run int null 0

Building configuration...

Current configuration : 43 bytes

!

interface Null0

no ip unreachables

end

5300_Readiness#sh ip bgp 69.0.0.1

BGP routing table entry for 69.0.0.1/32, version 3286

Paths: (1 available, no best path)

Not advertised to any peer

102

192.0.3.1 (inaccessible) from 192.168.2.2 (192.168.2.2)

Origin IGP, metric 0, localpref 100, valid, external

I also tried pointing the static route to another destination (not Null 0) and got the same output.

Regards, Alexandru

alexandru.coles · ‎09-22-2006

Ok, I've found out what the problem was. It seems that configuring the eBGP session as ebgp-multihop works. Here's the output:

router bgp YYY

no bgp default ipv4-unicast

no bgp default route-target filter

bgp log-neighbor-changes

neighbor 192.168.2.2 remote-as XXX

neighbor 192.168.2.2 description *** Customer ***

neighbor 192.168.2.2 ebgp-multihop 255

!

address-family ipv4

neighbor 192.168.2.2 activate

neighbor 192.168.2.2 send-community

neighbor 192.168.2.2 route-map Inbound in

no auto-summary

no synchronization

exit-address-family

!

ip route 192.0.3.0 255.255.255.0 Null0 tag 6969

!

ip prefix-list pref32 seq 5 permit 0.0.0.0/0 ge 32

!

route-map Inbound permit 10

match ip address prefix-list pref32

set ip next-hop 192.0.3.1

set origin igp

!

route-map Inbound permit 20

!

The route gets redistributed with 192.0.3.1 as next hop, and traffic gets filtered out at the edge.

PE_X_#sh ip cef 69.0.0.1

69.0.0.1/32, version 19162, epoch 0

0 packets, 0 bytes

tag information from 192.0.3.1/32, shared

local tag: implicit-null

via 192.0.3.1, 0 dependencies, recursive

next hop 192.0.3.1, Null0 via 192.0.3.0/24

valid null (drop) adjacency

Thanks everyone for all the help.

Alexandru