RE: No SOLUTION till DATE for this SCNERIO ???? Challenging from Asfer Shah on 2011-02-06 (Ccielab archives 02/2011)

From: Asfer Shah <s_asfar_at_hotmail.com>
Date: Mon, 7 Feb 2011 02:09:15 +0000

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#

(*, 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)

(*, 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
> >>>>
> >>>>
Received on Mon Feb 07 2011 - 02:09:15 ART

This archive was generated by hypermail 2.2.0 : Tue Mar 01 2011 - 07:01:49 ART