Re: No SOLUTION till DATE for this SCNERIO ???? Challenging

>also this is why I reffer to the 0.0.0.0 path , if you look at the
path below debug ip mpacket output which R9 is following
>00:15:47: IP(0): s=172.16.0.5 (FastEthernet0/0.59) d=239.255.4.4
(FastEthernet0/0.69) id=27, ttl=253, prot=1, len=114(100), not RPF
interface

Ah, well, now at least I understand what you were saying before! ;-)
Yes, that does seem strange, especially given the 'sh ip mroute vrf
ABC2' output on that same router (R9/PE2) - it would seem to contain a
valid entry with the correct RPF interface, yet above you see "not RPF
interface" for this incoming traffic. And then the part where
"(FastEthernet0/0.69)" follows the "d=239.2455.4.4," with the former
not being part of the VRF and does not coincide with what you see in
the mcast routing table (which again seems correct, with the Tun0
interface appearing in the OIL). I'm not clear that this is a
"registration problem," per se, since R9/PE2 is almost certainly never
going to send registration toward the RP so long as it regards the
incoming traffic - for whatever reason - as falling outside of the
VRF. At least that's what I think based on the below - perhaps a true
SP type with real-world MDT experience has a better idea!

OK, what strange things have you tried as far as mcast
troubleshooting? For example, have you tried placing a static mroute
on R9/PE2 towards 172.16.0.5 inside VRF ABC2? You shouldn't need to
but obviously something is amiss, so stuff like that is certainly
worth the mere few minutes it would take to try. I would also be
giving a close "before & after" look at the MDT at each node to see if
any subtle changes are taking place there. But again with that "not
RPF interface" bit, it would seem the failure/issue is localized to R9/
PE2. And RPF is always a great place to start when it comes to
troubleshooting mcast...

____________________________________________
There are only 10 types of people in the world:
Those who understand binary and those who do not...

On Feb 6, 2011, at 7:09 , Asfer Shah wrote:

> Thanks Scott for the reply !
> well man I do agree to what you say about people having different
> experiences will always have different suggestions and at the same
> time leaving something unattended in the exam which you do know how
> to make it work is also not a good idea. But my friend , as you
> mentioned is there is one very famous BUG which everyone do know. My
> couple of friends have been through the same exam , they
> encountered the same thing in the lab also but they have the CCIE
> Number with them.
> Yes, you are also right about the fact that these labs are there
> since long time but the problem I am facing is in the newest lab?
> which just got introduced two to three months ago.
> I hardly see people facing that exam in their first attempt and hope
> that I dont face the same exam in my attempt on th 9th of this month.
>
> Well as you have mentioned below, I have attached the outputs of the
> outgoing interface when ever the default route is coming into
> picture, you can clearly say that my Client R5 is stuck into the
> Registering state because its not flowing into the MDT Tunnel and is
> flowing towards the default route injected path.
>
> My one friend faced the same lab yesterday and he got 0 in the
> Multicast Section. I dont know what has to be done now ??
> Please find the attachment and advise, since its only a day before I
> am going to sit in the exam !!
>
> Client (when the defatul route is not injected,client cannot use the
> internet at this moment)
>
> R5#ping 197.68.1.254
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 197.68.1.254, timeout is 2 seconds:
> .....
> Success rate is 0 percent (0/5)
>
> R5#
>
> R5#ping 239.255.4.4 re 5
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 239.255.4.4, timeout is 2 seconds:
> .
> Reply to request 1 from 172.16.48.4, 216 ms
> Reply to request 1 from 172.16.48.4, 216 ms
> Reply to request 2 from 172.16.48.4, 204 ms
> Reply to request 2 from 172.16.48.4, 204 ms
> Reply to request 3 from 172.16.48.4, 120 ms
> Reply to request 3 from 172.16.48.4, 120 ms
> Reply to request 4 from 172.16.48.4, 176 ms
> Reply to request 4 from 172.16.48.4, 180 ms
> R5#
>
> R5#sh ip mroute
> IP Multicast Routing Table
> Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C -
> Connected,
> L - Local, P - Pruned, R - RP-bit set, F - Register flag,
> T - SPT-bit set, J - Join SPT, M - MSDP created entry,
> X - Proxy Join Timer Running, A - Candidate for MSDP
> Advertisement,
> U - URD, I - Received Source Specific Host Report,
> Z - Multicast Tunnel, z - MDT-data group sender,
> Y - Joined MDT-data group, y - Sending to MDT-data group
> Outgoing interface flags: H - Hardware switched, A - Assert winner
> Timers: Uptime/Expires
> Interface state: Interface, Next-Hop or VCD, State/Mode
>
> (*, 239.255.4.4), 00:00:23/stopped, RP 172.16.0.4, flags: SPF
> Incoming interface: Ethernet0/0.59, RPF nbr 172.16.59.9
> Outgoing interface list: Null
>
> (172.16.0.5, 239.255.4.4), 00:00:23/00:03:22, flags: FT
> Incoming interface: Loopback0, RPF nbr 0.0.0.0
> Outgoing interface list:
> Ethernet0/0.59, Forward/Sparse, 00:00:22/00:03:07
>
> (*, 224.0.1.40), 00:08:49/00:02:54, RP 0.0.0.0, flags: DCL
> Incoming interface: Null, RPF nbr 0.0.0.0
> Outgoing interface list:
> Loopback0, Forward/Sparse, 00:08:49/00:02:54
> =========================================
> PE (when the defatul route is not injected,client cannot use the
> internet at this moment)
>
> R9#sh ip mroute vrf ABC2
> IP Multicast Routing Table
> Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C -
> Connected,
> L - Local, P - Pruned, R - RP-bit set, F - Register flag,
> T - SPT-bit set, J - Join SPT, M - MSDP created entry,
> X - Proxy Join Timer Running, A - Candidate for MSDP
> Advertisement,
> U - URD, I - Received Source Specific Host Report, Z -
> Multicast Tunnel
> Y - Joined MDT-data group, y - Sending to MDT-data group
> Outgoing interface flags: H - Hardware switched, A - Assert winner
> Timers: Uptime/Expires
> Interface state: Interface, Next-Hop or VCD, State/Mode
>
> (*, 239.255.4.4), 00:01:26/stopped, RP 172.16.0.4, flags: SPF
> Incoming interface: Tunnel0, RPF nbr 18.18.0.7
> Outgoing interface list: Null
>
> (172.16.0.5, 239.255.4.4), 00:01:25/00:02:21, flags: T
> Incoming interface: FastEthernet0/0.59, RPF nbr 172.16.59.5
> Outgoing interface list:
> Tunnel0, Forward/Sparse, 00:01:25/00:03:04
>
> (172.16.59.5, 239.255.4.4), 00:01:26/00:02:21, flags: FT
> Incoming interface: FastEthernet0/0.59, RPF nbr 0.0.0.0
> Outgoing interface list:
> Tunnel0, Forward/Sparse, 00:01:25/00:03:04
>
> (*, 224.0.1.40), 00:09:46/00:02:03, RP 0.0.0.0, flags: DCL
> Incoming interface: Null, RPF nbr 0.0.0.0
> Outgoing interface list:
> Loopback1, Forward/Sparse, 00:09:44/00:02:03
> ============================================================
> Client (when the defatul route is injected,client can use the
> internet at this moment)
> R5#ping 197.68.1.254
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 197.68.1.254, timeout is 2 seconds:
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max =
> 24/58/160 ms
> R5#
>
> R5#ping 239.255.4.4 re 5
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 239.255.4.4, timeout is 2 seconds:
> .....
> R5#
>
> R5#sh ip mroute
> IP Multicast Routing Table
> Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C -
> Connected,
> L - Local, P - Pruned, R - RP-bit set, F - Register flag,
> T - SPT-bit set, J - Join SPT, M - MSDP created entry,
> X - Proxy Join Timer Running, A - Candidate for MSDP
> Advertisement,
> U - URD, I - Received Source Specific Host Report,
> Z - Multicast Tunnel, z - MDT-data group sender,
> Y - Joined MDT-data group, y - Sending to MDT-data group
> Outgoing interface flags: H - Hardware switched, A - Assert winner
> Timers: Uptime/Expires
> Interface state: Interface, Next-Hop or VCD, State/Mode
>
> (*, 239.255.4.4), 00:05:40/stopped, RP 172.16.0.4, flags: SPF
> Incoming interface: Ethernet0/0.59, RPF nbr 172.16.59.9
> Outgoing interface list: Null
>
> (172.16.0.5, 239.255.4.4), 00:00:22/00:03:15, flags: FT
> Incoming interface: Loopback0, RPF nbr 0.0.0.0, Registering
> Outgoing interface list:
> Ethernet0/0.59, Forward/Sparse, 00:00:22/00:03:07
>
> (*, 224.0.1.40), 00:14:06/00:02:31, RP 0.0.0.0, flags: DCL
> Incoming interface: Null, RPF nbr 0.0.0.0
> Outgoing interface list:
> Loopback0, Forward/Sparse, 00:14:06/00:02:31
>
> R5#
> ============
>
> PE (when the defatul route is injected,client can use the internet
> at this moment)
>
> R9#sh ip mroute vrf ABC2
> IP Multicast Routing Table
> Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C -
> Connected,
> L - Local, P - Pruned, R - RP-bit set, F - Register flag,
> T - SPT-bit set, J - Join SPT, M - MSDP created entry,
> X - Proxy Join Timer Running, A - Candidate for MSDP
> Advertisement,
> U - URD, I - Received Source Specific Host Report, Z -
> Multicast Tunnel
> Y - Joined MDT-data group, y - Sending to MDT-data group
> Outgoing interface flags: H - Hardware switched, A - Assert winner
> Timers: Uptime/Expires
> Interface state: Interface, Next-Hop or VCD, State/Mode
>
> (*, 239.255.4.4), 00:05:57/stopped, RP 172.16.0.4, flags: SP
> Incoming interface: Tunnel0, RPF nbr 18.18.0.7
> Outgoing interface list: Null
>
> (172.16.0.5, 239.255.4.4), 00:00:38/00:02:51, flags:
> Incoming interface: FastEthernet0/0.59, RPF nbr 172.16.59.5
> Outgoing interface list:
> Tunnel0, Forward/Sparse, 00:00:38/00:03:29
>
> (*, 224.0.1.40), 00:14:17/00:02:34, RP 0.0.0.0, flags: DCL
> Incoming interface: Null, RPF nbr 0.0.0.0
> Outgoing interface list:
> Loopback1, Forward/Sparse, 00:14:16/00:02:34
>
> R9#
>
>
> also this is why I reffer to the 0.0.0.0 path , if you look at the
> path below debug ip mpacket output which R9 is following
> 00:15:47: IP(0): s=172.16.0.5 (FastEthernet0/0.59) d=239.255.4.4
> (FastEthernet0/0.69) id=27, ttl=253, prot=1, len=114(100), not RPF
> interface
>
> Please if you are aware of the solution for this registerrin problem
> I will be highly delightful to see the results working here before I
> enter the lab
> thanks
> CC: 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 ADVICE
> Date: Sun, 6 Feb 2011 11:56:24 -0700
>
> Well my approach would be number 3. Experiences here vary widely
> but I found that explaining - very fully - what my dilemma was to
> the proctor was sometimes (but not necessarily always) helpful. And
> I would be surprised to see a task in the lab that was unsolvable.
> The SP track has been around awhile in its current state and I would
> think all bugs would have been exorcised by now.
>
> I'm always very, very skeptical that something is a bug. I did find
> one mcast bug in Dynamips and it was independently verified to truly
> be a bug but to my knowledge it was never resolved. But it had
> nothing to do with draft-rosen or the presence /absence of a default
> route, so it's unlikely that you're up against that. Have you tried
> different IOS?
>
> I still think there's lots you can do to try to resolve this. What
> if it isn't a bug at all? As close as you are to your lab date, you
> don't want to obsess over one single issue, but on the other hand
> you don't want to potentially leave points on the table by ignoring
> it. Have you at least determined whether or not it's your MDT
> that's breaking or just your mcast state within the VRF? I didn't
> fully understand the part where you said something about an outgoing
> interface pointing towards the default route. I would love to see
> the various 'sh ip mroute' before and after, etc.
>
> Again, best wishes one way or the other...
>
> (planning on attending a Super Bowl party so will be offline for the
> rest of the day starting shortly but will check back again tomorrow)
>
> ____________________________________________
> There are only 10 types of people in the world:
> Those who understand binary and those who do not...
>
>
> On Feb 5, 2011, at 11:37 , Asfer Shah wrote:
>
> 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
> > >>>>
> > >>>>
> _______________________________________________________________________
> > >>>> Subscription information may be found at:
> > >>>> http://www.groupstudy.com/list/CCIELab.html
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >> <CE1.cfg><CE2.cfg><PE1.cfg><PE2.cfg><PE3.cfg><PE4.cfg><PE5.cfg>
> > >>
> > >>
> > >> Blogs and organic groups at http://www.ccie.net
> > >>
> > >>
> _______________________________________________________________________
> > >> Subscription information may be found at:
> > >> http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> > > Blogs and organic groups at http://www.ccie.net
> > >
> > >
> _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> >
> _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Mon Feb 07 2011 - 12:26:55 ART