From: David Luu (wicked01@xxxxxxxxxxxxx)
Date: Sat Jul 06 2002 - 18:38:49 GMT-3
without the update-source command, bgp will use the closest interface, so
in this case it will use 10.1.1.2, the serial interface connecting Router B
to A...
the the ibgp's tcp session would look something like this...
A B B C
172.16.1.1-----10.1.1.2 172.16.1.3-----172.16.1.2
At 09:46 AM 7/6/2002 +0000, kym blair wrote:
>Hunt,
>
>Interesting that A and B peered up. You should have to include "nei
>172.16.1.1 update-source loop 0" on RouterB, or use 10.1.1.2 in the
>neighbor statement on RouterA. I hope someone will explain how this was
>possible without either of those.
>
>Incidentally, Greg is right, peering to the loopback interfaces is easily
>done with iBGP because the routers already know of the peer's loopback
>address via IGP. But it is also common to use the loopback address for
>eBGP peering. It's a good idea if you have two paths between the remote
>AS. You would add two more steps. First, the remote AS would need a
>route to your loopback network in their ip routing table (probably via
>static route or default route) and your router would need a route to their
>loopback network in your routing table in order to make the tcp
>connection. Second, you would need "neighbor X.X.X.X ebgp-multihop 2".
>
>An unrelated suggestion: recommend you always add "bgp router-id X.X.X.X"
>under the bgp routing process, and likewise "router-id X.X.X.X" under the
>ospf routing process since those two must match up. Nothing gets messed
>up if you add another loopback in the future.
>
>HTH, Kym
>
>
>>From: "Justler" <justler@subnetzero.net>
>>Reply-To: "Justler" <justler@subnetzero.net>
>>To: ccielab@groupstudy.com
>>Subject: Re: BGP Command Q
>>Date: Sat, 6 Jul 2002 02:19:47 -0500 (CDT)
>>
>>The command does allow internal BGP sessions to use the specified
>>interface for TCP connections. So in your setup, you're telling Router
>>B that it needs to peer up to Router A's 172 address. Router B on the
>>is told to peer up with IP Address 172.16.1.1 (Router A), but that
>>update-source command on Router A actually tells Router B to peer up w/
>>loopback0 instead, which I believe it decides in the BGP session
>>setup. I think it is mainly used in iBGP, but there could be a use in
>>eBGP that I am not aware of. Someone PLEASE correct me if i'm wrong!
>>Cisco's documentation of this is not very good. I even checked the
>>Internet Routing Architectures book for a detailed explanation with no
>>luck.
>>
>>Greg
>>
>>
>> > Group,
>> >
>> > I have a BGP question and the scenario is as follows.What am i doing
>> > wrong ? Scenario is:
>> >
>> > RTA -- RTB -- RTC
>> >
>> > They are all in the same AS 1.
>> >
>> > RTA's Serial: 10.1.1.1
>> > RTB's Serial: 10.1.1.2 (connecting to RTA)
>> > RTB's Serial: 10.1.2.1 (connecting to RTC)
>> > RTC's Serial: 10.1.2.2
>> >
>> > Each Router also has a Loopback Interface for IBGP connection.
>> >
>> > RTA's Loopback0: 172.16.1.1
>> > RTB's Loopback0: 172.16.1.3
>> > RTC's Loopback0: 172.16.1.2
>> >
>> >
>> > Ok - what I am confused is the BGP command "neighbor x.x.x.x
>> > update-source <interface x>"?? My understanding of the command is
>> > that the router who used this command can specify another interface
>> > to be used for IBGP Neighbor connections.
>> >
>> > So at here, RTA will tell RTB (172.16.1.3) to use RTA's Loopback
>> > interface for IBGP session.
>> >
>> > RTA:-
>> >
>> > router ospf 1
>> > log-adjacency-changes
>> > network 10.1.0.0 0.0.255.255 area 0
>> > network 172.16.1.1 0.0.0.0 area 1
>> > !
>> > router bgp 1
>> > bgp log-neighbor-changes
>> > network 1.0.0.0 mask 255.128.0.0
>> > neighbor 172.16.1.3 remote-as 1
>> > neighbor 172.16.1.3 update-source Loopback0
>> >
>> >
>> > RTB:-
>> >
>> > router ospf 1
>> > log-adjacency-changes
>> > network 10.1.0.0 0.0.255.255 area 0
>> > network 172.16.1.3 0.0.0.0 area 3
>> > !
>> > router bgp 1
>> > no synchronization
>> > bgp log-neighbor-changes
>> > neighbor 172.16.1.1 remote-as 1
>> > neighbor 172.16.1.1 route-reflector-client
>> > neighbor 172.16.1.2 remote-as 1
>> > neighbor 172.16.1.2 update-source Loopback0
>> > neighbor 172.16.1.2 route-reflector-client
>> >
>> >
>> > But at RTB, there is no neighbor update-source statement pointing
>> > back to RTA. Nevertheless, the BGP session still managed to get
>> > established. How can BGP still managed to establish the BGP
>> > connection??
>> >
>> >
>> > RouterB#sh ip bgp summary
>> > BGP router identifier 172.16.1.3, local AS number 1
>> > BGP table version is 3, main routing table version 3
>> > 2 network entries and 2 paths using 266 bytes of memory
>> > 1 BGP path attribute entries using 60 bytes of memory
>> > 0 BGP route-map cache entries using 0 bytes of memory
>> > 0 BGP filter-list cache entries using 0 bytes of memory
>> > BGP activity 4/4 prefixes, 4/2 paths, scan interval 15 secs
>> >
>> > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
>> > State/PfxRcd
>> > 172.16.1.1 4 1 15 13 3 0 0 00:03:52 1
>> > 172.16.1.2 4 1 14 14 3 0 0 00:04:17 1
>> > RouterB#
>> >
>> >
>> > Or is this command only required for EBGP sessions? Anyone with
>> > ideas.
>> >
>> > =====
>> > Thanks in advance for ur time and replies.
>> > Hunt
>> >
>> >
>> > http://www.sold.com.au - SOLD.com.au
>> > - Find yourself a bargain!
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:36:20 GMT-3