Re: IE Lab 6 Task 6.2

From: Rich Collins (nilsi2002@gmail.com)
Date: Mon Apr 28 2008 - 12:13:02 ART


I labbed it up using my own hub and spokes and different addresses than you
so it probably doesn't make sense for me to show you my configuration.

Steps:
On both spokes use "passive tunnel" under the ospf routing processes. I used
for tunnel source and destination the serial interfaces like you. A static
mroute on R2 back to the source of the ping like the tunnel interface on
R4. pim dense-mode on both tunnel interfaces.

Just the multicast packets will take the tunnel route (encapsulation) and
not unicast packets.

-Rich

On 4/27/08, Ahsan Mohiuddin <ahsan.mohiuddin@gmail.com> wrote:
>
> Hello Rich,
>
> thanks for taking an interest in my problem. the ip address i am using for
> unnumbered tunnel (loopback) is known via ospf area 0 but its known out the
> serial, and not the tunnel. For example, if I use R4's loopback for the
> unnumbered tunnel (150.1.4.4), R2 knows this address not out the tunnel
> but out the serial (FR) interface going to hub R5. That defeats the purpose
> of the tunnel. it will become clearer when u lab it up.
>
> thanks once again
>
> On Sun, Apr 27, 2008 at 7:21 PM, Rich Collins <nilsi2002@gmail.com> wrote:
>
> > Hi,
> >
> > I will try to lab it up tomorrow. I think that the interfaces you are
> > using for the unnumbered should already be known in the routing table or
> > pick a loopback that is known via a routing protocol.
> >
> > -Rich
> >
> >
> > On 4/26/08, Ahsan Mohiuddin <ahsan.mohiuddin@gmail.com> wrote:
> > >
> > > Hello,
> > >
> > > i just came up with one more possibility. We could run eigrp 20 on R2
> > > and R4's loopback 0 and unnumbered tunnel interfaces. The eigrp routes (to
> > > remote router's loopback) will be preferred over OSPF routes. Thereby, ping
> > > to multicast group from R4 will cause the packets to take the tunnel rather
> > > than the FR cloud. The question is, is it valid to add a routing domain,
> > > which the lab does not ask you to create?
> > >
> > > I have seen IE's solution guide for this lab but apparently it
> > > suggests nothing to overcome this problem. I would be grateful if Brian D.
> > > or Brian M. could shed some light.
> > >
> > > Thanks
> > >
> > > On Sat, Apr 26, 2008 at 8:50 PM, Ahsan Mohiuddin <
> > > ahsan.mohiuddin@gmail.com> wrote:
> > >
> > > > Hello again,
> > > >
> > > > I formed a tunnel between spokes and it works fine when i put ip
> > > > addressing over the tunnel. THat is, I am able to ping mcast addr
> > > > 228.22.22.22 from R4. R2 sees this as a source for this group out
> > > > the tunnel interface.
> > > >
> > > > However, once i use unnumbered on the tunnel, R4 cannot send ping
> > > > packets out the tunnel interface. So, well we are back to square 1; R4 sends
> > > > packets out to to R5 over FR. Since we are running dense mode, ip pim
> > > > nbma-mode is useless and R5 will not forward out the same interface on which
> > > > it received the packets.
> > > >
> > > > Any ideas how to make R2 receive ping packets from R4 over the
> > > > unnumbered tunnel?
> > > > Thanks
> > > >
> > > >
> > > > On Sat, Apr 26, 2008 at 2:08 PM, Ahsan Mohiuddin <
> > > > ahsan.mohiuddin@gmail.com> wrote:
> > > >
> > > > > much thanks.. i wonder why unnumbered never crossed my mind!
> > > > >
> > > > >
> > > > > On Sat, Apr 26, 2008 at 1:55 AM, Rich Collins <nilsi2002@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > yes. Probably you are allowed "ip unnumbered addresses for the
> > > > > > GRE tunnel". You have to then be careful about active routing protocols
> > > > > > which will broadcast/multicast over this tunnel. You might need to declare
> > > > > > the tunnel interface as passive.
> > > > > >
> > > > > > You also most likely will need a static mroute.
> > > > > > Watch for any RFP failures.
> > > > > >
> > > > > > i.e.
> > > > > > *Mar 1 00:31:41.631: IP(0): s=192.168.5.5 (Tunnel1) d=
> > > > > > 228.22.22.22 id=30, ttl=253, prot=1, len=100(100), not RPF
> > > > > > interface
> > > > > >
> > > > > > -Rich
> > > > > >
> > > > > > On 4/25/08, Ahsan Mohiuddin <ahsan.mohiuddin@gmail.com> wrote:
> > > > > > >
> > > > > > > like GRE tunnel? I don't know bcuz the lab instructions
> > > > > > > specifically ask NOT to add any IP Addressing thats not there in the diagram
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Apr 25, 2008 at 8:53 PM, Rich Collins <
> > > > > > > nilsi2002@gmail.com> wrote:
> > > > > > >
> > > > > > > > nbma mode on the hub will not help you with dense-mode since
> > > > > > > > you don't have an explicit join.
> > > > > > > >
> > > > > > > > Maybe one option is to build a pim dense tunnel between the
> > > > > > > > two spokes?
> > > > > > > >
> > > > > > > > -Rich
> > > > > > > >
> > > > > > > >
> > > > > > > > On 4/25/08, Ahsan Mohiuddin <ahsan.mohiuddin@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hello Group,
> > > > > > > > >
> > > > > > > > > I have two FR spokes R2 and R4 connected out R5 (hub)'s
> > > > > > > > > multipoint sub-if
> > > > > > > > > s1/0.245. The network is running PIM sparse-dense. R2 is a
> > > > > > > > > client for group
> > > > > > > > > 228.22.22.22. There is no RP for it, hence its a
> > > > > > > > > dense-mode group. All PIM
> > > > > > > > > routers receive ping replies from the 228.22.22.22 client
> > > > > > > > > (R2), except the
> > > > > > > > > other FR spoke R4. I have already checked for RPF failure
> > > > > > > > > but can't see any.
> > > > > > > > > On R5, I can see interface s1/0.245 as being in the (S,G)
> > > > > > > > > entry's Incoming
> > > > > > > > > interface list but not in the Outgoing list. I have
> > > > > > > > > already added ip pim
> > > > > > > > > nbma-mode under this sub-if, but R4 is unable to ping the
> > > > > > > > > group. ANy
> > > > > > > > > comments are appreciated. P.S. nothing but physical
> > > > > > > > > interfaces is allowed on
> > > > > > > > > both R4 & R2 (FR spokes).
> > > > > > > > >
> > > > > > > > > thanks in adv for your inputs
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Pass the CCIE in six weeks, Guaranteed!
> > > > > > > > > http://www.certscience.com/CCIE
> > > > > > > > >
> > > > > > > > > _______________________________________________________________________
> > > > > > > > > Subscription information may be found at:
> > > > > > > > > http://www.groupstudy.com/list/CCIELab.html

Pass the CCIE in six weeks, Guaranteed!
http://www.certscience.com/CCIE



This archive was generated by hypermail 2.1.4 : Thu May 01 2008 - 08:25:52 ART