Hi there, I would like to ask some skilled expert, if the restrictions presented in this feature : http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti_mvpn/configuration/15-s/imc-mvpn-15-s-book/imc_mc_vpn_extranet.html definitely apply. I'm about to decide, whether or not to test something deeply or to point my focus somewhere else (and possibly save the time). Situation : - We have source PE and receiver PE. Single MVPN, single MDT with PIM-SSM inside (some mcast range, non-default, used). Everything works. - on receiver PE, we add another (stub) MVRF, import routes from original MVRF, again SSM defined for VRF alike - it works (clients in new MVRF, source in original MVRF). - actually, as we don't have native IGMPv3 endpoints signalling sources, we need to map somehow on PE edge for mcast sources. As we do provide some 500 mcast groups, each of own source IP, static mapping is out of mind, DNS can be used (we are about to test yet) - may the DNS be not option for some reason for somebody, but don't admit it much, I imagine use of RP to get the PIM SM working for this case, placed at source PE in original MVRF, so (*, G) will be signalled in parallel between PEs in original MVRF, possibly new MVRF enjoying this also.. Questions : - can this RP be functional at source PE (or not at all per restrictions), as demanded to avoid SPT (not to mess with SSM declaration and be at the source LAN directly) ? - can this RP be reached while SSM range is declared on receiver PE for original MVRF only and not new MVRF ? (may be a stupid question as I feel it, but somehow believe that PIM (*, G) Join from new MVRF could make it into original MVRF on its way to RP "unnoticed" :-DD) Thanks for a reply ;-) BR Peter ... View more

Hi there, I need an urgent help. After intensive study of EEM for 1,5d before and experimenting today, I can't get why the EEM applets does not work the way they reasonably should. I want to grasp the dependancies, etc. Why for these 2 scripts : event manager applet first  event none  action 1   set a1 "xxxxx"  action 1.1 puts "1. $a1"  action 2   wait 3  action 3   policy second  action 4   puts "2. $a1" event manager applet second  event none sync no  action 1 puts "sub - $a1" I get this result : host#even manager run first 1. xxxxx 2. xxxxx *May 12 12:01:21.183: %HA_EM-6-LOG: second: sub - 0 where: 1) the  second applet is not called from first while it's running (I know about maxrun that could set an assured timerange). A detailed log shows : host#debug event manager server scheduling host#event mana run first 1. xxxxx *May 12 12:03:52.976: EEM server schedules one event: policy_type=applet epc=0x25B42A3C. *May 12 12:03:52.976: fh_set_epc_pid: EEM callback policy first has been scheduled to run. fdid: 16 sn: 140 jobid: 3522. xxxxx *May 12 12:03:55.980: EEM server schedules one event: policy_type=applet epc=0x25D7BBB8. *May 12 12:03:55.980: fh_io_ipc_msg: EEM callback policy first has ended with normal exit status of 0x0 *May 12 12:03:55.980: EEM: server decrements in use thread: jobid=352 rule id=2 in use thread=1. *May 12 12:03:55.980: EEM server schedules scripts *May 12 12:03:55.980: fh_set_epc_pid: EEM callback policy second has been scheduled to run. fdid: 16 sn: 141 jobid: 353 *May 12 12:03:55.984: %HA_EM-6-LOG: second: sub - 0 *May 12 12:03:55.984: fh_io_ipc_msg: EEM callback policy second has ended with normal exit status of 0x0 *May 12 12:03:55.984: EEM: server decrements in use thread: jobid=353 rule id=2 in use thread=0. *May 12 12:03:55.984: EEM server schedules scripts host# 2) if I don't set "sync no" in second, the first event takes 30s (besides that 3s wait), what relates to some "default" timer of event detector 30, even more than def. 20s for maxrun ?!? WTH? 3) I have read that variable changes among applets can be propagated only via config. change of them (or in TCL totally).. this was to test it, but I still hoped if step 1 was OK, it could work also. So, who can explain steps 1 and 2 to me, I'm yet amazed that there are almost none topics on "action policy" issue (to me). Thank you very much may some reactions come. BR Peter ... View more