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.vitkov...@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.vitkov...@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 postmas...@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. > > > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/