Re: [c-nsp] Enabling multicast routing on 3750G platform
Use igmp-join if you want the router itself to be a member of the multicast group. You don't need it if you are routing multicast through the router. It's rarely used and only for very specific circumstances, for example if a servers fails if there isn't at least one client joining, etc... Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Lobo Sent: Thursday, January 29, 2015 9:00 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Enabling multicast routing on 3750G platform Problem solved! You guys were right about VLC and its TTL. Turns out there's a bug in the program where changing the TTL in the GUI doesn't affect streaming for some reason. I added a ttl=30 to the string and the stream started flowing to the secondary port. I even changed things back to vlans and it routed perfectly fine. I have a question about one comment that was made regarding the igmp-join command. In all the documentation I've read, it says to put that command on the interfaces that plan on receiving the stream(s). Some comments suggested removing it or not needing it and with my own testing it clearly works fine even without this command. Why is that? This is the final show ip mroute: Switch#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group V - RD Vector, v - Vector Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.255.255.250), 02:45:34/00:02:34, RP 3.3.3.3, flags: SJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Vlan100, Forward/Sparse, 00:00:38/00:02:34 Vlan200, Forward/Sparse, 02:42:59/00:02:32 (*, 239.0.0.1), 02:45:35/stopped, RP 3.3.3.3, flags: SJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Vlan200, Forward/Sparse, 02:42:15/00:02:33 (1.1.1.1, 239.0.0.1), 00:00:40/00:02:58, flags: JT Incoming interface: Vlan100, RPF nbr 0.0.0.0 Outgoing interface list: Vlan200, Forward/Sparse, 00:00:40/00:02:33 (*, 224.0.1.40), 02:45:35/00:02:28, RP 3.3.3.3, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Loopback0, Forward/Sparse, 02:45:36/00:02:27 Switch# Thanks again for the tips everyone! Jose On Thu, Jan 29, 2015 at 7:23 AM, Adam Vitkovsky avitkov...@gammatelecom.com wrote: Hi Lobo, Ok so the SW is indeed a DR on port GigabitEthernet1/0/1 and it's obviously receiving some stream in which case it should create an (s,g) state and send a register msg to the RP and RP should update its group cache (all should be done internally since the DR=RP). However none of this is happening most likely because the switch doesn't like something about the stream (destination mac address, ttl, som security feature,..). Can you do: debug ip pim -to see if it shows why the switch ignores the incoming stream. -or some other techniques to see why the incoming multicast frames are being dropped silently. adam -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Lobo Sent: 29 January 2015 00:57 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Enabling multicast routing on 3750G platform I've moved the configuration on the switch so that the ports are routed now instead of using vlans but still no go. Here is the output from a show ip mroute: Switch#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group V - RD Vector, v - Vector Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.255.255.250), 00:01:03/00:02:56, RP 3.3.3.3, flags: SJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet1/0/2, Forward/Sparse, 00:01:03/00:02:06 GigabitEthernet1/0/1, Forward/Sparse, 00:01:03/00:02:56
Re: [c-nsp] Enabling multicast routing on 3750G platform
Well there are actually two versions of the cmd. ip igmp static-group - Is used widely in contribution video setups where there's no PIM/IGMP between the two providers. Or in 3play setups to speed up channel selection you statically join all the channels on the DR for the L2 segment. Or basically anytime where you always want the streams to be received and you don't want to or can't rely on the IGMP membership reports (e.g. backup). ip igmp join-group - though it achieves the same thing as the above cmd it makes the router to actually listen to the m-cast stream that is beneficial when you want to test multicast with ping to the group address for example -the router (or routers) which joined the group will be listed as replies to each ping -that's how you know the multicast was delivered to them successfully adam -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Lobo Sent: 30 January 2015 02:00 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Enabling multicast routing on 3750G platform Problem solved! You guys were right about VLC and its TTL. Turns out there's a bug in the program where changing the TTL in the GUI doesn't affect streaming for some reason. I added a ttl=30 to the string and the stream started flowing to the secondary port. I even changed things back to vlans and it routed perfectly fine. I have a question about one comment that was made regarding the igmp- join command. In all the documentation I've read, it says to put that command on the interfaces that plan on receiving the stream(s). Some comments suggested removing it or not needing it and with my own testing it clearly works fine even without this command. Why is that? This is the final show ip mroute: Switch#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group V - RD Vector, v - Vector Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.255.255.250), 02:45:34/00:02:34, RP 3.3.3.3, flags: SJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Vlan100, Forward/Sparse, 00:00:38/00:02:34 Vlan200, Forward/Sparse, 02:42:59/00:02:32 (*, 239.0.0.1), 02:45:35/stopped, RP 3.3.3.3, flags: SJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Vlan200, Forward/Sparse, 02:42:15/00:02:33 (1.1.1.1, 239.0.0.1), 00:00:40/00:02:58, flags: JT Incoming interface: Vlan100, RPF nbr 0.0.0.0 Outgoing interface list: Vlan200, Forward/Sparse, 00:00:40/00:02:33 (*, 224.0.1.40), 02:45:35/00:02:28, RP 3.3.3.3, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Loopback0, Forward/Sparse, 02:45:36/00:02:27 Switch# Thanks again for the tips everyone! Jose On Thu, Jan 29, 2015 at 7:23 AM, Adam Vitkovsky avitkov...@gammatelecom.com wrote: Hi Lobo, Ok so the SW is indeed a DR on port GigabitEthernet1/0/1 and it's obviously receiving some stream in which case it should create an (s,g) state and send a register msg to the RP and RP should update its group cache (all should be done internally since the DR=RP). However none of this is happening most likely because the switch doesn't like something about the stream (destination mac address, ttl, som security feature,..). Can you do: debug ip pim -to see if it shows why the switch ignores the incoming stream. -or some other techniques to see why the incoming multicast frames are being dropped silently. adam -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Lobo Sent: 29 January 2015 00:57 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Enabling multicast routing on 3750G platform I've moved the configuration on the switch so that the ports are routed now instead of using vlans but still no go. Here is the output from a show ip mroute: Switch#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending
Re: [c-nsp] Enabling multicast routing on 3750G platform
Ahh good to know! Thanks again everyone. Jose On Fri, Jan 30, 2015 at 1:32 PM, Blake Dunlap iki...@gmail.com wrote: It's mostly used for clients that either are ignorant of igmp, or do it poorly, along with for troubleshooting and a few weird edge cases. It shouldn't be needed normally. -Blake On Fri, Jan 30, 2015 at 6:19 AM, Matthew Huff mh...@ox.com wrote: Use igmp-join if you want the router itself to be a member of the multicast group. You don't need it if you are routing multicast through the router. It's rarely used and only for very specific circumstances, for example if a servers fails if there isn't at least one client joining, etc... Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff| Fax: 914-694-5669 -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Lobo Sent: Thursday, January 29, 2015 9:00 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Enabling multicast routing on 3750G platform Problem solved! You guys were right about VLC and its TTL. Turns out there's a bug in the program where changing the TTL in the GUI doesn't affect streaming for some reason. I added a ttl=30 to the string and the stream started flowing to the secondary port. I even changed things back to vlans and it routed perfectly fine. I have a question about one comment that was made regarding the igmp-join command. In all the documentation I've read, it says to put that command on the interfaces that plan on receiving the stream(s). Some comments suggested removing it or not needing it and with my own testing it clearly works fine even without this command. Why is that? This is the final show ip mroute: Switch#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group V - RD Vector, v - Vector Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.255.255.250), 02:45:34/00:02:34, RP 3.3.3.3, flags: SJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Vlan100, Forward/Sparse, 00:00:38/00:02:34 Vlan200, Forward/Sparse, 02:42:59/00:02:32 (*, 239.0.0.1), 02:45:35/stopped, RP 3.3.3.3, flags: SJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Vlan200, Forward/Sparse, 02:42:15/00:02:33 (1.1.1.1, 239.0.0.1), 00:00:40/00:02:58, flags: JT Incoming interface: Vlan100, RPF nbr 0.0.0.0 Outgoing interface list: Vlan200, Forward/Sparse, 00:00:40/00:02:33 (*, 224.0.1.40), 02:45:35/00:02:28, RP 3.3.3.3, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Loopback0, Forward/Sparse, 02:45:36/00:02:27 Switch# Thanks again for the tips everyone! Jose On Thu, Jan 29, 2015 at 7:23 AM, Adam Vitkovsky avitkov...@gammatelecom.com wrote: Hi Lobo, Ok so the SW is indeed a DR on port GigabitEthernet1/0/1 and it's obviously receiving some stream in which case it should create an (s,g) state and send a register msg to the RP and RP should update its group cache (all should be done internally since the DR=RP). However none of this is happening most likely because the switch doesn't like something about the stream (destination mac address, ttl, som security feature,..). Can you do: debug ip pim -to see if it shows why the switch ignores the incoming stream. -or some other techniques to see why the incoming multicast frames are being dropped silently. adam -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Lobo Sent: 29 January 2015 00:57 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Enabling multicast routing on 3750G platform I've moved the configuration on the switch so that the ports are routed now instead of using vlans but still no go. Here is the output from a show ip mroute: Switch#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host
Re: [c-nsp] Community tagged route, redistributed to RR, but OSPF learnt route takes precedence(So RIB failure)
To the best of my knowledge, there's a completely independent BGP RIB, where all BGP routes go to live/die. Therefore, RIB failure doesn't prevent propagation. Does the RR consider this path its best path for this route? If not, it won't reflect it. Otherwise, I'd verify that you have reflection configured as intended, and that you don't have an outbound route map that might be discarding the route. On 1/29/2015 6:14 PM, CiscoNSP List wrote: Hi Guys, Quick question (Hopefully!) Im successfully advertising 0.0.0.0 from a PE(With community tag) - RR, but on the RR it is displaying rib failure for this route(0.0.0.0), due to the RR learning a default via OSPF(Which makes sense)...but the route is still on the RR (With the correct community tag in BGP)...now I want to re-advertise the learnt BGP default route with community tag to route reflector client (Via matching the community tag), but the route isnt advertised.now I assume because it is not in RIB? Is there anyway around this...i.e. I want to maintain OSPF advertising default to the RR, but the RR to advertise a different default learnt from another PE, to a RR-Client..hopefully that makes sense :) Cheers. ___ 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/ ___ 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/
Re: [c-nsp] Community tagged route, redistributed to RR, but OSPF learnt route takes precedence(So RIB failure)
Thanks Peter, The RR has the route in BGP, albeit with RIB-failure: #sh ip bgp 0.0.0.0 BGP routing table entry for 0.0.0.0/0, version 8406453 BGP Bestpath: compare-routerid Paths: (1 available, best #1, table default, RIB-failure(17)) Additional-path-install Not advertised to any peer It also is saying it is learnt from the PE, and also has the community tags applied (That were applied on the PE) route-map from RR - RR-client is 2 matches (Both community tag based) 1. default 2. customer ranges Customer ranges (Directly connected to RR - there are on test Interfaces on the RR) are being advertised successfully to the RR-client, but default is not(They are being tagged from RR with a different community) RR-Client ingress route map (i.e for advertisements From RR) is the same 2 matches (Both community tag based) 1. default 2. customer ranges It is receiving the customer ranges successfully Ill test a customer range from PE - RR, and see if that gets advertised to RR-client...as it looks like anything learnt from iBGP (PE-RR) is not being re-advertised to the RR-client. Cheers Date: Fri, 30 Jan 2015 11:41:01 -0800 From: peteli...@templin.org To: cisconsp_l...@hotmail.com; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Community tagged route, redistributed to RR, but OSPF learnt route takes precedence(So RIB failure) To the best of my knowledge, there's a completely independent BGP RIB, where all BGP routes go to live/die. Therefore, RIB failure doesn't prevent propagation. Does the RR consider this path its best path for this route? If not, it won't reflect it. Otherwise, I'd verify that you have reflection configured as intended, and that you don't have an outbound route map that might be discarding the route. On 1/29/2015 6:14 PM, CiscoNSP List wrote: Hi Guys, Quick question (Hopefully!) Im successfully advertising 0.0.0.0 from a PE(With community tag) - RR, but on the RR it is displaying rib failure for this route(0.0.0.0), due to the RR learning a default via OSPF(Which makes sense)...but the route is still on the RR (With the correct community tag in BGP)...now I want to re-advertise the learnt BGP default route with community tag to route reflector client (Via matching the community tag), but the route isnt advertised.now I assume because it is not in RIB? Is there anyway around this...i.e. I want to maintain OSPF advertising default to the RR, but the RR to advertise a different default learnt from another PE, to a RR-Client..hopefully that makes sense :) Cheers. ___ 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/ ___ 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/
[c-nsp] Cisco 6500 SUP720-3BXL upgrade to 15.1.2.SY4a question
Looking to upgrade a couple of our 6500 SUP720-3BXL to 15.1.2SY4a. We have the WS-6748-GE-TX and WS-6724-SFP Cards installed, no SIP/SPA installed. Just want to make sure the following associated software is correct. The software version numbers make you questions yourself because the IOS version is 15.1.2 and the boot image is 12.2.33SXI and so on. Boot Image: s72033-boot-mz.122-33.SXI14.bin RP ROMMON: c6msfc3-rm2.srec.122-17r.SX7 SP ROMMON: c6ksup720-rm2.srec.8-5-4.srec IOS: s72033-advipservicesk9-mz.151-2.SY4a.bin Thanks Erik CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. ___ 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/
Re: [c-nsp] Enabling multicast routing on 3750G platform
It's mostly used for clients that either are ignorant of igmp, or do it poorly, along with for troubleshooting and a few weird edge cases. It shouldn't be needed normally. -Blake On Fri, Jan 30, 2015 at 6:19 AM, Matthew Huff mh...@ox.com wrote: Use igmp-join if you want the router itself to be a member of the multicast group. You don't need it if you are routing multicast through the router. It's rarely used and only for very specific circumstances, for example if a servers fails if there isn't at least one client joining, etc... Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff| Fax: 914-694-5669 -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Lobo Sent: Thursday, January 29, 2015 9:00 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Enabling multicast routing on 3750G platform Problem solved! You guys were right about VLC and its TTL. Turns out there's a bug in the program where changing the TTL in the GUI doesn't affect streaming for some reason. I added a ttl=30 to the string and the stream started flowing to the secondary port. I even changed things back to vlans and it routed perfectly fine. I have a question about one comment that was made regarding the igmp-join command. In all the documentation I've read, it says to put that command on the interfaces that plan on receiving the stream(s). Some comments suggested removing it or not needing it and with my own testing it clearly works fine even without this command. Why is that? This is the final show ip mroute: Switch#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group V - RD Vector, v - Vector Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.255.255.250), 02:45:34/00:02:34, RP 3.3.3.3, flags: SJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Vlan100, Forward/Sparse, 00:00:38/00:02:34 Vlan200, Forward/Sparse, 02:42:59/00:02:32 (*, 239.0.0.1), 02:45:35/stopped, RP 3.3.3.3, flags: SJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Vlan200, Forward/Sparse, 02:42:15/00:02:33 (1.1.1.1, 239.0.0.1), 00:00:40/00:02:58, flags: JT Incoming interface: Vlan100, RPF nbr 0.0.0.0 Outgoing interface list: Vlan200, Forward/Sparse, 00:00:40/00:02:33 (*, 224.0.1.40), 02:45:35/00:02:28, RP 3.3.3.3, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Loopback0, Forward/Sparse, 02:45:36/00:02:27 Switch# Thanks again for the tips everyone! Jose On Thu, Jan 29, 2015 at 7:23 AM, Adam Vitkovsky avitkov...@gammatelecom.com wrote: Hi Lobo, Ok so the SW is indeed a DR on port GigabitEthernet1/0/1 and it's obviously receiving some stream in which case it should create an (s,g) state and send a register msg to the RP and RP should update its group cache (all should be done internally since the DR=RP). However none of this is happening most likely because the switch doesn't like something about the stream (destination mac address, ttl, som security feature,..). Can you do: debug ip pim -to see if it shows why the switch ignores the incoming stream. -or some other techniques to see why the incoming multicast frames are being dropped silently. adam -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Lobo Sent: 29 January 2015 00:57 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Enabling multicast routing on 3750G platform I've moved the configuration on the switch so that the ports are routed now instead of using vlans but still no go. Here is the output from a show ip mroute: Switch#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group V - RD Vector, v - Vector Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires
[c-nsp] BGP Dynamic Neighbours Peer Templates
Hi all I think this has probably been asked before, but not for a while, so just wanted to ask the list for an update: Does anyone know when (indeed if!) the BGP Dynamic Neighbours feature (the 'bgp listen ...' command) will be integrated into the BGP Peer (Session) Template framework? Specifically on the G2 ISRs, but we'd also find it useful on the ASR1K. As of IOS 15.5(1)T (on a 1921), it doesn't seem to be there. We use the template framework extensively and I really, really don't want to have to start using peer-groups just to use this feature, so I'm hoping someone will tell me it's coming soon! :-) TIA Rich. Beware of the obnoxious lawyer-bot below this line! -- ** Satellite Information Services Limited. Registered Office: Whitehall Avenue, Kingston, Milton Keynes, Buckinghamshire, MK10 0AX. Company No. 4243307 The information in this email (which includes any files transmitted with it) is confidential and is intended for the addressee only. Unauthorized recipients are required to maintain confidentiality. If you have received this email in error please notify the sender immediately, destroy any copies and delete it from your computer system. ** ___ 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/
