From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Sun Oct 26 2003 - 21:54:10 GMT-3
Dt,
I'm not sure what "shouldn't" you're referencing, but let's take
the following scenario:
Same setup as before, R1 is the hub on the NBMA segment using
either a main interface or a multipoint subinterface (effectively the
same). R1, R2, and R3 are all on the same IP subnet. Regardless of the
interface types that R2 and R3 use, broadcast and multicast traffic
cannot be passed between the spokes.
When a router is routing IP, an IP broadcast will never be
forwarded from one interface to another. I mention 'when a router is
routing IP' because a broadcast *can* be forwarded between interfaces,
but only if the router is bridging IP. When routing multicast, a
multicast feed cannot be sent back out the interface it was received on.
First let me elaborate on the first statement about broadcast
packets.
R2#
Interface Serial0
Ip address 10.0.0.2 255.0.0.0
Encapsulation frame-relay
Frame-relay map ip 10.0.0.1 201 broadcast
Frame-relay map ip 10.0.0.3 201
Notice in the above config I am not adding the 'broadcast'
keyword onto the second frame-relay mapping statement. When a broadcast
or multicast packet comes to a multipoint non-broadcast interface, it is
replicated as a layer 2 unicast out any circuits which have the
broadcast keyword attached. Note that the layer 3 broadcast/multicast
destination address does not change, but the layer 2 address does.
Unlike a true 'broadcast' media such as Ethernet, the packet has to be
sent multiple times. If a broadcast or multicast packet comes to the
above interface, it will be replicated out PVC 201. Suppose that we
change our config to read as follows:
R2#
Interface Serial0
Ip address 10.0.0.2 255.0.0.0
Encapsulation frame-relay
Frame-relay map ip 10.0.0.1 201 broadcast
Frame-relay map ip 10.0.0.3 201 broadcast
Now since we have two broadcast keywords, any multicast or
broadcast traffic that arrives at this interface will be sent out PVC
201 *twice*. Note that the layer 3 address of the packet will not
change (read one is *not* destined for 10.0.0.1 nor is the other
destined for 10.0.0.3). Suppose that R2 sends a broadcast packet out
this interface. R1 will receive two copies of this packet, and not
forward either of them (assuming it's routing IP).
*Note: It is common that you will see the above type of configuration on
both CCO and many of the commercial labs out there, but it is *NOT*
correct to do so. If you configure your network like this, you are
effectively unnecessarily doubling the amount broadcast/multicast
traffic on this segment.
Now onto the multicast: Suppose a multicast feed is transiting R2's
NBMA segment, and there is a host on R3 that wants to receive it. When
R1 receives the feed, it does an RPF check on it. The RPF check looks
for two things. First, the interface that the stream was received on
must be the unicast outgoing interface for the source address. Second,
the outgoing interface must not be the same as the incoming interface.
In the above situation, when R1 received the feed, the incoming and
outgoing interfaces will be the same, and therefore the RPF check will
fail. This is an inherent design flaw of logical hub and spoke NBMA.
In order to resolve this problem, we can do two things:
1. As I mentioned in the previous post, use point to point IP subnets
over the network
2. Use GRE tunneling to transport multicast directly between the spokes
While GRE tunneling will work, it will add unnecessarily overhead with
the GRE header. Ideally, using p2p IP subnets would be the preferred
solution. However, depending on the requirements, this may not be an
option in the actual CCIE lab.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 708-362-1418 (Outside the US and Canada)
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> ccie2be
> Sent: Sunday, October 26, 2003 5:32 PM
> To: ccielab@groupstudy.com; 'Hunt Lee'; Brian McGahan
> Subject: Re: multicast issues
>
> Hi Brian,
>
> Yes, everything you've said makes alot of sense. And, thanks for
getting
> to
> us on this. But, I'm not 100% clear if "shouldn't" translate to can't.
>
> Taking your example, where R1 is the hub, and R2 and R3 have mapping
> statements to each other and R2 is attached to the multicast source,
are
> you
> saying that R3 won't get the multicast stream or are you saying that
> because
> of all the mapping statements, it's not a good idea to set things up
this
> way because it's not scalable?
>
> thanks, dt
> ----- Original Message -----
> From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> To: "'ccie2be'" <ccie2be@nyc.rr.com>; "'Hunt Lee'"
> <hunt_lee@bigpond.net.au>; <ccielab@groupstudy.com>
> Sent: Sunday, October 26, 2003 5:09 PM
> Subject: RE: multicast issues
>
>
> > Yes, the answer is to simply not use logical hub and spoke
> > networks. While a physical hub and spoke network is a perfectly
valid
> > setup, a logical hub and spoke network introduces *many* design
> > problems.
> >
> > For example, suppose we have 3 devices on a hub-and-spoke
> > Frame-Relay network. Note that the encapsulation does not matter,
as
> > Frame-Relay, ATM, ISDN, and X25 will all perform the same at a
> > fundamental level.
> >
> > R1
> > / \
> > R2 R3
> >
> > R1, R2, and R3 share the IP subnet 10.0.0.0/8, however, R1 is
> > the only device that has a physical connection to all endpoints of
the
> > network. Since R2 and R3 are on the same IP subnet, they
automatically
> > assume that they have direct connectivity, however this is not the
case.
> > This results in R2 and R3 having to have additional layer 3 to layer
2
> > resolution statements pointing out the same layer 2 circiut.
Example:
> >
> > R2#
> > Interface Serial0
> > Ip address 10.0.0.2 255.0.0.0
> > Encapsulation frame-relay
> > Frame-relay map ip 10.0.0.1 201 broadcast
> > Frame-relay map ip 10.0.0.3 201
> >
> > As the amount of devices on the segment grow, keeping track of
> > layer 3 to layer 2 resolution quickly gets out of control. A simple
> > solution to this problem is to use point-to-point interfaces on the
> > endpoints:
> >
> > R2#
> > Interface Serial0
> > Encapsulation frame-relay
> > !
> > interface serial0.1 point-to-point
> > ip address 10.0.0.2 255.0.0.0
> > frame-relay interface-dlci 201
> >
> > In the above case, there is no need for layer 3 to layer 2
> > resolution, since the only circuit available on the interface is VC
201.
> > While this will ease management a bit, it still does not resolve the
> > original issue. Now let's take the idea a step further, and use all
> > point to point circuits:
> >
> > R1#
> > Interface Serial0
> > Encapsulation frame-relay
> > !
> > interface Serial0.1 point-to-point
> > ip address 12.0.0.1 255.0.0.0
> > frame-relay interface-dlci 102
> > !
> > interface Serial0.2 point-to-point
> > ip address 13.0.0.1 255.0.0.0
> > frame-relay interface-dlci 103
> >
> > In this case, protocol resolution at layer 2 will not be
> > necessary on any circuit. Any traffic passed between non-directly
> > connected endpoints now must be resolved through a layer 3 routing
> > protocol.
> >
> > Note that this is more of a design consideration, and arguably
> > does not directly relate to the CCIE lab. While it is commonly said
> > that the CCIE lab is not a 'design' test, and does not relate to
best
> > practices, this is not necessarily true. In order to understand
best
> > practices in network design, you must first understand what is NOT
good
> > design. By testing you on a horribly designed network,
theoretically
> > the CCIE lab should help you to understand what good network design
is,
> > and show you issues that will impact your design. Make sense?
> >
> >
> > HTH,
> >
> > Brian McGahan, CCIE #8593
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987
> > Direct: 708-362-1418 (Outside the US and Canada)
> >
> >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
Behalf
> > Of
> > > ccie2be
> > > Sent: Sunday, October 26, 2003 1:28 PM
> > > To: Brian McGahan; 'Hunt Lee'; ccielab@groupstudy.com
> > > Subject: Re: multicast issues
> > >
> > > Hi Brian,
> > >
> > > You raised an interesting issue I had never thought about before -
> > that of
> > > the rpf check failing when source is on a spoke of a multipoint
> > interface.
> > >
> > > In general, is there good way of handling such situations? And,
are
> > such
> > > situations handled differently for F/R vs ATM?
> > >
> > > Thanks, dt
> > >
> > >
> > > ----- Original Message -----
> > > From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> > > To: "'Hunt Lee'" <hunt_lee@bigpond.net.au>;
<ccielab@groupstudy.com>
> > > Sent: Sunday, October 26, 2003 2:13 PM
> > > Subject: RE: multicast issues
> > >
> > >
> > > > Hunt,
> > > >
> > > > I'm assuming that you're trying to create two point to point
> > > > subnets by using GRE tunneling? What does your unicast routing
> > table
> > > > look like? Without seeing your complete config, I'm going to
guess
> > that
> > > > you're still getting an RPF failure on your hub router. The
point
> > of
> > > > creating two p2p subnets is to avoid the situation when your
> > incoming
> > > > interface and outgoing interface for the multicast feed are the
same
> > > > interface. You can think of this kind of a like split-horizon
for
> > > > multicast. Paste your unicast and multicast routing tables.
> > > >
> > > >
> > > > Brian McGahan, CCIE #8593
> > > > bmcgahan@internetworkexpert.com
> > > >
> > > > Internetwork Expert, Inc.
> > > > http://www.InternetworkExpert.com
> > > > Toll Free: 877-224-8987
> > > > Direct: 708-362-1418 (Outside the US and Canada)
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> > Behalf
> > > > Of
> > > > > Hunt Lee
> > > > > Sent: Saturday, October 25, 2003 9:35 PM
> > > > > To: ccielab@groupstudy.com
> > > > > Subject: multicast issues
> > > > >
> > > > > Is there a big secret to this?
> > > > >
> > > > > I have:
> > > > > R1 (spoke) R2 (spoke)
> > > > > \ /
> > > > > R3 (hub - multipoint subinterface)
> > > > >
> > > > > My R3 is MA.
> > > > >
> > > > > R1 is Auto-RP for 225.1.1.1
> > > > >
> > > > > R2 is Auto-RP for 235.1.1.1
> > > > >
> > > > > Yet R1 can't ping R2's 235.1.1.1, nor vice versa... But R3 can
> > ping
> > > > both
> > > > > 225.1.1.1 & 235.1.1.1 fine...
> > > > >
> > > > > R1
> > > > >
> > > > > interface Tunnel0
> > > > > ip unnumbered Loopback0
> > > > > ip pim sparse-dense-mode
> > > > > tunnel source Loopback0
> > > > > tunnel destination 192.1.1.1
> > > > >
> > > > > interface Serial0
> > > > > ip address 10.1.1.1 255.255.255.0
> > > > > ip pim sparse-dense-mode
> > > > >
> > > > > !
> > > > > router ospf 1
> > > > > passive-interface Tunnel0
> > > > >
> > > > > ip pim send-rp-announce Loopback0 scope 5 group-list rp-1
> > > > > !
> > > > > !
> > > > > ip access-list standard rp-1
> > > > > permit host 225.1.1.1
> > > > > !
> > > > >
> > > > > R2
> > > > >
> > > > > interface Tunnel0
> > > > > ip unnumbered Loopback0
> > > > > ip pim sparse-dense-mode
> > > > > tunnel source Loopback0
> > > > > tunnel destination 192.2.2.2
> > > > >
> > > > > interface Serial0
> > > > > ip address 10.2.2.2 255.255.255.0
> > > > > ip pim sparse-dense-mode
> > > > >
> > > > > router ospf 1
> > > > > passive-interface Tunnel0
> > > > >
> > > > > ip pim send-rp-announce Loopback0 scope 5 group-list rp-2
> > > > > !
> > > > > !
> > > > > ip access-list standard rp-2
> > > > > permit host 235.1.1.1
> > > > >
> > > > > R5
> > > > >
> > > > > !
> > > > > interface Serial0.1 multipoint
> > > > > ip address 10.5.5.5 255.255.255.0
> > > > > ip pim sparse-dense-mode
> > > > >
> > > > >
> > > > > interface Tunnel0
> > > > > ip unnumbered Loopback0
> > > > > ip pim sparse-dense-mode
> > > > > tunnel source Loopback0
> > > > > tunnel destination 10.1.1.1
> > > > > !
> > > > > interface Tunnel1
> > > > > ip unnumbered Loopback0
> > > > > ip pim sparse-dense-mode
> > > > > tunnel source Loopback0
> > > > > tunnel destination 10.2.2.2
> > > > >
> > > > > ip pim send-rp-discovery Loopback0 scope 5
> > > > >
> > > > > Thanks,
> > > > > H.
> > > > >
> > > > >
> > > >
> >
This archive was generated by hypermail 2.1.4 : Mon Nov 24 2003 - 07:53:08 GMT-3