RE: Peice of ADVICE from EXPERTS , 3 days left for LAB !! I

Dear ALL,
This is I could only find out , nothing is helping up !!
the REGISTER-STOPED MESSAGE is sent across by the RP, but the MDT-PE tunnel
router is not forwarding it to the CLient and I can clearly see that the
CLIENT is stuck into the REGISTERING state.
I am sharing the logs of the PE , first we dont have the default route and the
multicast works fine, register-stop message is delieverd and the other one is
one when the deffault route is injected !!
 Please HELP ME ON THIS !!

Logs when Multicast WOrks

03:32:26: MRT(0): RPF lookup for 18.18.0.8[0.0.0.0] (18.18.0.8) returned
FastEthernet0/0.89 18.18.89.8
03:32:29: MRT(0): set min mtu for (18.18.0.7, 234.5.6.7) 1514->1514
03:32:29: MRT(0): set min mtu for (18.18.0.8, 234.5.6.7) 1514->1514
03:32:29: MRT(0): set min mtu for (18.18.0.9, 234.5.6.7) 1500->1500
03:32:29: MRT(0): set min mtu for (18.18.0.8, 234.5.6.7) 1514->1514
03:32:29: MRT(0): set min mtu for (18.18.0.8, 234.44.44.44) 0->0
03:32:29: MRT(0): set min mtu for (0.0.0.0, 224.0.1.40) 1514->1514
03:32:32: MRT(0): RPF lookup for 18.18.0.7[0.0.0.0] (18.18.0.7) returned
FastEthernet0/0.79 18.18.79.7
03:32:32: MRT(0): RPF lookup for 18.18.0.8[0.0.0.0] (18.18.0.8) returned
FastEthernet0/0.89 18.18.89.8
03:32:32: MRT(0): RPF lookup for 18.18.0.9[0.0.0.0] (18.18.0.9) returned
Loopback0 18.18.0.9
03:32:32: MRT(0): RPF lookup for 18.18.0.8[0.0.0.0] (18.18.0.8) returned
FastEthernet0/0.89 18.18.89.8
03:32:32: IP(0): s=18.18.0.9 (Loopback0) d=234.5.6.7 (FastEthernet0/0.79)
id=45, ttl=255, prot=47, len=78(78), mforward
03:32:32: IP(0): s=18.18.0.9 (Loopback0) d=234.5.6.7 (FastEthernet0/0.89)
id=45, ttl=255, prot=47, len=78(78), mforward
03:32:35: PIM(0): Building Periodic Join/Prune message for 234.5.6.7
03:32:35: PIM(0): Insert (*,234.5.6.7) join in nbr 18.18.89.8's queue
03:32:35: PIM(0): Insert (18.18.0.7,234.5.6.7) sgr prune in nbr 18.18.89.8's
queue
03:32:35: PIM(0): Insert (18.18.0.7,234.5.6.7) join in nbr 18.18.79.7's queue
03:32:35: PIM(0): Insert (18.18.0.8,234.5.6.7) join in nbr 18.18.89.8's queue
03:32:35: PIM(0): Insert (18.18.0.9,234.5.6.7) sgr prune in nbr 18.18.89.8's
queue
03:32:35: PIM(0): Building Join/Prune packet for nbr 18.18.79.7
03:32:35: PIM(0): Adding v2 (18.18.0.7/32, 234.5.6.7), S-bit Join
03:32:35: PIM(0): Send v2 join/prune to 18.18.79.7 (FastEthernet0/0.79)
03:32:35: PIM(0): Building Join/Prune packet for nbr 18.18.89.8
03:32:35: PIM(0): Adding v2 (18.18.0.8/32, 234.5.6.7), WC-bit, RPT-bit, S-bit
Join
03:32:35: PIM(0): Adding v2 (18.18.0.8/32, 234.5.6.7), S-bit Join
03:32:35: PIM(0): Adding v2 (18.18.0.7/32, 234.5.6.7), RPT-bit, S-bit Prune
03:32:35: PIM(0): Adding v2 (18.18.0.9/32, 234.5.6.7), RPT-bit, S-bit Prune
03:32:35: PIM(0): Send v2 join/prune to 18.18.89.8 (FastEthernet0/0.89)
03:32:37: MRT(0): RPF lookup for 18.18.0.8[0.0.0.0] (18.18.0.8) returned
FastEthernet0/0.89 18.18.89.8
03:32:39: MRT(0): set min mtu for (18.18.0.7, 234.5.6.7) 1514->1514
03:32:39: MRT(0): set min mtu for (18.18.0.8, 234.5.6.7) 1514->1514
03:32:39: MRT(0): set min mtu for (18.18.0.9, 234.5.6.7) 1500->1500
03:32:39: MRT(0): set min mtu for (18.18.0.8, 234.5.6.7) 1514->1514
03:32:39: MRT(0): set min mtu for (18.18.0.8, 234.44.44.44) 0->0
03:32:39: MRT(0): set min mtu for (0.0.0.0, 224.0.1.40) 1514->1514
03:32:42: MRT(0): RPF lookup for 18.18.0.7[0.0.0.0] (18.18.0.7) returned
FastEthernet0/0.79 18.18.79.7
03:32:42: MRT(0): RPF lookup for 18.18.0.8[0.0.0.0] (18.18.0.8) returned
FastEthernet0/0.89 18.18.89.8
03:32:42: MRT(0): RPF lookup for 18.18.0.9[0.0.0.0] (18.18.0.9) returned
Loopback0 18.18.0.9
03:32:42: MRT(0): RPF lookup for 18.18.0.8[0.0.0.0] (18.18.0.8) returned
FastEthernet0/0.89 18.18.89.8un all
All possible debugging has been turned off

Logs when the default pauses the multicasts

03:33:55: PIM(0): Received RP-Reachable on FastEthernet0/0.89 from 18.18.0.8
03:33:55: PIM(0): Received RP-Reachable on FastEthernet0/0.89 from 18.18.0.8
03:33:55: for group 234.5.6.7
03:33:55: PIM(0): Update RP expiration timer (270 sec) for 234.5.6.7
03:33:57: MRT(0): RPF lookup for 18.18.0.8[0.0.0.0] (18.18.0.8) returned
FastEthernet0/0.89 18.18.89.8
03:33:59: MRT(0): set min mtu for (18.18.0.7, 234.5.6.7) 1514->1514
03:33:59: MRT(0): set min mtu for (18.18.0.8, 234.5.6.7) 1514->1514
03:33:59: MRT(0): set min mtu for (18.18.0.9, 234.5.6.7) 1500->1500
03:33:59: MRT(0): set min mtu for (18.18.0.8, 234.5.6.7) 1514->1514
03:33:59: MRT(0): set min mtu for (18.18.0.8, 234.44.44.44) 0->0
03:33:59: MRT(0): set min mtu for (0.0.0.0, 224.0.1.40) 1514->1514
03:34:00: IP(0): s=18.18.0.9 (Loopback0) d=234.5.6.7 (FastEthernet0/0.79)
id=64, ttl=255, prot=47, len=78(78), mforward
03:34:00: IP(0): s=18.18.0.9 (Loopback0) d=234.5.6.7 (FastEthernet0/0.89)
id=64, ttl=255, prot=47, len=78(78), mforward
03:34:02: MRT(0): RPF lookup for 18.18.0.7[0.0.0.0] (18.18.0.7) returned
FastEthernet0/0.79 18.18.79.7
03:34:02: MRT(0): RPF lookup for 18.18.0.8[0.0.0.0] (18.18.0.8) returned
FastEthernet0/0.89 18.18.89.8
03:34:02: MRT(0): RPF lookup for 18.18.0.9[0.0.0.0] (18.18.0.9) returned
Loopback0 18.18.0.9
03:34:02: MRT(0): RPF lookup for 18.18.0.8[0.0.0.0] (18.18.0.8) returned
FastEthernet0/0.89 18.18.89.8un all
03:34:07: MRT(0): RPF lookup for 18.18.0.8[0.0.0.0] (18.18.0.8) returned
FastEthernet0/0.89 18.18.89.8
03:34:09: MRT(0): Update (*,224.0.1.40), RPF /0.0.0.0
03:34:09: MRT(0): Update Loopback0/224.0.1.40 in the olist of (*, 224.0.1.40),
Forward state - MAC not built
03:34:09: MRT(0): Update (*,224.0.1.40), RPF /0.0.0.0
03:34:09: MRT(0): Update Loopback0/224.0.1.40 in the olist of (*, 224.0.1.40),
Forward state - MAC not built
03:34:09: MRT(0): set min mtu for (18.18.0.7, 234.5.6.7) 1514->1514
03:34:09: MRT(0): set min mtu for (18.18.0.8, 234.5.6.7) 1514->1514
03:34:09: MRT(0): set min mtu for (18.18.0.9, 234.5.6.7) 1500->1500
03:34:09: MRT(0): set min mtu for (18.18.0.8, 234.5.6.7) 1514->1514
03:34:09: MRT(0): set min mtu for (18.18.0.8, 234.44.44.44) 0->0un all
All possible debugging has been turned off
R9#
03:34:09: MRT(0): set min mtu for (0.0.0.0, 224.0.1.40) 1514->1514un all
All possible debugging has been turned off
=============================================================================
===========

> Date: Sun, 6 Feb 2011 14:51:04 -0500
> From: swm_at_emanon.com
> To: togunsina_at_gmail.com
> CC: ccielab_at_groupstudy.com
> Subject: Re: Peice of ADVICE from EXPERTS , 3 days left for LAB !!
>
> I have to do something to shake my brain up every now and then. :)
> Thanks!
>
> Scott Morris, CCIEx4 (R&S/ISP-Dial/Security/Service Provider) #4713,
>
> CCDE #2009::D, JNCIE-M #153, JNCIE-ER #102, CISSP, et al.
>
> CCSI #21903, JNCI-M, JNCI-ER
>
> swm_at_emanon.com
>
> Knowledge is power.
>
> Power corrupts.
>
> Study hard and be Eeeeviiiil......
>
> On 2/6/11 10:40 AM, Tolulope Ogunsina wrote:
>
> I noticed a slight change in your signature :)
> I guess that means you are now a Dual JNCIE. Combined with being a Quad
CCIE and a CCDE!
> Congrats!
> Best Regards, Tolulope Ogunsina, CCIE x2 (R&S|Sec)
>
> -----Original Message-----
> From: Scott Morris <swm_at_emanon.com> Sender: nobody_at_groupstudy.com
Date: Sun, 06 Feb 2011 10:01:57
> To: <ccielab_at_groupstudy.com> Reply-To: Scott Morris <swm_at_emanon.com>
Subject: Re: Peice of ADVICE from EXPERTS , 3 days left for LAB !!
>
> Remember that a "bug in IOS on GNS3" is completely different than a "bug
> in IOS". Things that you are presented with in the lab are
> (intentionally) not brand new technologies.... They've been around for
> a while, and the exams have gone through internal testing with multiple
> people to assure that they do actually work.
>
> Is it possible to trigger a bug they hadn't anticipated? Sure, because
> your ENTIRE config may be different than what they did, and you may do
> one thing that affects another. If you suspect anything like that,
> involve the proctor ASAP. They may tell you to go look at your configs
> again (which typically will tell you that they know what you did wrong
> because they've seen it several times before, and it's self-induced).
> If you still can't find it, let them know (nicely!) why you think it's a
> bug and what you've done. If they agree, they will kick you off your
> rack for a little while and will look at your routers/configs and test
> it. If it is a bug, they'll let you know and you will likely get lost
> time back (if you spent three hours doing this, good luck on that!) but
> if they find it's your problem, you lose the time.
>
> You may also decide to skip something any move on if it's not critical
> (or band-aid it if it is critical) so that you know exactly which points
> you have lost.
>
> That's all part of your time management strategy. But generally
> speaking you SHOULDN'T run into bugs.
>
> Best of luck to you!
>
> *Scott Morris*, CCIE/x4/ (R&S/ISP-Dial/Security/Service Provider) #4713,
>
> CCDE #2009::D, JNCIE-M #153, JNCIE-ER #102, CISSP, et al.
>
> CCSI #21903, JNCI-M, JNCI-ER
> swm_at_emanon.com
>
> Knowledge is power.
>
> Power corrupts.
>
> Study hard and be Eeeeviiiil......
>
> On 2/6/11 4:46 AM, Asfer Shah wrote:
>
> Just one query, what do you guys suggest, because everyone is saying
that
> this
> is a BUG in CISCO IOS
> so in that case what should a person do ?
>
> 1. Just paste the standard working configs verify the solution one by
one ,and
> come out of the lab.
> 2. Do a work around which may deduct the marks because both the
technologies
> don't work together at the same time
> 3. ask the proctor ? because he must know the bug , but again he can
make your
> day worst by guiding you into a wrong way ?
> 4. Just drop one Section, lets say the internet and dont risk the
entire
>
> MULTICAST because of that 0.0.0.0 default route :(
>
> please reply back since I have less then a week now :(, I hope I don't
> encounter into this situation in the real LAB ?
>
> From: s_asfar_at_hotmail.com To:
scott_ccie_list_at_it-ag.com CC: ccielab_at_groupstudy.com Subject:
RE: No SOLUTION till DATE for this SCNERIO ???? Challenging
>
> MULTICAST TASK ?? Please ADVICE
>
> Date: Sun, 6 Feb 2011 06:37:15 +0000
>
> Thanks SCOTT,
> Just one query, what do you guys suggest, because everyone is saying
that
>
> this
>
> is a BUG in CISCO IOS
> so in that case what should a person do ?
>
> 1. Just paste the standard working configs verify the solution one by
one ,
> and come out of the lab.
> 2. Do a work around which may deduct the marks because both the
>
> technologies
>
> don't work together at the same time
> 3. ask the proctor ? because he must know the bug , but again he can
make
>
> your
>
> day worst by guiding you into a wrong way ?
> 4. Just drop one Section, lets say the internet and dont risk the
entire
> MULTICAST because of that 0.0.0.0 default route :(
>
> please reply back since I have less then a week now :(, I hope I
don't
> encounter into this situation in the real LAB ?
>
>
=============================================================================
>
> =====================================
>
> CC: markom_at_ipexpert.com ;
ccielab_at_groupstudy.com From: scott_ccie_list_at_it-ag.com
To: s_asfar_at_hotmail.com Subject: Re: No SOLUTION till DATE for
this SCNERIO ???? Challenging
>
> MULTICAST TASK ?? Please help
>
> Date: Thu, 3 Feb 2011 17:19:57 -0700
>
> Oh, and also:
>
> Best luck with your rapidly approaching lab date!!
>
> ____________________________________________
> There are only 10 types of people in the world:
> Those who understand binary and those who do not...
>
> On Feb 3, 2011, at 5:07 , Scott M Vermillion wrote:
>
> So I brushed up a little bit on my draft-rosen stuff this
afternoon
> (been nearly three years since I even thought about that mess!)
and
> then had a closer look at your configs. In truth, it will
probably
> take an SP CCIE or SP CCIE candidate to weigh in and help you out
but
> I will be happy to try. At the very least, I still feel very
strong
> in general mcast, if not MDT, specifically.
>
> Are you perchance running this in a Dynamips environment? If so,
I'd
> love to see that .net file. Also, you said you could share
further
> details, which would be most helpful. Probably more so to an SP
type
> than and R&S guy like myself but the more detail you post, the
more
> likely you are to entice someone knowledgeable into the problem!
;-)
>
> ____________________________________________
> There are only 10 types of people in the world:
> Those who understand binary and those who do not...
>
> On Feb 2, 2011, at 7:31 , Asfer Shah wrote:
>
> Thanks
> Scoottt, I surely will try to check the tutorials but the
problem is
> that Its
> very basic thing which is not coming up ?
> I am trying to run the Multicast in INTRA-AS between my two
sites(R9
> and
> R7/R8) connected via MPLS - VPN's . (R4 is RP and client & R5
is
> SOURCE)
> Everything runs smoothly unless, I introduce the default route
from
> the (R6)
> which is the internet gateway for my PE's of ABC Vpn's.
>
> Whenever the default route is injected my PE outgoing interface
> donot point
> towards the tunnel and starts to follow the 0.0.0.0 source !!
which
> breaks my
> multicast communication and messes everything !
> I can share the details with you even further, I discussed this
> scenerio will
> couple of other CCIE's but somehow no one has managed to answer
my
> solution ?
> thanks
>
> CC: markom_at_ipexpert.com ;
ccielab_at_groupstudy.com From: scott_ccie_list_at_it-ag.com
To: s_asfar_at_hotmail.com Subject: Re: No SOLUTION till
DATE for this SCNERIO ???? Challenging
> MULTICAST
> TASK ?? Please help
> Date: Wed, 2 Feb 2011 11:17:11 -0700
>
> So it looks as if you've got some vendor's full-scale SP lab up
and
> running
> there. Lots of layers to an onion like that which are not going
to
> be readily
> apparent with just a glance over the configs. It's also not
evident
> from your
> text exactly what was working before the introduction of the
default
> route
> came along and broke things. I see you've got a couple of 'ip
igmp
> join-group' commands on your CEs but it's not clear to me what
you
> were
> pinging - and from where - that worked and then later ceased
> working. What
> mcast troubleshooting have you done thus far?
> I try to keep my posts as vendor-neutral as possible but if you
> google
> "multicast troubleshooting" you will find a couple of very, very
good
> tutorials out there. If you follow a logical process of
validating
> all of
> your various control and data plane RPF checks, etc, you are
bound
> to find the
> problem for yourself quickly...
> ____________________________________________There are only 10
types
> of people
> in the world:
> Those who understand binary and those who do not...
> On Feb 2, 2011, at 2:50 , Asfer Shah wrote:
> thanks for the quick Reply, Actually I am appearing in les than
a
> week time
> and I am failing to understand this buG !!
> nothing much I could figure out !!!
> I am hell stuck,since either multcast or Internet will wok at a
> single time
> !!
>
> CE1 is dual homed to PE5 and PE3, we have three GRE (MDT)
tunnels
> between PE2
> , PE 5 and PE3
> thanks
>
>
|--------------------------
> PE5-----
> -----
> |
> |
>
>
INT---------PE1--------PE2--------------------------PE3--------CE1
> | |
> | |
> PE4 CE2
>
> From: markom_at_ipexpert.com Date:
Wed, 2 Feb 2011 10:16:40 +0100
> Subject: Re: No SOLUTION till DATE for this SCNERIO ????
Challenging
>
> MULTICAST TASK ?? Please help
>
> To: s_asfar_at_hotmail.com CC:
bmcgahan_at_ine.com ; scott_ccie_list_at_it-ag.com
;
>
> ccielab_at_groupstudy.com
>
> ;
>
> narbikk_at_gmail.com
>
> Can you please post all the relevant configurations to the
list so
> we
> can actually troubleshoot it? :-)
>
> --
> Marko Milivojevic - CCIE #18427
> Senior Technical Instructor - IPexpert
>
> FREE CCIE training: http://bit.ly/vLecture
> Mailto: markom_at_ipexpert.com
Telephone: +1.810.326.1444
> Web: http://www.ipexpert.com/
> On Wed, Feb 2, 2011 at 09:03, Asfer Shah
<s_asfar_at_hotmail.com> wrote:
>
> Hello ,
> I have a Query to which no one have answered so far ??
>
> PE2-PE3 are in AS20 and are MP-iBGP neighbor to each other.
> CE1 and CE2 are two sites connected to PE2 and PE3
respectively
> talking
> through the MPLS VPN cloud.
> The multicast distribution trees are also configured and the
Intra-
> AS
> multicast end-to-end is working smoothly fine between
CE1-CE2.
>
> I have the below topology in which I have a trouble.
>
> INT---------PE1--------PE2-------PE3--------CE1
> | |
> | |
> PE4 CE2
>
> Now,I have PE1 in AS 10 which is gateway to the internet and
is
> peering
>
> with
>
> PE2 for ipv4 (add-fam) only.
> I have PE4 in (AS30) which is peering with PE1 for both ipv4
and
> vpnv4
> (add-families)
> PE4 is Multihop Mp-eBGP neighbor to both the PE2 and PE3.
>
> PE1 is advertising the internet (0.0.0.0 in vpnv4 add
family) to
> PE4 and
>
> then
>
> PE4 is throwing it to PE2 and PE3
> After manipulating the Next-Hop , PE2 and PE3 do watch the
internet
>
> default
>
> vpnv4 route 0.0.0.0 coming from PE1 and they do access the
internet
>
> easily.
>
> At this point when I check back the multicast between CE1
and
> CE2 , it
>
> will
>
> stop working and the traffic is dropped
> The momnet , I remove the 0.0.0.0 route adver in the vpnv4
from
> PE1 , my
> multicast will run perfectly fine.
>
> There is PIM running between PE1 PE2 and PE4 but no solution
to the
>
> problem
>
> till date !!
> Can you please help me in this special problem ???
>
> Blogs and organic groups at
http://www.ccie.net
>
>
Received on Mon Feb 07 2011 - 08:41:12 ART