Mailing List Archive: eBGP multihop

eBGP multihop

Jan 29, 2004, 6:57 AM

Post #1 of 5 (1340 views)

Hi,
Can someone clarify in detail that why do we need to use eBGP multihop/ttl2
when using the famous 'blackholing' technique to discard malicious traffic.
Is it something to do with the nexthop self attribute?

Thanks,
Amjad

**********************************************************************
This e-mail message is confidential and is intended only for the use of the
individual or entity named above and contains information which is or may be
confidential, non-public or legally privileged. Any dissemination or
distribution of this message other than to its intended recipient is
strictly prohibited. If you have received this message in error, please
notify us by email to postmaster@flagtelecom.com immediately and delete the
original message and all copies from all locations in your computer systems.

This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG
Telecom cannot accept liability for any damage which you may sustain as a
result of software viruses.
**********************************************************************

This message has been scanned for viruses by MailControl - www.mailcontrol.com

eBGP multihop [ In reply to ]

gtate at juniper

Jan 29, 2004, 11:47 AM

Post #2 of 5 (1277 views)

Permalink

Hi Khan
You need eBGP multihop/ttl2 if the neighbour address is not on a
directly connected subnet i.e. is two hops away. This has nothing to
do with next-hop-self or black holing traffic.

Could you tell me where you have seen the this I can explain better.
I'm assuming its in our documentation somewhere.

Gary'

On Jan 29, 2004, at 3:51 AM, Khan, Amjad wrote:

> Hi,
> Can someone clarify in detail that why do we need to use eBGP
> multihop/ttl2
> when using the famous 'blackholing' technique to discard malicious
> traffic.
> Is it something to do with the nexthop self attribute?
>
> Thanks,
> Amjad
>
>
>
>
> **********************************************************************
> This e-mail message is confidential and is intended only for the use
> of the
> individual or entity named above and contains information which is or
> may be
> confidential, non-public or legally privileged. Any dissemination or
> distribution of this message other than to its intended recipient is
> strictly prohibited. If you have received this message in error, please
> notify us by email to postmaster@flagtelecom.com immediately and
> delete the
> original message and all copies from all locations in your computer
> systems.
>
>
> This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG
> Telecom cannot accept liability for any damage which you may sustain
> as a
> result of software viruses.
> **********************************************************************
>
>
>
>
>
> This message has been scanned for viruses by MailControl -
> www.mailcontrol.com
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>

eBGP multihop [ In reply to ]

morrowc at ops-netman

Jan 31, 2004, 3:34 AM

Post #3 of 5 (1280 views)

Permalink

On Jan 29, 2004, at 11:51 AM, Khan, Amjad wrote:

> Hi,
> Can someone clarify in detail that why do we need to use eBGP
> multihop/ttl2
> when using the famous 'blackholing' technique to discard malicious
> traffic.
> Is it something to do with the nexthop self attribute?
>

you only require this setting if one of the 2 peers is a cisco :) I
believe its actually explained somewhat at: www.secsup.org though it
might need some better wording or clarification.

eBGP multihop [ In reply to ]

gtate at juniper

Feb 1, 2004, 2:30 PM

Post #4 of 5 (1282 views)

Permalink

http://www.secsup.org/CustomerBlackHole/

If this is indeed the document that you are referring too then this is
only added for consistency with the Cisco solution configuration that
is given. It is not a requirement on the Juniper side and shouldn't
have been added to the document just to make it consistent.

Gary

On Jan 31, 2004, at 12:34 AM, Christopher Morrow wrote:

>
> On Jan 29, 2004, at 11:51 AM, Khan, Amjad wrote:
>
>> Hi,
>> Can someone clarify in detail that why do we need to use eBGP
>> multihop/ttl2
>> when using the famous 'blackholing' technique to discard malicious
>> traffic.
>> Is it something to do with the nexthop self attribute?
>>
>
> you only require this setting if one of the 2 peers is a cisco :) I
> believe its actually explained somewhat at: www.secsup.org though it
> might need some better wording or clarification.
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>

eBGP multihop [ In reply to ]

morrowc at ops-netman

Feb 1, 2004, 3:02 PM

Post #5 of 5 (1301 views)

Permalink

On Feb 1, 2004, at 7:30 PM, Gary Tate wrote:

> http://www.secsup.org/CustomerBlackHole/
>
> If this is indeed the document that you are referring too then this is
> only added for consistency with the Cisco solution configuration that
> is given. It is not a requirement on the Juniper side and shouldn't
> have been added to the document just to make it consistent.
>

certianly its not required for a juniper only solution, or a juniper
provider edge solution :) It should be updated for that contingency, I
believe the original thought was that if the provider side was Cisco
based and thus required the multihop option, the customer side would
also need to be multihop...

after a little test that doesn't seem to be required, so the document
should be updated to reflect that also.

Thanks Gary.

> Gary
>
> On Jan 31, 2004, at 12:34 AM, Christopher Morrow wrote:
>
>>
>> On Jan 29, 2004, at 11:51 AM, Khan, Amjad wrote:
>>
>>> Hi,
>>> Can someone clarify in detail that why do we need to use eBGP
>>> multihop/ttl2
>>> when using the famous 'blackholing' technique to discard malicious
>>> traffic.
>>> Is it something to do with the nexthop self attribute?
>>>
>>
>> you only require this setting if one of the 2 peers is a cisco :) I
>> believe its actually explained somewhat at: www.secsup.org though it
>> might need some better wording or clarification.
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> http://puck.nether.net/mailman/listinfo/juniper-nsp
>>