> 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: [email protected]
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 [email protected]
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 [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
