Re: [c-nsp] setting max mtu on switch (Jumbo)

2012-05-29 Thread Julien Goodwin
On 29/05/12 15:41, CiscoNSP_list CiscoNSP_list 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

Re: [c-nsp] setting max mtu on switch (Jumbo)

2012-05-29 Thread Gert Doering
Hi, On Tue, May 29, 2012 at 04:11:17PM +1030, CiscoNSP_list CiscoNSP_list 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

Re: [c-nsp] setting max mtu on switch (Jumbo)

2012-05-29 Thread Saku Ytti
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

Re: [c-nsp] MAC-to-IP script on IOS

2012-05-29 Thread James Bensley
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

Re: [c-nsp] setting max mtu on switch (Jumbo)

2012-05-29 Thread Gert Doering
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

Re: [c-nsp] setting max mtu on switch (Jumbo)

2012-05-29 Thread Reuben Farrelly
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

Re: [c-nsp] setting max mtu on switch (Jumbo)

2012-05-29 Thread Gert Doering
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

[c-nsp] Can I use BGP instead of any IGP?

2012-05-29 Thread vijay gore
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] Can I use BGP instead of any IGP?

2012-05-29 Thread Mark Tinka
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. adding_complexity But in concept, you can use BGP as an IGP, e.g.,

Re: [c-nsp] Can I use BGP instead of any IGP?

2012-05-29 Thread vijay gore
thanks Mark, you cleared my doubts On Tue, May 29, 2012 at 3:28 PM, Mark Tinka mark.ti...@seacom.mu 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

[c-nsp] Why weight doesn’t fall under path attribute category? BGP

2012-05-29 Thread vijay gore
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] setting max mtu on switch (Jumbo)

2012-05-29 Thread -Hammer-
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

Re: [c-nsp] setting max mtu on switch (Jumbo)

2012-05-29 Thread Mark Tinka
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

Re: [c-nsp] setting max mtu on switch (Jumbo)

2012-05-29 Thread -Hammer-
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

Re: [c-nsp] setting max mtu on switch (Jumbo)

2012-05-29 Thread Lee
On 5/29/12, Gert Doering g...@greenie.muc.de 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

[c-nsp] EARL L2 ASIC Search Engine has failed

2012-05-29 Thread Jason Lixfeld
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

[c-nsp] m-vpn

2012-05-29 Thread Aaron
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

Re: [c-nsp] m-vpn

2012-05-29 Thread Phil Mayers
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

Re: [c-nsp] m-vpn

2012-05-29 Thread Aaron
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

Re: [c-nsp] m-vpn

2012-05-29 Thread Arie Vayner (avayner)
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

Re: [c-nsp] m-vpn

2012-05-29 Thread Aaron
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

Re: [c-nsp] m-vpn

2012-05-29 Thread Phil Mayers
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,

Re: [c-nsp] m-vpn

2012-05-29 Thread Mark Tinka
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

Re: [c-nsp] EARL L2 ASIC Search Engine has failed

2012-05-29 Thread Piotr Wojciechowski
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

Re: [c-nsp] EARL L2 ASIC Search Engine has failed

2012-05-29 Thread Jason Lixfeld
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

Re: [c-nsp] Can I use BGP instead of any IGP?

2012-05-29 Thread Andrew Jones
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

[c-nsp] Multicast Issue

2012-05-29 Thread Mohammad Khalil
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

Re: [c-nsp] Can I use BGP instead of any IGP?

2012-05-29 Thread Mark Tinka
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

Re: [c-nsp] Multicast Issue

2012-05-29 Thread Mark Tinka
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