09-19-2006 03:21 AM
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
09-19-2006 04:41 AM
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
09-19-2006 05:00 AM
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
09-19-2006 05:48 AM
Alexandru-
I believe your prefix-list should be "le" instead of "ge".
Best regards,
Rich
09-19-2006 08:02 AM
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
09-19-2006 09:58 PM
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
09-22-2006 01:54 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide