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

[Adam Vitkovsky]

> 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.