From: Jongsoo.Kim@Intelsat.com
Date: Tue Aug 10 2004 - 11:38:52 GMT-3
OK Wow. I never thought about this behavior even though I've been touched c
and j for such a long time.( cause I have never used it). Thanks for this
info as I learned something new about bgp next-hop behavior.
But regarding your previous email to explain a method of preventing DDOS
attack by changing next-hop and no-export,
My upstream are UUnet and Level 3 connecting about 10 Gige links or so. But
in our case, we are just using community.
So we are using some special community tag based on which these L3 and Uunet
has some policy pre-set to blackhole the matches.
Is there some reason why you don't just use community to prevent DOS?
JK
-----Original Message-----
From: James [mailto:james@towardex.com]
Sent: Monday, 09 August, 2004 7:58 PM
To: Kim, Jongsoo
Cc: ccielab@groupstudy.com
Subject: Re: RE: BGP Update Source
On Mon, Aug 09, 2004 at 07:06:20PM -0400, Jongsoo.Kim@Intelsat.com wrote:
> James
>
> Are you saying we can't change next-hop attribute via route-map without
> ebgp-multihop configured?
Nope. You cannot when this is single hop EBGP session at least on C and J
vendors and may I also include Z and Q open-source routing daemons to the
list
as well. :) I think I'll include E vendor to this behaviour list as well.
There are two notable differences between an ebgp multihop session and a
single
hop session:
1. Multihop session sets outgoing BGP packet TTL to <hopcount> defined by
the user[1].[2]
2. Single hop session, as a security precaution verifies the next-hop
attribute delievered by the remote peer. If the nexthop is different
than
local connected network where peering is being executed at, it will be
denied due as a martian. Setting nexthop via outbound route-map on a
single
hop session will cause remote peer to drop the prefix due to martian
or unknown nexthop. Setting the peering to ebgp-multihop will allow the
peer to accept next-hop out of the connected net.
[1]: Also dependent on the OS itself. IOS is fine, some vendor OSes in
general
automatically react to the situation and tune their control plane's outgoing
system TTL (i.e. sysctl -w net.inet.ip.ttl=255) if needed.
[2]: Because of outgoing TTL change, by using ebgp-multihop 255, one can
perform
GTSM peering protection at the line card by using Receive Path ACL as a way
to protect the peering session. Cisco also introduced new option called
'ttl-security' but it can also be performed by using ebgp-multihop 255 + LC
filter.
-J
-- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net############################################################
Building on 40 Years of Leadership - As a global communications leader with 40 years of experience, Intelsat helps service providers, broadcasters, corporations and governments deliver information and entertainment anywhere in the world, instantly, securely and reliably.
############################################################ This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Intelsat, Ltd. and its subsidiaries. ############################################################
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:36 GMT-3