Walter Prue wrote:
This second low speed connection thus becomes a lightning rod for the
DDOS traffic most of which will be discarded and not even delivered due
to congestion on the slow speed link, the slower the better for you.
This of course kills all traffic to the attacked node but the rest of
^^^^^^^^^^^^^^^^^
the network remains usable.
Including the BGP session, I would think, thus causing it to reset and
drop the route, sending all the traffic back to the primary, which unfloods
the smaller link, which re-advertises, which...
Flappage, anyone?
> This of course kills all traffic...
> Including the BGP session, I would think, thus causing it to reset and
> drop the route, sending all the traffic back to the primary, which unfloods
> the smaller link, which re-advertises, which...
Which in turn can be fixed by adding a _third_ connection between the two
routers, dedicated to advertising /32s, which the upstream/recipient then
route-maps to set-next-hop to the second connection... 
Sounds to me like we need itrace soon.
-Bill
Including the BGP session, I would think, thus causing it to reset and
drop the route, sending all the traffic back to the primary, which
unfloods
the smaller link, which re-advertises, which...
Flappage, anyone?
Why not just advertise the host route with an unreachable next hop from your
main peering session?
Best regards,
Geoff Zinderdine wrote:
Why not just advertise the host route with an unreachable next hop from your
main peering session?
Maybe your upstream sets the NEXT_HOP to your side of the point-to-point for
you, just in case you neglected to do so.
Even if they don't, who's to say what's unreachable? If the NEXT_HOP is
truly unreachable, in that there is no route to it, the BGP path won't be
marked as valid and won't make it to the IP routing table (Loc-RIB.)
I've long felt that IP should have come with a provision for an address that
is never routed. It would be great if we could get something like 127.0.0.2
for this very task.
Mark
Agreed. Still you could just throw up a box at the end of that low speed
line and have your main peering session set it as NEXT_HOP for the host
route without needing it to be running a BGP session itself, no?
Easy...
ip route 127.254.254.254 255.255.255.255 null0
BGP sees this as a valid route, straight to the bit bucket.
-C
Christopher Woodfield wrote:
Easy...
ip route 127.254.254.254 255.255.255.255 null0
BGP sees this as a valid route, straight to the bit bucket.
Great. Now let's update RFC 1812.
Mark