[c-nsp] mVPN Rosen - S,G is not refreshed but *,G is

Mattias Gyllenvarg mattias at gyllenvarg.se
Wed May 25 08:20:01 EDT 2016


Adam,

Thank you for replying.

There is no Data MDT at this point. Correct me if I am wrong but i gather
that it is not necessary so we are working on having basic functionality
right now.




ons 25 maj 2016 kl 13:45 skrev Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk>:

> > Mattias Gyllenvarg
> > Sent: Tuesday, May 24, 2016 2:52 PM
> >
> > Dear All
> >
> > Any input is greatly appreciated!
> >
> > I have two PE ME3600X where one is RP (North) and one is has the customer
> > link (South).
> >
> > North receives a set of TV streams that work perfect locally. But over
> the
> > tunnel interface down to South SOME mroutes on North are not refreshed
> > properly.
> > The *,G is refreshed every minute or so but the S,G is not so it
> times-out and
> > is recreated 3min later.
> >
> > Source [NORTH] --- <mVPNtunnel> --- [South] --- pim --- [vanilla 6500] -
> > Users
> >
> > From North:
> >
> > sh ip mroute vrf Foo-Barf <borking-mroute>
> >
> > (*, M.C.S.T), 02:00:47/00:03:10, RP <North>, flags: S
> >   Incoming interface: Null, RPF nbr 0.0.0.0
> >   Outgoing interface list:
> >     Vlan3713, Forward/Sparse, 02:00:47/00:02:47
> >     Tunnel2, Forward/Sparse, 00:47:09/00:03:10
> >
> > (U.C.S.T, M.C.S.T), 02:00:36/00:10:53, flags: MT
> >   Incoming interface: Vlan1112, RPF nbr <verified source>, Mroute
> >   Outgoing interface list:
> >     Vlan3713, Forward/Sparse, 02:00:36/00:02:47
> >     Tunnel2, Forward/Sparse, 00:02:19/00:01:12
> >
> >
> > ################################
> >
> > Both boxes are running 15.3-3.S3 and are freshly rebooted.
> >
> > I have not found any bug to match the behavior.
> >
> Hmmm, since the (*,G) state is being refreshed the IGMP membership report
> to PIM Join translation should be fine I think.
> -is the south router the only one on the subnet to customer (is it the
> designated forwarder for all groups)?
> -but you can test with static IGMP join on the interface towards the
> receiver, if it helps
>
> Ok so let's assume the PIM Join is generated just fine and hits the RP,
> then RP forwards the join up the tree towards source.
> Source will start sending the stream down via shared tree so receivers on
> south will receive it.
> All this happens via the Default MDT that both routers are part of.
>
> At this point though the m-cast stream triggers the max kbps threshold for
> Default MDT on the north router.
> So the north router should signal to south router which Data MDT it should
> join to keep receiving this stream.
> So in global routing table the south router will join Data MDT m-cast
> group (as designated by north router in BGP update) with source on north
> router.
> -not sure how you have the Data MDT config done (if just one MDT is
> allowed or if other north to south streams sharing a common Default/Data
> MDT with the failed stream are fine, then it's probably not a problem with
> MDTs).
> -there might be some problems with Data MDTs.
>         -maybe reaching max number and tunnel reuse is not working
> properly.
>         -maybe reaching HW limits of the box with regards to Data MDT
> states or any of the HW limits associated with multicast states.
>
> While this switchover from Default to Data MDT is happening or even before
> it happens the designated forwarder (north router) will get the first
> packet and learns the source of the m-cast stream.
> At that moment it will join the source tree sending PIM join towards the
> source (not RP) creating (S,G) states along the path.
> This though happens in the VRF mcast RIB/FIB.
> So depending on which state the MDT trees are in, the (S,G) on south
> router might point to Default or Data MDT tunnel (which hopefully is in the
> same VRF as receiver and you're not doing extranet with tail-end
> replication).
> On north router the resulting (S,G) state should point to the interface
> where source is connected to. (which hopefully is in the same VRF as
> receiver and you're not doing extranet with head-end replication).
> - So I assume on south router the (S,G) states are being refreshed
> correctly by local receivers right?
> - And it's just the north router that doesn't seem to be getting the PIM
> (S,G) joins?
> - You can debug the S,G joins to see if south router is sending them via
> MDT tunnel to north router.
> - And on north router you can verify whether the (S,G) Joins are actually
> received and if yes whether they are accepted.
>
> As you can see there might be two things happening at the same time north
> PE initiating switchover from Default to Data MDT in global routing table
> and south PE (as designated forwarder) switching from shared tree to source
> tree in VRF routing table.
>
>
> adam
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>         Adam Vitkovsky
>         IP Engineer
>
> T:      0333 006 5936
> E:      Adam.Vitkovsky at gamma.co.uk
> W:      www.gamma.co.uk
>
> This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents
> of this email are confidential to the ordinary user of the email address to
> which it was addressed. This email is not intended to create any legal
> relationship. No one else may place any reliance upon it, or copy or
> forward all or any of it in any form (unless otherwise notified). If you
> receive this email in error, please accept our apologies, we would be
> obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or
> email postmaster at gamma.co.uk
>
> Gamma Telecom Limited, a company incorporated in England and Wales, with
> limited liability, with registered number 04340834, and whose registered
> office is at 5 Fleet Place London EC4M 7RD and whose principal place of
> business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
>
>
>


More information about the cisco-nsp mailing list