From: ccie2be (ccie2be@nyc.rr.com)
Date: Sun Oct 26 2003 - 20:32:27 GMT-3
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.
> > > >
> > > >
> > >
> _______________________________________________________________________
> > > > Please help support GroupStudy by purchasing your study materials
> > > from:
> > > > http://shop.groupstudy.com
> > > >
> > > > Subscription information may be found at:
> > > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> _______________________________________________________________________
> > > Please help support GroupStudy by purchasing your study materials
> from:
> > > http://shop.groupstudy.com
> > >
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> _______________________________________________________________________
> > Please help support GroupStudy by purchasing your study materials
> from:
> > http://shop.groupstudy.com
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon Nov 24 2003 - 07:53:08 GMT-3