From: Andrew Bruce Caslow (abcaslow@netmasterclass.net)
Date: Thu Nov 30 2006 - 08:01:02 ART
Hi Antonio,
I agree with Sabrina's answer to your question. Please remember, as a
general rule, the phrase in Sabrina's answer about "using the broadcast
keyword once per DLCI" (emphasis on the "once per DLCI" sub-phrase). Using
the "broadcast" keyword multiple times on multiple frame-relay map
statements referencing the "exact same DLCI" will cause a replication of
broadcasts and multicasts.
When reading Sabrina's conclusion below, your first two configurations are
equivalent. They will both result in transmitting a single copy of any
multicast packet transmitted on either of the DLCI's on the Frame-Relay
interface since one and only one "broadcast" statement is associated with
each DLCI in your set of Frame-Relay map statements.
Again, as Sabrina mentioned, your third configuration will result in the
transmission of two duplicate multicast packets transmitted on either DLCI
on the Frame-Relay interface since two broadcast statements are associated
with each DLCI in your set of Frame-Relay map statements.
Good answers Sabrina! Now, in the spirit of my friend and colleague Mr. Bob
Sinclair, let's attempt to verify this answer. Learning to use the tools of
the IOS to verify and to visualize the operation of a technology will lead
to a better understanding of the technology. So here is one possible proof
of Sabrina's answer.
First, let's supply a simple topology. It will be a simpler topology than
what you had Antonio. Where you had four frame-relay map statements
referencing two DLCI's under the interface you presented in your original
question, we will have two frame-relay map statements referencing one DLCI
under our test interface. Here is a little diagram:
R1 (DLCI 102) ==== FRAME-RELAY ==== R2 (DLCI 201)
And here is our test configuration:
interface Serial0/0
encapsulation frame-relay
ipv6 address 2001:1001::1/64
ipv6 address FE80::1 link-local
ipv6 rip test enable
frame-relay map ipv6 FE80::2 102
frame-relay map ipv6 2001:1001::2 102
end
Like your configuration, we have two frame-relay map statements for our IPv6
implementation: one map statement for R2's link-local address and one for
R2's global unicast address.
Now, notice that, in this initial configuration, no broadcast statements are
referenced on either of these two map statements. This will result in the
suppression of the transmission of all RIPng multicast for IPv6. Let's take
a look at some debug output for this configuration. We have enabled the
following two debug commands:
Debug ipv6 rip
Debug frame packet
Here is the debug:
RIPng: Sending multicast update on Serial0/0 for test
src=FE80::1
dst=FF02::9 (Serial0/0)
sport=521, dport=521, length=52
command=2, version=1, mbz=0, #rte=2
tag=0, metric=1, prefix=2001:1001::/64
tag=0, metric=1, prefix=2001:AAA::/64
Serial0/0: broadcast search
Serial0/0:encaps failed on broadcast for link 79(IPV6) <- * ENCAPS FAILED
As you can see in the last line, the encapsulation failed for transmitting
the packet due to the lack of the broadcast parameter on either of the
frame-relay map statements referencing DLCI 102 in the configuration.
Now, go ahead and add one "broadcast" parameter to one and only one of these
map statements. You will now see that the RIPng update is multicasted out.
Here is the configuration change:
interface Serial0/0
encapsulation frame-relay
ipv6 address 2001:1001::1/64
ipv6 address FE80::1 link-local
ipv6 rip test enable
frame-relay map ipv6 FE80::2 102 broadcast <= CHANGE
frame-relay map ipv6 2001:1001::2 102
end
And now the debug output reflects that the RIPng multicast is transmitted:
tag=0, metric=1, prefix=2001:AAA::/64
RIPng: Sending multicast update on Serial0/0 for test
src=FE80::1
dst=FF02::9 (Serial0/0)
sport=521, dport=521, length=52
command=2, version=1, mbz=0, #rte=2
tag=0, metric=1, prefix=2001:1001::/64
tag=0, metric=1, prefix=2001:AAA::/64
Serial0/0: broadcast search
Serial0/0(o): dlci 102(0x1861), pkt type 0x86DD(IPV6), datagramsize 96
You can alternate the single broadcast parameter between these two map
statements, and as Sabrina, mentioned you will attain equivalent results.
Finally, if you use broadcast parameters on BOTH frame-relay map statemets
in this configuration, two duplicate RIPng multicasts will be transmitted on
DLCI 102:
RIPng: Sending multicast update on Serial0/0 for test
src=FE80::1
dst=FF02::9 (Serial0/0)
sport=521, dport=521, length=52
command=2, version=1, mbz=0, #rte=2
tag=0, metric=1, prefix=2001:1001::/64
tag=0, metric=1, prefix=2001:AAA::/64
Serial0/0: broadcast search
Serial0/0: Broadcast on DLCI 102 link 79
Serial0/0(o): dlci 102(0x1861), pkt type 0x86DD(IPV6), datagramsize 96
Serial0/0(o): dlci 102(0x1861), pkt type 0x86DD(IPV6), datagramsize 96
Serial0/0(o):Pkt sent on dlci 102(0x1861), pkt type
0x86DD(IPV6), datagramsize 96
Serial0/0(o):Pkt sent on dlci 102(0x1861), pkt type
0x86DD(IPV6), datagramsize 96
Notice that only one RIPng update is displayed in the debug output above,
but two duplicate Frame-Relay output messages are generated both referencing
the exact same datagram size.
If you enable debug ipv rip and debug frame packet on the receiving side of
this PVC, you will see two duplicate RIPng updates received. Let's do this:
From R2, the receiving RIPng router:
05:52:38: Serial0/0(i): dlci 201(0x3091), pkt type 0x86DD, datagramsize 96
05:52:38: RIPng: response received from FE80::1 on Serial0/0 for test
05:52:38: src=FE80::1 (Serial0/0)
05:52:38: dst=FF02::9
05:52:38: sport=521, dport=521, length=52
05:52:38: command=2, version=1, mbz=0, #rte=2
05:52:38: tag=0, metric=1, prefix=2001:1001::/64
05:52:38: tag=0, metric=1, prefix=2001:AAA::/64
05:52:38: Serial0/0(i): dlci 201(0x3091), pkt type 0x86DD, datagramsize 96
05:52:38: RIPng: response received from FE80::1 on Serial0/0 for test
05:52:38: src=FE80::1 (Serial0/0)
05:52:38: dst=FF02::9
05:52:38: sport=521, dport=521, length=52
05:52:38: command=2, version=1, mbz=0, #rte=2
05:52:38: tag=0, metric=1, prefix=2001:1001::/64
05:52:38: tag=0, metric=1, prefix=2001:AAA::/64
So there you have it. Just as Sabrina mentioned, two duplicate copies are
sent out the same DLCI.
Proof by IOS Debug! Quod Erat Demonstrandum (Q.E.D)! : )
For any one that is interested in IPv6, we at NMC are working hard on an
IPv6 Class-on-Demand product that will include several hours of video on
demand content, along with on-line quizzes and technology-focused DRILLiT
labs. Anthony Sequiera will be your instructor/host for the VoD series
within this product. If you are looking for more info on IPv6, please
contact us. Our IPv6 Class-on-Demand product will be available later next
month.
HTH,
-Bruce Caslow CCIE #3139
NetMasterClass, LLC
www.netmasterclass.net
A Cisco Learning Partner
PS. As a footnote, the NMC training facility is in the Washington DC area,
near Dulles Airport and next to the Cisco area offices. Since we are in the
Washington DC area, the home of the US Federal government, we are building
out our IPv6 e-learning content well beyond what is needed for the CCIE lab
for many of our government customers. If anyone needs IPv6 training services
beyond what could be found in the R&S CCIE lab, please contact us. Thanks in
advance!
HTH,
-Bruce
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> sabrina pittarel
> Sent: Thursday, November 30, 2006 2:48 AM
> To: Antsnio Soares; ccielab@groupstudy.com
> Subject: Re: IPv6 Over Frame-Relay
>
> Hi Antonio,
> in my understanding the best way of using the broadcast keyword is
> once per DLCI, so it doesn't really matter if you associate it to the map
> statement for the link local or the global address.
> 1) and 2) are equivalent
> 3) will cause the interface to send 2 copies of the same broadcast/mcast
> packet out of the dlci. (2 copies out of 501 and 2 others out of 504)
>
> Sabrina
> ----- Original Message ----
> From: Antsnio Soares <amsoares@convex.pt>
> To:
> ccielab@groupstudy.com
> Sent: Wednesday, November 29, 2006 5:06:48 PM
> Subject:
> IPv6 Over Frame-Relay
>
> Hello Group,
>
> When configuring IPv6 Over Frame-Relay
> in order to support RIPng or OSPFv3,
> i've seen different types of
> configurations related with the broadcast
> option. Suppose that we have R5 as
> the Hub and R1 and R4 as Spokes. For
> example in R5, we have 3 options:
> Option #1:
>
> R5#sh runn int s0/0 | inc ipv6
> ipv6 address 2001:176:1:145::5/64
> ipv6 address FE80::5 link-local
> ipv6 rip ripng enable
> frame-relay map ipv6
> FE80::1 501 broadcast
> frame-relay map ipv6 FE80::4 504 broadcast
> frame-relay
> map ipv6 2001:176:1:145::1 501
> frame-relay map ipv6 2001:176:1:145::4 504
> R5#
> Option #2:
>
> R5#sh runn int s0/0 | inc ipv6
> ipv6 address 2001:176:1:145::5/64
> ipv6 address FE80::5 link-local
> ipv6 rip ripng enable
> frame-relay map ipv6
> FE80::1 501
> frame-relay map ipv6 FE80::4 504
> frame-relay map ipv6
> 2001:176:1:145::1 501 broadcast
> frame-relay map ipv6 2001:176:1:145::4 504
> broadcast
> R5#
>
> Option #3:
>
> R5#sh runn int s0/0 | inc ipv6
> ipv6 address
> 2001:176:1:145::5/64
> ipv6 address FE80::5 link-local
> ipv6 rip ripng enable
> frame-relay map ipv6 FE80::1 501 broadcast
> frame-relay map ipv6 FE80::4 504
> broadcast
> frame-relay map ipv6 2001:176:1:145::1 501 broadcast
> frame-relay
> map ipv6 2001:176:1:145::4 504 broadcast
> R5#
>
> The 3 options are valid but I
> usually choose option #1. The debugs show me
> the following in R5:
>
> RIPng:
> Sending multicast update on Serial0/0 for ripng
> src=FE80::5
> dst=FF02::9 (Serial0/0)
> sport=521, dport=521, length=292
> (...)
>
> We
> know that RIPng updates are sent using the link-local address, in this
> case
> FE80::5. And we know that FF02::9 represents the all-RIP-routers
> multicast
> address. So the router will pick-up the pvc's with broadcast
> capabilities and
> will send these packets.
>
> My question is: which option is recommended and why.
> Thanks,
> AMS
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
> __________________________________________________________________________
> ___
> _______
> Do you Yahoo!?
> Everyone is raving about the all-new Yahoo! Mail beta.
> http://new.mail.yahoo.com
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Dec 01 2006 - 08:05:49 ART