From: James (james@towardex.com)
Date: Mon Aug 09 2004 - 20:58:26 GMT-3
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
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:36 GMT-3