From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Sun Oct 26 2003 - 19:09:34 GMT-3
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