Re: [c-nsp] Multicast Issue
The downstream is configured to be 24 M but the upstream is configured to be 4M this is the current setup , so it is for sure bandwidth issue ? > From: mark.ti...@seacom.mu > To: eng_m...@hotmail.com > Subject: Re: [c-nsp] Multicast Issue > Date: Wed, 30 May 2012 08:18:57 +0200 > CC: cisco-nsp@puck.nether.net > > On Wednesday, May 30, 2012 08:14:20 AM Mohammad Khalil > wrote: > > > Actually its supposed for each stream to consume 8M > > should i try to increase the speed limits configured ? > > As this is VDSL, are you sure you're actually getting 24Mbps > into the house? > > We tested IPTv on VDSL using new copper across 50m - it was > a disaster. > > If you can, try increasing bandwidth and see if that helps. > But it definitely sounds like when you request a 2nd stream > and the picture develops block noise, you're starving the > link of bandwidth. > > Mark. ___ 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] Multicast Issue
On Wednesday, May 30, 2012 08:14:20 AM Mohammad Khalil wrote: > Actually its supposed for each stream to consume 8M > should i try to increase the speed limits configured ? As this is VDSL, are you sure you're actually getting 24Mbps into the house? We tested IPTv on VDSL using new copper across 50m - it was a disaster. If you can, try increasing bandwidth and see if that helps. But it definitely sounds like when you request a 2nd stream and the picture develops block noise, you're starving the link of bandwidth. Mark. ___ 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] Multicast Issue
Actually its supposed for each stream to consume 8M should i try to increase the speed limits configured ? > From: mark.ti...@seacom.mu > To: cisco-nsp@puck.nether.net > Subject: Re: [c-nsp] Multicast Issue > Date: Wed, 30 May 2012 07:25:01 +0200 > CC: eng_m...@hotmail.com > > On Wednesday, May 30, 2012 07:15:28 AM Mohammad Khalil > wrote: > > > Hi all , i have CPE that terminates VDSL connection with > > a downstream of 24M The CPE receives Multicast streams > > to serve two televisions The network is all layer 2 > > connections > > When serving one television , all is working good but > > when two are in service the picture is stuck as if the > > multicast traffic is stopped or something Any ideas? > > Sounds like you're asking too much from the link. > > How much bandwidth does a single stream consume? > > Mark. ___ 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] Multicast Issue
On Wednesday, May 30, 2012 07:15:28 AM Mohammad Khalil wrote: > Hi all , i have CPE that terminates VDSL connection with > a downstream of 24M The CPE receives Multicast streams > to serve two televisions The network is all layer 2 > connections > When serving one television , all is working good but > when two are in service the picture is stuck as if the > multicast traffic is stopped or something Any ideas? Sounds like you're asking too much from the link. How much bandwidth does a single stream consume? Mark. ___ 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] Can I use BGP instead of any IGP?
On Wednesday, May 30, 2012 03:34:04 AM Andrew Jones wrote: > In enterprise WAN environments, you could use BGP as the > sole routing protocol, if you treat each individual site > as a separate AS (private AS numbers offcourse). > > Depending on the size / complexity of the campus, you > might still need an IGP within the campus. Again you > could treat each individual router as a separate AS, > forming ebgp peers across links where dynamic peers > would ordinarily appear. It didn't sound like this is what the OP was after; you're right, it would work but seems awfully complex :-). I think the OP was after replacing any IGP with BGP, including using BGP for BGP. The latter is easy, the former, not so much. Mark. ___ 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] Multicast Issue
Hi all , i have CPE that terminates VDSL connection with a downstream of 24M The CPE receives Multicast streams to serve two televisions The network is all layer 2 connections When serving one television , all is working good but when two are in service the picture is stuck as if the multicast traffic is stopped or something Any ideas? Thanks ___ 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] Can I use BGP instead of any IGP?
In enterprise WAN environments, you could use BGP as the sole routing protocol, if you treat each individual site as a separate AS (private AS numbers offcourse). Depending on the size / complexity of the campus, you might still need an IGP within the campus. Again you could treat each individual router as a separate AS, forming ebgp peers across links where dynamic peers would ordinarily appear. But just because you can, doesn't mean you should. Andrew Jones -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of vijay gore Sent: Tuesday, 29 May 2012 8:19 PM To: mark.ti...@seacom.mu Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Can I use BGP instead of any IGP? thanks Mark, you cleared my doubts On Tue, May 29, 2012 at 3:28 PM, Mark Tinka wrote: > On Tuesday, May 29, 2012 11:53:35 AM vijay gore wrote: > > > do you mean that you can not use BGP instead of IGP, even > > static route. > > Thoroughly speaking, you can't use BGP as an IGP in the > context of what IGP's are meant to do. > > > But in concept, you can use BGP as an IGP, e.g., carrying > customer and interface prefixes in iBGP instead of in the > IGP as was normally the case (in order to aid scaling), BGP > Label Unicast particularly for Seamless MPLS designs (in > order to aid scaling, as well), e.t.c. > > > But for an IGP, i.e., link state routing protocols, e.t.c., > BGP doesn't do that. BGP requires an underlying IGP in order > for its sessions to form - this underlying capability can be > provided by static routes, connected routes or dynamic > IGP's. > > Mark. > ___ 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] EARL L2 ASIC Search Engine has failed
Hi Piotr, Both linecards (including DFCs), chassis and power supplies were replaced. The only common element left is the Supervisor. The standby Supervisor was replaced on a prior RMA, but there has been no (obvious) indication on either the part of TAC or myself to suggest the active Supervisor is somehow responsible. The chassis was rebooted this most recent time and has cleared the error and it hasn't resurfaced in the few days since, but that doesn't give me much comfort. -- Sent from my mobile device On 2012-05-29, at 5:56 PM, Piotr Wojciechowski wrote: > On 5/29/12 16:03 , Jason Lixfeld wrote: >> I've had TAC chewing on this error for the past month. Seems that the DFC >> in slot 2 and slot 3 are reporting the error. TAC's first inclination was >> bad hardware, so it was RMA'd, however the error showed up again a few days >> ago. A reboot cleared it and I haven't seen it since, but it's still >> alarming that "brand new" hardware would show exactly the same error, of >> which I have never seen before in my life. >> >> Anyone seen this in the wild? Software issue perhaps? >> > > Hello Jason, > > Have you replaced only DFC or whole line card including DFC? Have you > tried this card in different chassis or different slots in same chassis? > Have you tried rebooting or reinserting just one line card instead of > rebooting whole chassis? Because we're talking about adjacent slots it > may be possible it's chassis problem just error messages are misleading. > > Regards, > -- > Piotr Wojciechowski (CCIE #25543) | "The trouble with being a god is > http://ccieplayground.wordpress.com | that you've got no one to pray to" > JID: pe...@jabber.org | -- (Terry Pratchett, Small Gods) > > > ___ > 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] EARL L2 ASIC Search Engine has failed
On 5/29/12 16:03 , Jason Lixfeld wrote: > I've had TAC chewing on this error for the past month. Seems that the DFC in > slot 2 and slot 3 are reporting the error. TAC's first inclination was bad > hardware, so it was RMA'd, however the error showed up again a few days ago. > A reboot cleared it and I haven't seen it since, but it's still alarming that > "brand new" hardware would show exactly the same error, of which I have never > seen before in my life. > > Anyone seen this in the wild? Software issue perhaps? > Hello Jason, Have you replaced only DFC or whole line card including DFC? Have you tried this card in different chassis or different slots in same chassis? Have you tried rebooting or reinserting just one line card instead of rebooting whole chassis? Because we're talking about adjacent slots it may be possible it's chassis problem just error messages are misleading. Regards, -- Piotr Wojciechowski (CCIE #25543) | "The trouble with being a god is http://ccieplayground.wordpress.com | that you've got no one to pray to" JID: pe...@jabber.org | -- (Terry Pratchett, Small Gods) ___ 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] L3VPN works, but not default route
Is there a reason why my pe's only install type 5 routes from the ospf neighboring ce? In other words, on the pe, I see lots of type-3's in the vrf-specific ospf db learned from the directly connected ce...but in this pe, I only see type 5's installed in vrf rib, and thus, subsequently, only those type-5's are redis'd to remotely located pe's where other member vrf are located. Aaron -Original Message- From: Bruce Pinsky [mailto:b...@whack.org] Sent: Thursday, April 19, 2012 1:42 PM To: Aaron Cc: 'Tim Durack'; oboeh...@cisco.com; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] L3VPN works, but not default route -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aaron wrote: > I didn't have to use import, and they still came into vrf. ? any idea why? > With unique RD, each route advertised by each PE is considered a separate prefix with a different nexthop. So, bestpath is run for each of those unique RD/Prefixes and the bestpath is then imported into the VRF. maximum-paths only comes into play when you have more than one nexthop for each unique RD/prefix (such as when you have redundant RRs). - -- = bep -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+QXGEACgkQE1XcgMgrtyZI6ACfdKbMaBfqQ5oNRnXo745qi4KW wFMAn2hYdLo9Kg51vfWtPiXryotiGtgA =/B1T -END PGP SIGNATURE- ___ 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] m-vpn
On Tuesday, May 29, 2012 06:23:45 PM Phil Mayers wrote: > No. SSM *is* sparse-mode. It's just sparse mode without > *,g joins. In NG-MVPN (or BGP-MVPN, as Juniper call it nowadays), you can deploy an MVPN tree as either SPT-only, or RPT-SPT, when running PIM-SM. In NG-MVPN, BGP replaces PIM for all PIM functionality (hence the lack of PIM in the core network). RPT-SPT is akin to regular PIM in a PIM-based core, where an IGMP client tries to join a Multicast group, and (*,G) is initiated to toward the RP. However, SPT-only means that while an RP configuration may exist in the Receiver PE router, when the Receiver PE router receives a (*,G) join request, it searches for and consults what is know as a Source Active (SA) route in its routing table (SA routes are Type 5 BGP routes in NG-MVPN's). If it finds a matching one, it automatically converts the join message to a Type 6 Multicast route, which is the same as (S,G), and the appropriate route is installed in the router. In SPT-only mode, single forwarder election, rather than the RP, is used to determine the source of the Multicast traffic. Pretty cool. You can read all about it here: http://tools.ietf.org/html/rfc6514#section-14 Mark. ___ 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] m-vpn
On 29/05/12 17:14, Aaron wrote: Please help me on a side-note I've been wondering, what makes ssm ssm? I mean here's what I was seeing SSM is configurable on a range of groups. Effectively, all it means is "don't make *,g joins for this group". s,g joins are made via other methods, for example IGMPv3 LAN clients, or discovery of "s" (i.e. the IP of other PEs) when running MVPN. I have several mcast groups in my network currently...all 239.x.x.x Thus far my mcast network was simply ... Mcast xmitter-->asr9kasr9k--mcast rcvr That's it. Just a 2 router network with asr9k's directly connected in the middle with the source and destination of mcast traffic directly connected to both the respective asr9k's. I now want to virtualize that traffic from source to destination in a L3VPN (mcast enabled of course, which I believe makes it a mvpn by definition) but before proceeding just want to understand what I have currently. If I type "sh pim gr" I see all of the groups as "SM". Interestingly I have SM being "sparse mode", I assume? *NO* rp defined in my 2 mcast routers currently. Isn't it a well know fact that you can not accomplish pim sm without an rp ??! (that's why I have my No. SSM *is* sparse-mode. It's just sparse mode without *,g joins. doubts that "sh pim gr" is telling me the truth, but please tell me if I'm wrong) I assume the ASR was able to discover the source of the other PE, and perform an s,g join. I wonder if it's using the older type-2 RDs, or something else, or if it worked "by chance". ___ 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] m-vpn
Please help me on a side-note I've been wondering, what makes ssm ssm? I mean here's what I was seeing I have several mcast groups in my network currently...all 239.x.x.x Thus far my mcast network was simply ... Mcast xmitter-->asr9kasr9k--mcast rcvr That's it. Just a 2 router network with asr9k's directly connected in the middle with the source and destination of mcast traffic directly connected to both the respective asr9k's. I now want to virtualize that traffic from source to destination in a L3VPN (mcast enabled of course, which I believe makes it a mvpn by definition) but before proceeding just want to understand what I have currently. If I type "sh pim gr" I see all of the groups as "SM". Interestingly I have *NO* rp defined in my 2 mcast routers currently. Isn't it a well know fact that you can not accomplish pim sm without an rp ??! (that's why I have my doubts that "sh pim gr" is telling me the truth, but please tell me if I'm wrong) I did a test sending mcast to 239.0.6.1, I added a third mcast router to join that 239.0.6.1 group. It showed up as pim sm in "sh pim gr". I then changed ONLY that third router's config to have a new ssm range of 239.0.6.0/24 and then now "sh pim gr" shows that as a SSM group. The p and xmitting pe routers still show that group as SM. So which is it SM or SSM ? Here's what I saw on the third router that I'm joining 239.0.6.1 on. conf router igmp interface bvI 2 static-group 239.0.6.1 192.168.107.204 commit ...shows as SM. (192.168.107.204,239.0.6.1)SPT SM Up: 00:00:50 JP: Join(now) RPF: Bundle-Ether1,10.101.1.49 Flags: Up: MT clr (00:00:00) MDT: JoinSend N, Cache N/N, Misc (0x0,0/0) Cache: Add 00:00:00, Rem 00:00:00. MT Cnt: Set 0, Unset 0. Joins sent 0 MDT-ifh 0x0/0x0 MT Slot none/ none RPF Table: IPv4-Unicast-default BVI200:00:50 fwd LI AS(self,00:02:54) LH 224.0.1.39/32* DMperm 0 0.0.0.0 224.0.1.40/32* DMperm 1 0.0.0.0 224.0.0.0/24* NOperm 0 0.0.0.0 232.0.0.0/8*SSM config 0 0.0.0.0 224.0.0.0/4*SMstatic 1 0.0.0.0 RPF: Null,0.0.0.0 delete static join... then ssm range testssm239.0.6 ipv4 access-list testssm239.0.6 10 permit ipv4 239.0.6.0 0.0.0.255 any multicast-routing address-family ipv4 ssm range testssm239.0.6 commi re-added static join... shows as SSM. Transit p and source pe still show this group as SM. (192.168.107.204,239.0.6.1)SPT SSM Up: 00:00:51 JP: Join(now) RPF: Bundle-Ether1,10.101.1.49 Flags: Up: MT clr (00:00:00) MDT: JoinSend N, Cache N/N, Misc (0x0,0/0) Cache: Add 00:00:00, Rem 00:00:00. MT Cnt: Set 0, Unset 0. Joins sent 0 MDT-ifh 0x0/0x0 MT Slot none/ none RPF Table: IPv4-Unicast-default BVI200:00:51 fwd LI AS(self,00:02:54) LH 224.0.1.39/32* DMperm 0 0.0.0.0 224.0.1.40/32* DMperm 1 0.0.0.0 224.0.0.0/24* NOperm 0 0.0.0.0 239.0.6.0/24* SSM config 1 0.0.0.0 224.0.0.0/4*SMstatic 0 0.0.0.0 RPF: Null,0.0.0.0 -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers Sent: Tuesday, May 29, 2012 10:11 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] m-vpn On 29/05/12 15:55, Aaron wrote: > Hi all, > > > > I've read through Chapter 7 of "MPLS and VPN Architectures Volume II" > regarding Multicast VPN. > > > > I never saw any mention of enabling the ipv4 mdt address family under bgp. > Is this ipv4 mdt af something altogether different than what is spoken > of in the book ? .or did I totally miss something in that chapter > about the ipv4 mdt af being implicitly enable somehow. > > > > I'm just trying to accomplish mcast over my mpls L3VPN. This will be > for my draft-rosen, yes? > high capacity mcast for catv for all my catv subscribers. 2-3 gbps > sustained 24x7. A couple different pe/ce will xmit and a couple > different pe/ce will rcv. I'd prefer to use ssm cause I don't wanna > mess with rp's In that case, you want the "mdt" SAFI under the BGP stanza, appropriately route-reflected. The "mdt" SAFI basically lets you discover other PEs in the MVPN. This is not necessary with ASM MVPN groups as the *,g tree allows discover. This was accomplished in earlier versions of IOS using so-called type-2 RDs, but the MDT SAFI replaces that (and is in turn replaced in NG-MVPN) > and sup-optimal routing to and from rp and single point of failure on > rp (so I don't wanna mess with redundant rp either if I can simply do > ssm) SSM works fine. Just enable the "mft" SAFI. I only holds one route per PE/MVPN combo. ___ 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] m-vpn
Usually, the starting point would be here: http://www.cisco.com/cisco/web/psa/default.html?mode=prod The specific page you are looking for is here: http://www.cisco.com/en/US/partner/docs/routers/asr9000/software/asr9k_r 4.1/multicast/configuration/guide/mc41mcst.html#wp2631058 http://www.cisco.com/en/US/partner/docs/routers/asr9000/software/asr9k_r 4.1/multicast/configuration/guide/mc41mcst.html#wp2631629 (This is for ASR9K...) Arie -Original Message- From: Aaron [mailto:aar...@gvtc.com] Sent: Tuesday, May 29, 2012 08:19 To: Arie Vayner (avayner); cisco-nsp@puck.nether.net Subject: RE: [c-nsp] m-vpn Thanks Arie, I'm trying to accomplish in ios xr 4.1.2 - got link for that ? -Original Message- From: Arie Vayner (avayner) [mailto:avay...@cisco.com] Sent: Tuesday, May 29, 2012 10:15 AM To: Aaron; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] m-vpn Aaron, The MDT BGP address family syntax is relatively new, so might not have been around when the book was released... For a more recent source of information, I would suggest: http://www.cisco.com/en/US/partner/docs/ios-xml/ios/ipmulti_mvpn/configu ration/15-2mt/imc-mvpn-15-2mt-book.html Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Aaron Sent: Tuesday, May 29, 2012 07:55 To: cisco-nsp@puck.nether.net Subject: [c-nsp] m-vpn Hi all, I've read through Chapter 7 of "MPLS and VPN Architectures Volume II" regarding Multicast VPN. I never saw any mention of enabling the ipv4 mdt address family under bgp. Is this ipv4 mdt af something altogether different than what is spoken of in the book ? .or did I totally miss something in that chapter about the ipv4 mdt af being implicitly enable somehow. I'm just trying to accomplish mcast over my mpls L3VPN. This will be for my high capacity mcast for catv for all my catv subscribers. 2-3 gbps sustained 24x7. A couple different pe/ce will xmit and a couple different pe/ce will rcv. I'd prefer to use ssm cause I don't wanna mess with rp's and sup-optimal routing to and from rp and single point of failure on rp (so I don't wanna mess with redundant rp either if I can simply do ssm) Aaron ___ 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] m-vpn
Thanks Arie, I'm trying to accomplish in ios xr 4.1.2 - got link for that ? -Original Message- From: Arie Vayner (avayner) [mailto:avay...@cisco.com] Sent: Tuesday, May 29, 2012 10:15 AM To: Aaron; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] m-vpn Aaron, The MDT BGP address family syntax is relatively new, so might not have been around when the book was released... For a more recent source of information, I would suggest: http://www.cisco.com/en/US/partner/docs/ios-xml/ios/ipmulti_mvpn/configu ration/15-2mt/imc-mvpn-15-2mt-book.html Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Aaron Sent: Tuesday, May 29, 2012 07:55 To: cisco-nsp@puck.nether.net Subject: [c-nsp] m-vpn Hi all, I've read through Chapter 7 of "MPLS and VPN Architectures Volume II" regarding Multicast VPN. I never saw any mention of enabling the ipv4 mdt address family under bgp. Is this ipv4 mdt af something altogether different than what is spoken of in the book ? .or did I totally miss something in that chapter about the ipv4 mdt af being implicitly enable somehow. I'm just trying to accomplish mcast over my mpls L3VPN. This will be for my high capacity mcast for catv for all my catv subscribers. 2-3 gbps sustained 24x7. A couple different pe/ce will xmit and a couple different pe/ce will rcv. I'd prefer to use ssm cause I don't wanna mess with rp's and sup-optimal routing to and from rp and single point of failure on rp (so I don't wanna mess with redundant rp either if I can simply do ssm) Aaron ___ 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] m-vpn
Aaron, The MDT BGP address family syntax is relatively new, so might not have been around when the book was released... For a more recent source of information, I would suggest: http://www.cisco.com/en/US/partner/docs/ios-xml/ios/ipmulti_mvpn/configu ration/15-2mt/imc-mvpn-15-2mt-book.html Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Aaron Sent: Tuesday, May 29, 2012 07:55 To: cisco-nsp@puck.nether.net Subject: [c-nsp] m-vpn Hi all, I've read through Chapter 7 of "MPLS and VPN Architectures Volume II" regarding Multicast VPN. I never saw any mention of enabling the ipv4 mdt address family under bgp. Is this ipv4 mdt af something altogether different than what is spoken of in the book ? .or did I totally miss something in that chapter about the ipv4 mdt af being implicitly enable somehow. I'm just trying to accomplish mcast over my mpls L3VPN. This will be for my high capacity mcast for catv for all my catv subscribers. 2-3 gbps sustained 24x7. A couple different pe/ce will xmit and a couple different pe/ce will rcv. I'd prefer to use ssm cause I don't wanna mess with rp's and sup-optimal routing to and from rp and single point of failure on rp (so I don't wanna mess with redundant rp either if I can simply do ssm) Aaron ___ 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] m-vpn
On 29/05/12 15:55, Aaron wrote: Hi all, I've read through Chapter 7 of "MPLS and VPN Architectures Volume II" regarding Multicast VPN. I never saw any mention of enabling the ipv4 mdt address family under bgp. Is this ipv4 mdt af something altogether different than what is spoken of in the book ? .or did I totally miss something in that chapter about the ipv4 mdt af being implicitly enable somehow. I'm just trying to accomplish mcast over my mpls L3VPN. This will be for my draft-rosen, yes? high capacity mcast for catv for all my catv subscribers. 2-3 gbps sustained 24x7. A couple different pe/ce will xmit and a couple different pe/ce will rcv. I'd prefer to use ssm cause I don't wanna mess with rp's In that case, you want the "mdt" SAFI under the BGP stanza, appropriately route-reflected. The "mdt" SAFI basically lets you discover other PEs in the MVPN. This is not necessary with ASM MVPN groups as the *,g tree allows discover. This was accomplished in earlier versions of IOS using so-called type-2 RDs, but the MDT SAFI replaces that (and is in turn replaced in NG-MVPN) and sup-optimal routing to and from rp and single point of failure on rp (so I don't wanna mess with redundant rp either if I can simply do ssm) SSM works fine. Just enable the "mft" SAFI. I only holds one route per PE/MVPN combo. ___ 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] m-vpn
Hi all, I've read through Chapter 7 of "MPLS and VPN Architectures Volume II" regarding Multicast VPN. I never saw any mention of enabling the ipv4 mdt address family under bgp. Is this ipv4 mdt af something altogether different than what is spoken of in the book ? .or did I totally miss something in that chapter about the ipv4 mdt af being implicitly enable somehow. I'm just trying to accomplish mcast over my mpls L3VPN. This will be for my high capacity mcast for catv for all my catv subscribers. 2-3 gbps sustained 24x7. A couple different pe/ce will xmit and a couple different pe/ce will rcv. I'd prefer to use ssm cause I don't wanna mess with rp's and sup-optimal routing to and from rp and single point of failure on rp (so I don't wanna mess with redundant rp either if I can simply do ssm) Aaron ___ 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] EARL L2 ASIC Search Engine has failed
I've had TAC chewing on this error for the past month. Seems that the DFC in slot 2 and slot 3 are reporting the error. TAC's first inclination was bad hardware, so it was RMA'd, however the error showed up again a few days ago. A reboot cleared it and I haven't seen it since, but it's still alarming that "brand new" hardware would show exactly the same error, of which I have never seen before in my life. Anyone seen this in the wild? Software issue perhaps? Gear: 7609/SUP720-3BXL15.2(2)S. 6748-GE-TX-3BXL (slot 2) 6748-GE-TX-3BXL (slot 3) Apr 25 16:16:22.527: %EARL_L2_ASIC-DFC2-4-SRCH_ENG_FAIL: EARL L2 ASIC Search Engine has failed -Traceback= 20B9414Cz 20B9AA84z 20BBA7FCz 20BBB638z 20BDC2A0z 20BDE674z Apr 25 16:16:22.531: DFC2: Dumping srcb info sman_setup_search Apr 25 16:16:22.531: DFC2: se_flags: 100 Apr 25 16:16:22.531: DFC2: se_data: 0x0004 Apr 25 16:16:22.531: DFC2: se_mask: 0x00040020 Apr 25 16:16:22.531: DFC2: sew_data: 0x Apr 25 16:16:22.531: DFC2: sew_mask: 0x ... Apr 25 16:16:32.927: %EARL_L2_ASIC-DFC3-4-SRCH_ENG_FAIL: EARL L2 ASIC Search Engine has failed -Traceback= 20B9414Cz 20B9AA74z 20BBA7FCz 20BBB638z 20BDC2A0z 20BDE674z Apr 25 16:16:32.927: DFC3: Dumping srcb info sman_setup_search Apr 25 16:16:32.927: DFC3: se_flags: 100 Apr 25 16:16:32.927: DFC3: se_data: 0x0004 Apr 25 16:16:32.927: DFC3: se_mask: 0x00040020 Apr 25 16:16:32.927: DFC3: sew_data: 0x Apr 25 16:16:32.927: DFC3: sew_mask: 0x ... ___ 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] setting max mtu on switch (Jumbo)
On 5/29/12, Gert Doering wrote: > Hi, > > On Tue, May 29, 2012 at 06:40:38PM +1000, Reuben Farrelly wrote: >> I've often wondered about supposed downsides myself. Why is it that we >> don't see the layer 2 MTU set as high as possible on Cisco devices out >> of the box, but a relatively "normal" routing MTU set to 1500 in the >> default config? Are there any "bad things" that could come out of this >> config? > > I've posed that question here on the list about half a year ago, and > nobody had to report anything negative... so yes, I'm wondering as > well why the default isn't "9200 off the shelf". I was under the impression that all hosts on the vlan had to have the same MTU or they couldn't talk to each other. If that is the case, having a switch default to 9200 byte MTUs opens up the possibility of some users deciding they want large MTUs, giving it a try and, when it works, setting their machines to 9200 byte MTUs. Meanwhile, everyone else of the vlan is still using a 1500 byte MTU.. Another issue in the "users doing their own thing" category is following random "best practices" docs they find. I was helping one user who had pretty much all ICMP blocked in iptables because it was a 'best practice' > One possible thought I had was that it could affect the internal memory > layout, with a larger MTU segmenting the memory into fewer + larger > buffers, but nobody was able to confirm that - at least not for the > 6500... Sounds reasonable. I couldn't find anything for 6500s, but a quick look found this for ASAs: " You can enable support for jumbo frames for all interfaces by increasing the amount of memory to process Ethernet frames. Assigning more memory for jumbo frames might limit the maximum use of other features, such as access lists." (http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/intrface.html) Lee ___ 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] setting max mtu on switch (Jumbo)
Agreed. It doesn't happen often but every once in a while you see this. Years ago I had two vendors "interpret" the RFC for VRRP differently on the same broadcast domain. Complete trainwreck. Move along. Nothing to see here -Hammer- "I was a normal American nerd" -Jack Herer On 5/29/2012 7:14 AM, Mark Tinka wrote: On Tuesday, May 29, 2012 02:06:00 PM -Hammer- wrote: One thing that I recently suffered thru regarding this is how your vendors define "jumbo". In a single vendor shop like Cisco, you may define 9000 to your end devices and 9216 to your switching to account for overhead. But other vendors treat jumbo differently and some (Yes, this is 2012) don't support it. Recently I had a multi vendor environment where one of the larger core vendors didn't support it. The result was that any performance gain from the entire solution was really sacrificed by the fact that one of the vendors would issue PMTUD and knock the frame down to 1500 regardless. Make sure you confirm the feature/function thru all your touchpoints and are actually going to benefit from it. This is one of the reasons that while we embrace multi- vendor topologies, we stick to as few as possible (two, in our case). Mark. ___ 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] setting max mtu on switch (Jumbo)
On Tuesday, May 29, 2012 02:06:00 PM -Hammer- wrote: > One thing that I recently suffered thru regarding this is > how your vendors define "jumbo". In a single vendor shop > like Cisco, you may define 9000 to your end devices and > 9216 to your switching to account for overhead. But > other vendors treat jumbo differently and some (Yes, > this is 2012) don't support it. Recently I had a multi > vendor environment where one of the larger core vendors > didn't support it. The result was that any performance > gain from the entire solution was really sacrificed by > the fact that one of the vendors would issue PMTUD and > knock the frame down to 1500 regardless. Make sure you > confirm the feature/function thru all your touchpoints > and are actually going to benefit from it. This is one of the reasons that while we embrace multi- vendor topologies, we stick to as few as possible (two, in our case). Mark. ___ 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] setting max mtu on switch (Jumbo)
One thing that I recently suffered thru regarding this is how your vendors define "jumbo". In a single vendor shop like Cisco, you may define 9000 to your end devices and 9216 to your switching to account for overhead. But other vendors treat jumbo differently and some (Yes, this is 2012) don't support it. Recently I had a multi vendor environment where one of the larger core vendors didn't support it. The result was that any performance gain from the entire solution was really sacrificed by the fact that one of the vendors would issue PMTUD and knock the frame down to 1500 regardless. Make sure you confirm the feature/function thru all your touchpoints and are actually going to benefit from it. -Hammer- "I was a normal American nerd" -Jack Herer On 5/29/2012 3:56 AM, Mark Tinka wrote: On Tuesday, May 29, 2012 10:40:38 AM Reuben Farrelly wrote: I've often wondered about supposed downsides myself. Why is it that we don't see the layer 2 MTU set as high as possible on Cisco devices out of the box, but a relatively "normal" routing MTU set to 1500 in the default config? Are there any "bad things" that could come out of this config? Some of the HP (Flex 10 etc) switches we run here do jumbos by default and I don't think there is any way to lower it. Then again these are storage switches so It's probably because the only standards-based MTU value is 1,500 bytes, and the value for Jumbo frames has been recognized as a standard. As such, while all major vendors will support even up to 10,000 bytes in some cases, 1,500 bytes is still the 802.3 understood standard. You can read here about how the industry is trying to adopt Jumbo frames as some kind of "common understanding": http://en.wikipedia.org/wiki/Jumbo_frame#Adoption Mark. ___ 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] Why weight doesn’t fall under path attribute category? BGP
1. It's proprietary 2. It's never included in the update packets. It is included in the route selection process though its just set local to individual routers. HTH Sent from my iPhone On May 29, 2012, at 6:52 AM, vijay gore wrote: > Hi All, > > *Why weight doesn’t fall under path attribute category?* > * > * > * > * > ___ > 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] Why weight doesn’t fall under path attribute category? BGP
Hi All, *Why weight doesn’t fall under path attribute category?* * * * * ___ 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] Can I use BGP instead of any IGP?
thanks Mark, you cleared my doubts On Tue, May 29, 2012 at 3:28 PM, Mark Tinka wrote: > On Tuesday, May 29, 2012 11:53:35 AM vijay gore wrote: > > > do you mean that you can not use BGP instead of IGP, even > > static route. > > Thoroughly speaking, you can't use BGP as an IGP in the > context of what IGP's are meant to do. > > > But in concept, you can use BGP as an IGP, e.g., carrying > customer and interface prefixes in iBGP instead of in the > IGP as was normally the case (in order to aid scaling), BGP > Label Unicast particularly for Seamless MPLS designs (in > order to aid scaling, as well), e.t.c. > > > But for an IGP, i.e., link state routing protocols, e.t.c., > BGP doesn't do that. BGP requires an underlying IGP in order > for its sessions to form - this underlying capability can be > provided by static routes, connected routes or dynamic > IGP's. > > Mark. > ___ 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] Can I use BGP instead of any IGP?
On Tuesday, May 29, 2012 11:53:35 AM vijay gore wrote: > do you mean that you can not use BGP instead of IGP, even > static route. Thoroughly speaking, you can't use BGP as an IGP in the context of what IGP's are meant to do. But in concept, you can use BGP as an IGP, e.g., carrying customer and interface prefixes in iBGP instead of in the IGP as was normally the case (in order to aid scaling), BGP Label Unicast particularly for Seamless MPLS designs (in order to aid scaling, as well), e.t.c. But for an IGP, i.e., link state routing protocols, e.t.c., BGP doesn't do that. BGP requires an underlying IGP in order for its sessions to form - this underlying capability can be provided by static routes, connected routes or dynamic IGP's. Mark. ___ 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] Can I use BGP instead of any IGP?
On Tuesday, May 29, 2012 11:34:07 AM vijay gore wrote: > *Can I use BGP instead of any IGP?* To use BGP, you need an IGP (even though that IGP is static routing). BGP doesn't understand topology and link discovery. It requires an underlying routing protocol to help it with that, which is where the IGP's come in. So if you want to run iBGP without any dynamic IGP, static routing is your only option, although I'd only recommend that if you were my competitor :-). Mark. ___ 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] Can I use BGP instead of any IGP?
Hi, On Tue, May 29, 2012 at 03:04:07PM +0530, vijay gore wrote: > *Can I use BGP instead of any IGP?* If you know what you're doing, yes. If you need to ask, no. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpp8Qj84l7tO.pgp Description: PGP signature ___ 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] Can I use BGP instead of any IGP?
Hi All, *Can I use BGP instead of any IGP?* * * *Best answer ... awaited** * ___ 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] setting max mtu on switch (Jumbo)
On Tuesday, May 29, 2012 10:40:38 AM Reuben Farrelly wrote: > I've often wondered about supposed downsides myself. Why > is it that we don't see the layer 2 MTU set as high as > possible on Cisco devices out of the box, but a > relatively "normal" routing MTU set to 1500 in the > default config? Are there any "bad things" that could > come out of this config? > > Some of the HP (Flex 10 etc) switches we run here do > jumbos by default and I don't think there is any way to > lower it. Then again these are storage switches so It's probably because the only standards-based MTU value is 1,500 bytes, and the value for Jumbo frames has been recognized as a standard. As such, while all major vendors will support even up to 10,000 bytes in some cases, 1,500 bytes is still the 802.3 understood standard. You can read here about how the industry is trying to adopt Jumbo frames as some kind of "common understanding": http://en.wikipedia.org/wiki/Jumbo_frame#Adoption Mark. ___ 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] setting max mtu on switch (Jumbo)
Hi, On Tue, May 29, 2012 at 06:40:38PM +1000, Reuben Farrelly wrote: > I've often wondered about supposed downsides myself. Why is it that we > don't see the layer 2 MTU set as high as possible on Cisco devices out > of the box, but a relatively "normal" routing MTU set to 1500 in the > default config? Are there any "bad things" that could come out of this > config? I've posed that question here on the list about half a year ago, and nobody had to report anything negative... so yes, I'm wondering as well why the default isn't "9200 off the shelf". One possible thought I had was that it could affect the internal memory layout, with a larger MTU segmenting the memory into fewer + larger buffers, but nobody was able to confirm that - at least not for the 6500... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpf3NBVAj1yZ.pgp Description: PGP signature ___ 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] setting max mtu on switch (Jumbo)
On 29/05/2012 6:09 PM, Gert Doering wrote: Is it best practice to set all switches to max mtu? "Big enough to achieve what you need to achieve". If all your L3 devices only use 1500 bps MTU, and no EoMPLS tunneling or whatnot, there is no real benefit in upping the switch MTU. There does not seem to be a downside either, though. gert I've often wondered about supposed downsides myself. Why is it that we don't see the layer 2 MTU set as high as possible on Cisco devices out of the box, but a relatively "normal" routing MTU set to 1500 in the default config? Are there any "bad things" that could come out of this config? Some of the HP (Flex 10 etc) switches we run here do jumbos by default and I don't think there is any way to lower it. Then again these are storage switches so Reuben ___ 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] setting max mtu on switch (Jumbo)
Hi, On Tue, May 29, 2012 at 04:45:01PM +1030, CiscoNSP_list CiscoNSP_list wrote: > > You need to ensure that the MTU settings of the layer3 devices connected > > to the l2 fabric is smaller or equal than the *lowest* L2 MTU of any > > switch in the fabric. > > > > If one of the switches has a bigger L2 MTU, that's no problem. > > So If we have an existing 3560 with mtu of 1998, that connects to a 7200 > w/NPE400 (10/100 Ints and max mtu of 1500), we should have no issues if we > adjust the 3560 MTU to 9000? The L2 MTU, yes. The 3560 also has a "routing mtu", and that needs to be the same value as on the 7200 (1500). > Is it best practice to set all switches to max mtu? "Big enough to achieve what you need to achieve". If all your L3 devices only use 1500 bps MTU, and no EoMPLS tunneling or whatnot, there is no real benefit in upping the switch MTU. There does not seem to be a downside either, though. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgp7iAy9WVjDl.pgp Description: PGP signature ___ 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] MAC-to-IP script on IOS
Hi Ulrich, The only problem with pinging every IP in the subnet assigned to an interface (for example) is that multiple IPs may reside on the same IP. Take a firewall for example, if multiple IPs are routed to a firewall (say 192.168.1.10 to 192.168.1.20). It's address maybe 192.168.1.10 and 192.168.1.11-20 are then used for 1:1 NAT of internal hosts; How will you know which IP is the firewall? They will all be reached by the same MAC address? There is one to many relation here, is that going to be a problem? Just my two pence, James. ___ 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] setting max mtu on switch (Jumbo)
On (2012-05-29 16:09 +1000), Julien Goodwin wrote: > > Are there any "issues" with setting mtu at 9000? (We have a mix of > > routers/switches some of which only support mtu of 1500), so is adding a > > new switch(or adjusting an existing switch(3560+2960)) going to cause > > issues if other connecting devices mtu is smaller? > interface MTU and L2 transit MTU. There's a bunch of switches where the > two can be different (I remember one switch, can't remember from who, > doesn't allow L3 above 1500, but L2 can be 9k). The aforementioned switches are another example of such. They allow only 1998B L3 MTU (fixed in E and X models). > There's a few things to remember: One more thing is, that in some platforms like GSR, enabling jumbos can affect how memory is allocated, causing there to be less memory for 'normal' sized frames than previously. However generally, unless other information is available, BCP is to set L2 as high as it goes, and L3 ends of L2 link at minimum L2 link or less (less to achieve standardization of L3 MTU). -- ++ytti ___ 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/
