From: Sean C (Upp_and_Upp@hotmail.com)
Date: Thu Feb 17 2005 - 12:55:35 GMT-3
Hello,
Thanks for everyone's responses. I appreciate the effort and time.
My original topology was "hub-and-spoke multipoint frame topology, and on
the hub and spokes I place both IPv6 addresses and IPv6 link-local addresses
with the appropriate frame maps for the neighbors".
After seeing everyone's responses - my question is this: if using the
link-local IPv6 address on the neighbor statement for the BGP neighbor on
the frame connection, I can't see how the 'update-source' will work since
the config will say to update-source of the frame-interface (which would be
the same frame-interface used if using the IPv6 unicast address in the first
place).
IOW - if I have a router with:
int ser 0/0.123 multipoint
ipv6 address 1111:1
ipv6 address 1122:2 link-local
frame map ipv6 1111:1 103 <--this router's IPv6 unicast address
frame map ipv6 1122:2 103 <--this router's IPv6 link-local address
frame map ipv6 1111:3 103 broad <--other router's unicast address
frame map ipv6 3333:3 103 broad <--other router's link-local address
on the BGP process (if using link-local as the neighbor)
neighbor 3333:3 update-source serial 0/0.123
How will the router know to use the link-local address to advertise rather
than the unicast address - they're both under the same s0/0.123 interface?
Again, appreciate everyone's time on this,
Sean
----- Original Message -----
From: <Jongsoo.Kim@Intelsat.com>
To: <bsinclair@netmasterclass.net>; <swm@emanon.com>; <ccie2be@nyc.rr.com>;
<Upp_and_Upp@hotmail.com>; <ccielab@groupstudy.com>
Sent: Thursday, February 17, 2005 10:08 AM
Subject: RE: BGP Neighbors for IPv6
> You won't have problem peering itself via link-local subnet.
> If you add one more router in your example, you may see some non-sense
> problem (of IPv6) of BGP routes using link-local address as next-hop
> attribute.
>
> In your example, R2 and R4 are direct ibgp peers.
> But as eBGP will show the problem much clearer, let's say R2 and R4 are
> direct eBGP peers using link-local address and let's say R4 has another
> iBGP
> peer R1.
> Now, if the below subject route-map is not used, R1 can't learn R2's eBGP
> routes via R4 iBGP peer.
> R1 can't resolve the next-hop address of R2 because it is link-local
> address
> between R2 and R4, which is not supposed to be used outside of R2-R4 link.
>
>
> Regards
>
>
> Jongsoo
>
>
> -----Original Message-----
> From: Bob Sinclair [mailto:bsinclair@netmasterclass.net]
> Sent: Wednesday, 16 February, 2005 9:41 PM
> To: Kim, Jongsoo; swm@emanon.com; ccie2be@nyc.rr.com;
> Upp_and_Upp@hotmail.com; ccielab@groupstudy.com
> Subject: Re: BGP Neighbors for IPv6
>
>
> Jongsoo,
>
> The only problem I have with that document is that it does not appear to
> describe the actual behavior of the IOS as I have observed it. Please see
> my earlier post, which showed good peers between routers using link-local
> address, update-source and no route-map. Please let me know what I am
> missing.
>
> Bob Sinclair
> CCIE #10427, CCSI 30427, CISSP
> www.netmasterclass.net
>
>
> ----- Original Message -----
> From: <Jongsoo.Kim@Intelsat.com>
> To: <swm@emanon.com>; <ccie2be@nyc.rr.com>;
> <bsinclair@netmasterclass.net>;
> <Upp_and_Upp@hotmail.com>; <ccielab@groupstudy.com>
> Sent: Wednesday, February 16, 2005 8:32 PM
> Subject: RE: BGP Neighbors for IPv6
>
>
>> For IPv6 BGP peering using link local address, I believe the answer is
>> update-source AND( not or) route-map changing next-hop address to global
>> unicast. Both are required.
>> Update-source will tell BGP process to send link-local address out of
>> which
>> interfaces as multiple interface can have the same link-local address.
>> And route-map changing next-hop address to global unicast will solve
>> next-hop resolution problem of iBGP peers.
>>
>> Here is the summary of cisco web site
>>
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/ipv6
>> _c/sa_bgpv6.htm#wp1037072
>>
>> "Configuring IPv6 multiprotocol BGP between two IPv6 routers (peers)
>> using
>> link-local addresses requires that the interface for the neighbor be
>> identified by using the update-source router configuration command and
>> that
>> a route map be configured to set an IPv6 global next hop."
>>
>>
>> Regards
>>
>>
>> Jongsoo
>>
>>
>> -----Original Message-----
>> From: Scott Morris [mailto:swm@emanon.com]
>> Sent: Wednesday, 16 February, 2005 7:47 PM
>> To: Kim, Jongsoo; ccie2be@nyc.rr.com; bsinclair@netmasterclass.net;
>> Upp_and_Upp@hotmail.com; ccielab@groupstudy.com
>> Subject: RE: BGP Neighbors for IPv6
>>
>>
>> So update-source may be an answer, or perhaps next-hop-self?
>>
>> Scott
>>
>> -----Original Message-----
>> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>> Jongsoo.Kim@Intelsat.com
>> Sent: Wednesday, February 16, 2005 6:19 PM
>> To: ccie2be@nyc.rr.com; bsinclair@netmasterclass.net;
>> Upp_and_Upp@hotmail.com; ccielab@groupstudy.com
>> Subject: RE: BGP Neighbors for IPv6
>>
>> I think a route-map changing next-hop address to global unicast is
>> necessary
>> if link-local address is used for BGP peering.
>> Otherwise, other BGP peers not part of link-local segment has no way to
>> resolve link-local next-hop address for BGP route.
>> A router can have identical link-local address for multiple interface,
>> which
>> is one of reasons why update source is necessary.
>>
>>
>> Regards
>>
>> Jongsoo
>>
>>
>> -----Original Message-----
>> From: ccie2be [mailto:ccie2be@nyc.rr.com]
>> Sent: Wednesday, 16 February, 2005 4:54 PM
>> To: Bob Sinclair; Sean C; ccielab@groupstudy.com
>> Subject: Re: BGP Neighbors for IPv6
>>
>>
>> Hmmm, interesting.
>>
>> So, why do you think the VoD lesson on ipv6 bgp makes a point of using a
>> route-map to set the next hop address to
>>
>> an ipv6 global unicast address if it's not required?
>>
>> Is that a best practice for some reason?
>>
>> Thanks, Tim
>> ----- Original Message -----
>> From: "Bob Sinclair" <bsinclair@netmasterclass.net>
>> To: "ccie2be" <ccie2be@nyc.rr.com>; "Sean C" <Upp_and_Upp@hotmail.com>;
>> <ccielab@groupstudy.com>
>> Sent: Wednesday, February 16, 2005 4:19 PM
>> Subject: Re: BGP Neighbors for IPv6
>>
>>
>>> Hi Tim,
>>>
>>> Since the router always prompts for an outgoing interface when the
>>> destination is link-local, it would make sense that it needs more
>>> "direction" in order use the link-local address. I was able to get BGP
>>> peers to come up using the configuration below. It peers to the far
>>> link-local address and uses the outgoing interface in the update-source
>>> command:
>>>
>>> On R2:
>>>
>>> router bgp 24
>>> no synchronization
>>> bgp log-neighbor-changes
>>> neighbor FE80::204:C1FF:FE8E:C40 remote-as 24
>>> neighbor FE80::204:C1FF:FE8E:C40 update-source FastEthernet0/0
>>> no auto-summary
>>> !
>>> address-family ipv4 multicast
>>> no auto-summary
>>> no synchronization
>>> exit-address-family
>>> !
>>> address-family ipv6
>>> neighbor FE80::204:C1FF:FE8E:C40 activate
>>> exit-address-family
>>>
>>> On R4:
>>>
>>> router bgp 24
>>> no synchronization
>>> bgp log-neighbor-changes
>>> neighbor FE80::2D0:58FF:FE95:C8E1 remote-as 24
>>> neighbor FE80::2D0:58FF:FE95:C8E1 update-source FastEthernet0/0
>>> no auto-summary
>>> !
>>> address-family ipv4 multicast
>>> no auto-summary
>>> no synchronization
>>> exit-address-family
>>> !
>>> address-family ipv6
>>> neighbor FE80::2D0:58FF:FE95:C8E1 activate
>>> exit-address-family
>>>
>>> Result:
>>>
>>> R4#sh bgp ipv6 summary
>>> BGP router identifier 172.16.104.1, local AS number 24
>>> BGP table version is 1, main routing table version 1
>>>
>>> Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
>>> State/PfxRcd
>>> FE80::2D0:58FF:FE95:C8E1
>>> 4 24 10 10 1 0 0 00:06:20
>> 0
>>> R4#
>>>
>>> Note good peer!!
>>>
>>> Bob Sinclair
>>> CCIE #10427, CCSI 30427, CISSP
>>> www.netmasterclass.net
>>>
>>>
>>> ----- Original Message -----
>>> From: "ccie2be" <ccie2be@nyc.rr.com>
>>> To: "Bob Sinclair" <bsinclair@netmasterclass.net>; "Sean C"
>>> <Upp_and_Upp@hotmail.com>; <ccielab@groupstudy.com>
>>> Sent: Wednesday, February 16, 2005 3:31 PM
>>> Subject: Re: BGP Neighbors for IPv6
>>>
>>>
>>> > There's a VoD on Cisco's PEC site that talked about this.
>>> >
>>> > I watched it yesterday.
>>> >
>>> > In the example they used, if a link-local address was used in the
>> neighbor
>>> > <ipv6 -LL-addr> remote command, 2 other things were also required:
>>> >
>>> > 1) the neighbor <ipv6 LL-addr> source-update command and
>>> >
>>> > 2) a route-map that sets the next hop to the ipv6 unicast address for
>> that
>>> > neighbor.
>>> >
>>> > I'm not able to try that at the moment, but would you agree?
>>> >
>>> > Tim
>>> > ----- Original Message -----
>>> > From: "Bob Sinclair" <bsinclair@netmasterclass.net>
>>> > To: "Sean C" <Upp_and_Upp@hotmail.com>; <ccielab@groupstudy.com>
>>> > Sent: Wednesday, February 16, 2005 2:52 PM
>>> > Subject: Re: BGP Neighbors for IPv6
>>> >
>>> >
>>> >> Hi Sean,
>>> >>
>>> >> A certain gentleman of our mutual acquaintance assures me that either
>> the
>>> >> routable or link-local address could be used, if the neighbor is
>> directly
>>> >> connected. If you do use the link-local, however, you will need to
>>> >> use
>>> >> update-source. Give it a shot.
>>> >>
>>> >> HTH,
>>> >>
>>> >> Bob Sinclair
>>> >> CCIE #10427, CCSI 30427, CISSP
>>> >> www.netmasterclass.net
>>> >>
>>> >>
>>> >> ----- Original Message -----
>>> >> From: "Sean C" <Upp_and_Upp@hotmail.com>
>>> >> To: <ccielab@groupstudy.com>
>>> >> Sent: Wednesday, February 16, 2005 1:24 PM
>>> >> Subject: BGP Neighbors for IPv6
>>> >>
>>> >>
>>> >> > Hello,
>>> >> >
>>> >> > I have a question but it's not from any particular vendor's
>>> >> > practice
>>> > test.
>>> >> > If
>>> >> > I'm given a hub-and-spoke multipoint frame topology, and on the hub
>> and
>>> >> > spokes
>>> >> > I place both IPv6 addresses and IPv6 link-local addresses with the
>>> >> > appropriate
>>> >> > frame maps for the neighbors, if I configure BGP over the topology:
>>> >> > 1-do I need to apply the IPv6 address or the link-local address on
>> the
>>> >> > neighbor statements under the BGP process and address-family?
>>> >> > 2-is there a difference if the neighbors are iBGP vs. eBGP?
>>> >> > 3-can I use either address? Or, perhaps if using the link-local
>>> >> > address
>>> > I
>>> >> > need to update-source?
>>> >> >
>>> >> > I'm trying to keep this a simple question (if possible). Hope this
>>> > makes
>>> >> > sense, and thanks in advance.
>>> >> > Sean
>>> >> >
>>> >> >
>> _______________________________________________________________________
>>> >> > 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
>>> >
>>> > _______________________________________________________________________
>>> > 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
>>
>> ############################################################
>>
>> 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.
>> ############################################################
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>> ############################################################
>>
>> 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.
>> ############################################################
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>
> ############################################################
>
> 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 : Thu Mar 03 2005 - 08:51:22 GMT-3