From: Rick Shafer \(rishafer\) (rishafer@cisco.com)
Date: Fri Feb 23 2007 - 12:54:52 ART
And yet another scenario where this command can be utilized is when you
have multiple BGP peers on a single network segment.
For instance R1, R2 and R3 are all on a single Ethernet segment in the
same subnet. You want traffic destined for a network on R3 to be
forwarded from R1 to R2 and then finally to R3 as it transits R1 and
R2's AS.
R1 and R2 are iBGP peers in AS 100. R3 is an eBGP peer in AS 1000
peering with both R1 and R2.
When R3 advertises the destination network to R1 and R2, R1 will prefer
the eBGP route. We can modify this behavior by modifying local
preference. Once we have established R2 as the exit point for the AS we
convince R2 to advertise his own interface address as the next hop. By
default he will advertise the interface address of R3 because he knows
they are all on the same segment and he doesn't modify next hop when
advertising to iBGP peers. So even though he is now the preferred exit
point and route learned from him shows up as best in the BGP table
(local preference) traffic will never actually traverse R2.
Summary
When peers are on the same network segment establishing the preferred
exit from the AS with local preference doesn't guarantee traffic will be
forwarded to the iBGP peer if the next hop is not modified. Neighbor
x.x.x.x next-hop-self must be issued in order to actually forward the
traffic to the iBGP peer.
In this scenario reachability would exist without changing the next hop
but the engineered traffic path would not be correct.
See show output: The 3.3.3.0 network is the destination on R3.
R1's BGP table before next-hop-self
BGP table version is 9, local router ID is 172.16.101.1
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
r 3.3.3.0/24 172.16.34.3 0 0 1000 i
r>i 172.16.34.3 0 150 0 1000 i
After next-hop-self
BGP table version is 8, local router ID is 172.16.101.1
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
r 3.3.3.0/24 172.16.34.3 0 0 1000 i
r>i 172.16.34.2 0 150 0 1000 i
Hope this helps,
Rick
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Narbik Kocharians
Sent: Friday, February 23, 2007 2:11 AM
To: Dwi C Taniel
Cc: ccielab@groupstudy.com
Subject: Re: BGP --neighbor x.x.x.x next-hop-self
Well, neighbor next-hop-self is also needed between the EBGP neighbors
when the connection is multipoint and the spokes don't have reachability
to each other, especially in a frame-relay hub and spoke where all
routers are from the same IP address space.
Let's say R1 is the hub and R2 and R3 are the spokes, and R2 and R3 have
an EBGP peer session to R1. When R2 advertises a prefix to R1, it will
set the next hop to be it's own IP address (R2's IP address), when R1
advertises the same prefix to R3, since the interface is a multipoint
interface and the neighbors (R2 and R3) are from the same address space,
R1 does not change the next hop attribute, therefore the spokes (R2 and
R3) will not have reachability to each others IP address, one way to fix
this issue is to configure R1 to change the next hop attribute for it's
clients (R2 and R3).
On 2/22/07, Dwi C Taniel <dc@dwichandra.info> wrote:
>
> ... and here is the example if you needed it (at least I got the idea
> better with this example)
>
> R1 (AS1) --- R2 (AS2) --- R3 (AS2) --- R4 (AS2) --- R5 (AS3) The
> 'neighbor x.x.x.x next-hop-self' would need to be in R2 and R4 for
> their neighbourship with R3 (yes, in some countries they spelled it
> 'neighbour', which give me problem in configuring bgp in the past.
> Thanks to the 'neigh' shortcut that remove this problem)
>
> Thus, R3 would be informed by R2 and R4 for reachability to R1 (AS1)
> and R5 (AS3).
> Without 'next-hop-self', R3 would receive the NLRI (CMIIW for the
> terms as I am still a barbaric network engineer) but did not have the
> 'best' selected (the one with symbol '>' from 'show ip bgp' in R3)
>
> Hope it helps ;)
>
> DC
>
> ========
> http://www.dwichandra.info
> dc@dwichandra.info
> --------
> visit Transformers movie link at
> http://www.dwichandra.info/transformers
> --------
>
>
> On 02/23/2007, "Schulz, Dave" <DSchulz@dpsciences.com> wrote:
>
> > Dennis -
> >
> > When a route is received via ebgp, and passed into ibgp....the next
> > hop is not manipulated. Therefore, the routers within the AS will
> > not know how to reach this next hop (learned by ebgp).
> >
> > By using the next-hop-self command, the AS border router is set as
> > the next hop. This allows the other routers within the AS
> > reachability, since the border router knows how to reach the route
on the next AS.
> >
> >
> > Dave Schulz,
> > Email: dschulz@dpsciences.com
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of dennis lin
> > Sent: Thursday, February 22, 2007 10:13 PM
> > To: ccielab@groupstudy.com
> > Subject: BGP --neighbor x.x.x.x next-hop-self
> >
> > I am quite confused about this BGP command: neighbor
> > x.x.x.xnext-hop-self Do you know under what situation I have to
> > issue this
> > command? Thanks
> >
> >
> > Dennis
> >
> > ____________________________________________________________________
> > ___ Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> > ____________________________________________________________________
> > ___ Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
-- Narbik Kocharians CCIE# 12410 (R&S, SP, Security) CCSI# 30832 Network Learning, Inc. (CCIE class Instructor) www.ccbootcamp.com (CCIE Training)
This archive was generated by hypermail 2.1.4 : Thu Mar 01 2007 - 07:38:48 ART