Re: [c-nsp] MTU change on data link layer and connection degradation/loss
There are indeed few servers connected to the C3750G's, but the traffic between them is 10Mbps. Keeping the MTU at the constant value seems better practice to me as well. However, is it possible, that changing the data link layer MTU value could cause an outage or traffic degradation. regards, martin 2011/8/15 Andrew Miehs and...@2sheds.de: On 15/08/2011, at 2:39 AM, Martin T wrote: I have a following network topology: C3750G-12S[Gi1/0/12] - [ge-0/0/0]Juniper M10i[ge-1/0/0] - [Po1]Cisco 4506[Gi2/6] - [Gi1/0/1]C3750G-12S Is it a best practise to use the largest possible value on all interfaces or find out the largest supported MTU on the circuit and use this for all the interfaces? This depends on your traffic. Do you have servers connected to the 3750Gs that need to talk to another on the same switch with large amounts of traffic? Then setting a large MTU on the 3750G will be to your advantage. Setting all interfaces to the smallest value, will ensure that you don't have any PMTU problems should someone have the bright idea of dropping ICMP packets. If possible, try to keep your MTU at least large enough so that should someone decide to tunnel traffic that it will still be larger than 1500 bytes. Regards Andrew ___ 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] MTU - issue while doing VPLS over VPLS!
I have requirement of GRE over VPLS ? 20 remote sites routers connect to one central cisco router. Remote router : 3 WAN interface , 100 kpps throughput , MPLS / VPLS /GRE over VPLS Central router : 4 WAN interface , 600-900 kpps throughput , MPLS / VPLS /GRE over VPLS Regards, Dipesh Basnet From: Dipesh Basnet [mailto:dipesh.basn...@gmail.com] Sent: Tuesday, August 02, 2011 3:39 PM To: 'cisco-nsp@puck.nether.net' Subject: MTU - issue while doing VPLS over VPLS! Dear Sir , we are deploying Cisco metro Switch to create VPLS network as below. PC-Cisco Switch + Cisco switch E1 Link [ service provider] -Cisco Switch + Cisco Switch -internet For E1 link , we are using protocol converter that its Ethernet port only support MTU 1500. That means we have MTU 1500 for backhaul link. Now when we do VPLS or VPLS over VPLS , There are some application not working properly. I want to know , does Cisco Switch fragment the packet at its outer interface of the switch that is connect to E1 link. Or shall we ask Service provider to increase the MTU [ or place protocol converter that support higher MTU] Appreciate if you could help me with proper solution. Dipesh Basnet ___ 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] MTU - issue while doing VPLS over VPLS!
I have requirement of GRE over VPLS ? 20 remote sites routers connect to one central cisco router. Remote router : 3 WAN interface , 100 kpps throughput , MPLS / VPLS /GRE over VPLS Central router : 4 WAN interface , 600-900 kpps throughput , MPLS / VPLS /GRE over VPLS Please provide me , make and model number to meet the above requirement of CISCO routers Regards, Dipesh Basnet From: Dipesh Basnet [mailto:dipesh.basn...@gmail.com] Sent: Tuesday, August 02, 2011 3:39 PM To: 'cisco-nsp@puck.nether.net' Subject: MTU - issue while doing VPLS over VPLS! Dear Sir , we are deploying Cisco metro Switch to create VPLS network as below. PC-Cisco Switch + Cisco switch E1 Link [ service provider] -Cisco Switch + Cisco Switch -internet For E1 link , we are using protocol converter that its Ethernet port only support MTU 1500. That means we have MTU 1500 for backhaul link. Now when we do VPLS or VPLS over VPLS , There are some application not working properly. I want to know , does Cisco Switch fragment the packet at its outer interface of the switch that is connect to E1 link. Or shall we ask Service provider to increase the MTU [ or place protocol converter that support higher MTU] Appreciate if you could help me with proper solution. Dipesh Basnet ___ 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] BGP router upgrade
On 8/14/11 8:35 PM, Pete Lumbis wrote: Bottom line, I would under no situation ever consider NPE-G[12] for forwarding Internet peering traffic (wording chosen carefully:). And I have lot of love for them. A completely fair statement, it all comes down to throughput requirements. A hardware based platform will always beat the pants off of a software based platform, but when you talk about control plane flexibility and reducing your odds for forwarding problems, software is the way to go. Peering router selection isn't about throughput requirements, it's about PPS requirements in the face of what the Internet should decide to throw at the router at random time X+pi. pt ___ 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] best way to get around IPSEC subnet Conflicts.
I have and its working across about 7 sites currently. Trouble is that the same people that have 192.168.X.X always have the same dinky Firewalls that won't do Source (one-to-one)NAT Across a VPN tunnel. The Setup is heavy outbound (on our side) with a lot of ERP Printing to specific Printers. Already done the multiple inline networks setup as well. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Anton Yurchenko Sent: Monday, August 15, 2011 9:12 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] best way to get around IPSEC subnet Conflicts. Have you considered Source NATing remote side networks? It works fine for most applications. On 8/12/2011 12:53 PM, Brent Roberts wrote: I am looking for the best way to get around IP conflicts (On the Far Side) in fully redundant Hardware solution. I am working in a large Scale Hosted application environment and every 5th or so customer has the same RFC1918 Address that every other small shop has. I have a Pair of ASA 5520's (SEC-K9 8.2(2) in A/S) and it seems that I am either missing something or it may not be possible due to IPSEC priority. I typically use the SET-Reverse Router and redistribute static via OSPF to the L3 Core. I was thinking about moving to a 6509 with redundant sup720's and using IPSEC AWARE VRF's (1x 7600-SSC-400/2xSPA-IPSEC-2G) to get around this limitation. Any feedback on this idea. Negative/Positives of this setup? I am only looking to move about 100 meg aggregate of IPSec Traffic. Thoughts welcome on and off list. ___ 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/ ___ 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] 3750G Terminating a Metro-e circuit
Does anyone know of any issues with 3750G's and metro-e circuits? I vaguely remember hearing of issues where you couldn't disable auto-negotiation on the 3750G so it wouldn't like to transport gear that doesn't autoneg. I'm looking at a couple of metro-e circuits connected to 6509's that won't seem to link. I verified fiber and sfp types and I see light from the provider at both ends. ___ 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] best way to get around IPSEC subnet Conflicts.
Not sure about what everyone else is recommending but our solution (with several hundred B2B tunnels now) was simply to make it policy NEVER to run 1918 address space in the tunnel. We usually tell peers that they must provide public IP space which will then be NATted on our side. We also have a block of our own ARIN space that we sometimes use. Either way, it's always tunneled and NATted and never seen anywhere else. Extra config? Yes. Sanity? A little. -Hammer- I was a normal American nerd -Jack Herer On 08/12/2011 02:53 PM, Brent Roberts wrote: I am looking for the best way to get around IP conflicts (On the Far Side) in fully redundant Hardware solution. I am working in a large Scale Hosted application environment and every 5th or so customer has the same RFC1918 Address that every other small shop has. I have a Pair of ASA 5520's (SEC-K9 8.2(2) in A/S) and it seems that I am either missing something or it may not be possible due to IPSEC priority. I typically use the SET-Reverse Router and redistribute static via OSPF to the L3 Core. I was thinking about moving to a 6509 with redundant sup720's and using IPSEC AWARE VRF's (1x 7600-SSC-400/2xSPA-IPSEC-2G) to get around this limitation. Any feedback on this idea. Negative/Positives of this setup? I am only looking to move about 100 meg aggregate of IPSec Traffic. Thoughts welcome on and off list. ___ 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] best way to get around IPSEC subnet Conflicts.
On 8/15/2011 4:38 PM, -Hammer- wrote: Not sure about what everyone else is recommending but our solution (with several hundred B2B tunnels now) was simply to make it policy NEVER to run 1918 address space in the tunnel. We usually tell peers that they must provide public IP space which will then be NATted on our side. We also have a block of our own ARIN space that we sometimes use. Either way, it's always tunneled and NATted and never seen anywhere else. Extra config? Yes. Sanity? A little. -Hammer- I was a normal American nerd -Jack Herer On 08/12/2011 02:53 PM, Brent Roberts wrote: I am looking for the best way to get around IP conflicts (On the Far Side) in fully redundant Hardware solution. I am working in a large Scale Hosted application environment and every 5th or so customer has the same RFC1918 Address that every other small shop has. I have a Pair of ASA 5520's (SEC-K9 8.2(2) in A/S) and it seems that I am either missing something or it may not be possible due to IPSEC priority. I typically use the SET-Reverse Router and redistribute static via OSPF to the L3 Core. I was thinking about moving to a 6509 with redundant sup720's and using IPSEC AWARE VRF's (1x 7600-SSC-400/2xSPA-IPSEC-2G) to get around this limitation. Any feedback on this idea. Negative/Positives of this setup? I am only looking to move about 100 meg aggregate of IPSec Traffic. Thoughts welcome on and off list. ___ 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/ That's it. Public space. It pushes all the nasty stuff out to the edge companies. tv ___ 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] best way to get around IPSEC subnet Conflicts.
We use OpenVPN for such tunnels and put a Linux box at the customer end. That box can do both Source and destination NAT. On 8/12/2011 12:53 PM, Brent Roberts wrote: I am looking for the best way to get around IP conflicts (On the Far Side) in fully redundant Hardware solution. I am working in a large Scale Hosted application environment and every 5th or so customer has the same RFC1918 Address that every other small shop has. I have a Pair of ASA 5520's (SEC-K9 8.2(2) in A/S) and it seems that I am either missing something or it may not be possible due to IPSEC priority. I typically use the SET-Reverse Router and redistribute static via OSPF to the L3 Core. I was thinking about moving to a 6509 with redundant sup720's and using IPSEC AWARE VRF's (1x 7600-SSC-400/2xSPA-IPSEC-2G) to get around this limitation. Any feedback on this idea. Negative/Positives of this setup? I am only looking to move about 100 meg aggregate of IPSec Traffic. Thoughts welcome on and off list. ___ 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] best way to get around IPSEC subnet Conflicts.
Yeah I am familiar with that problem, never had to deal with so many firewall flavors until I worked at that job. I used to do NAT on my VPN gateway, it was not ASA but a 7300 box, but I think it should behave in a similar fashion. If my memory is not failing me we did static NAT because most of of traffic was B2B type of applications. Couple of times did source NAT too I believe. Check out this link, very helpful in understanding what comes after what in NAT/ACL/IPsec world, so that you know what to match on: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml On 8/15/2011 9:42 AM, Brent Roberts wrote: I have and its working across about 7 sites currently. Trouble is that the same people that have 192.168.X.X always have the same dinky Firewalls that won't do Source (one-to-one)NAT Across a VPN tunnel. The Setup is heavy outbound (on our side) with a lot of ERP Printing to specific Printers. Already done the multiple inline networks setup as well. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Anton Yurchenko Sent: Monday, August 15, 2011 9:12 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] best way to get around IPSEC subnet Conflicts. Have you considered Source NATing remote side networks? It works fine for most applications. On 8/12/2011 12:53 PM, Brent Roberts wrote: I am looking for the best way to get around IP conflicts (On the Far Side) in fully redundant Hardware solution. I am working in a large Scale Hosted application environment and every 5th or so customer has the same RFC1918 Address that every other small shop has. I have a Pair of ASA 5520's (SEC-K9 8.2(2) in A/S) and it seems that I am either missing something or it may not be possible due to IPSEC priority. I typically use the SET-Reverse Router and redistribute static via OSPF to the L3 Core. I was thinking about moving to a 6509 with redundant sup720's and using IPSEC AWARE VRF's (1x 7600-SSC-400/2xSPA-IPSEC-2G) to get around this limitation. Any feedback on this idea. Negative/Positives of this setup? I am only looking to move about 100 meg aggregate of IPSec Traffic. Thoughts welcome on and off list. ___ 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/ ___ 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] Brocade Vs Cisco
That is exactly what I am doing in our network - ASR9K as edge and MX480 as pure P router. Judy --- On Sat, 8/13/11, Ryan Finnesey rfinne...@gmail.com wrote: From: Ryan Finnesey rfinne...@gmail.com Subject: Re: [c-nsp] Brocade Vs Cisco To: 'Derick Winkworth' dwinkwo...@att.net, 'Gert Doering' g...@greenie.muc.de Cc: cisco-nsp@puck.nether.net Date: Saturday, August 13, 2011, 11:54 PM If I have the option to engineer to our requirements I would use cisco at the edge and Juniper at the core. Cheers Ryan From: Derick Winkworth [mailto:dwinkwo...@att.net] Sent: Saturday, August 13, 2011 9:08 AM To: Gert Doering; Ryan Finnesey Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Brocade Vs Cisco Engineer to your requirements. Cisco and Juniper are good vendors to have for variety. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.com _ From: Gert Doering g...@greenie.muc.de To: Ryan Finnesey rfinne...@gmail.com Cc: cisco-nsp@puck.nether.net Sent: Fri, August 12, 2011 2:52:44 AM Subject: Re: [c-nsp] Brocade Vs Cisco Hi, On Thu, Aug 11, 2011 at 09:00:32PM -0400, Ryan Finnesey wrote: What would be your preference between just Cisco or Juniper depends on what you want to do with it Recently, OS and TAC support quality at Juniper seriously went down the drain, so the original reason to want Juniper high quality operating system and very motivated company to iron out the remaining wrinkles seems to have been lost... OTOH, Cisco is still stuck in we have too many operating systems and we spend half our resources with BU in-fighting mode - which, I guess, will now be fixed by firing 10.000 folks from engineering so they won't get in the way of the in-fighting anymore... Right now, I'm not sure I'm trusting either company enough. 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-35655025 g...@net.informatik.tu-muenchen.de ___ 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] ASR's + GLBP
Hi Guys, After some advice on asr's,glbp+3750x's We currently have 7200's(LNS,MP-BGP,Inet, client tails etc(i.e. P/PE)) with G2's that are doing ~350Mb/sec(Our utilisation has increased dramatically over the last 6months)...we have failover 7200's ready to take over should the G2 7200's failunfortunately the failover 7200's only have npe400's in them, and would melt should they be needed. Therefore, we are looking at replacing the 7200's with ASR's, and also implementing a more robust switching infrastructure(i.e. 2 x 3750x stack) Having no experience with GLBP can it be used like so: 2 x ASRs running GLBP (The ASR's will be doing the same role as the existing 7200's), each one connected to both 3750x's via Portchan - We then have stacks of 2x2960S's as client facing switches, with portchan running from both 2960s-both 3750s. Hoping that with the above, both asr's will be active/active(So we dont have one sitting idle waiting for a failure), we can lose an asr, and experience minimal interruption, we can also lose a 3750 and also experience minimal interruption. Will this work? Thanks in advance. ___ 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] Brocade Vs Cisco
We run a mix of Cisco and Brocade (Foundry). The CES/CER2000 units have proven to be incredibly high performing and reliable as an MPLS L2VPN PE device. If we need to offer IP services we haul it via a VLL back to a Cisco ASR1000 located at a central POP (high performance IP services but expensive forwarding so not suitable for transport) for termination. There have been issues inter-oping MPLS L2VPN with the Cisco gear (in our deployment) so I'd stick to a single vendor for your PE device and try to avoid using LDP at all on the CES/CER platform as it does not scale as well and performs poorly compared with RSVP. When it comes to price vs performance, the CES has been pretty hard to beat and we looked at a LOT of other vendors. As for their IP capabilities, since we only run these with infrastructure routes (ISIS) and terminate VLLs, I can't give you any feedback on how they perform as an IP edge. McDonald On Thu, Aug 11, 2011 at 11:45 PM, Bradley Williamson bwilliam...@eatel.comwrote: Does anyone have any horror stories or gotcha's concerning Brocade? What about success stories? We are looking at Brocade, Cisco, and Juniper for a couple of upcoming projects and I am familiar with both Cisco and Juniper, but not so much with Brocade. We have a few of their small switches in our network, but that’s about the extent of my experience. We want to build an MPLS core capable of delivering triple-play services and as part of that, we will be building our a MetroE network to provide ethernet backhaul for mobile providers and also deliver L2VPN and L3VPN services to our business customers. I am a little skeptical of Brocade. I just do not understand how they can provide the performance they claim at half the price of the other guys. Any insight/advice would be appreciated. Brad ___ 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] Full BGP Feed Convergence Time on ASR 1006 RP2 Setup
Can anyone provide real world BGP Table convergence times on 3 full Peers on an ASR 1006 RP2 for IPV4. Strictly in the IP V4 world scheme. Timing reference being sought is for the equivalent of CLEAR IP BGP ALL Command. Service engine would be a ASR1000-ESP10. ___ 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] Brocade Vs Cisco
That sounds like a winning combination. -Original Message- From: judy teng Sent: Monday, August 15, 2011 7:20 PM To: 'Derick Winkworth' ; 'Gert Doering' ; Ryan Finnesey Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Brocade Vs Cisco That is exactly what I am doing in our network - ASR9K as edge and MX480 as pure P router. Judy --- On Sat, 8/13/11, Ryan Finnesey rfinne...@gmail.com wrote: From: Ryan Finnesey rfinne...@gmail.com Subject: Re: [c-nsp] Brocade Vs Cisco To: 'Derick Winkworth' dwinkwo...@att.net, 'Gert Doering' g...@greenie.muc.de Cc: cisco-nsp@puck.nether.net Date: Saturday, August 13, 2011, 11:54 PM If I have the option to engineer to our requirements I would use cisco at the edge and Juniper at the core. Cheers Ryan From: Derick Winkworth [mailto:dwinkwo...@att.net] Sent: Saturday, August 13, 2011 9:08 AM To: Gert Doering; Ryan Finnesey Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Brocade Vs Cisco Engineer to your requirements. Cisco and Juniper are good vendors to have for variety. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.com _ From: Gert Doering g...@greenie.muc.de To: Ryan Finnesey rfinne...@gmail.com Cc: cisco-nsp@puck.nether.net Sent: Fri, August 12, 2011 2:52:44 AM Subject: Re: [c-nsp] Brocade Vs Cisco Hi, On Thu, Aug 11, 2011 at 09:00:32PM -0400, Ryan Finnesey wrote: What would be your preference between just Cisco or Juniper depends on what you want to do with it Recently, OS and TAC support quality at Juniper seriously went down the drain, so the original reason to want Juniper high quality operating system and very motivated company to iron out the remaining wrinkles seems to have been lost... OTOH, Cisco is still stuck in we have too many operating systems and we spend half our resources with BU in-fighting mode - which, I guess, will now be fixed by firing 10.000 folks from engineering so they won't get in the way of the in-fighting anymore... Right now, I'm not sure I'm trusting either company enough. 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-35655025 g...@net.informatik.tu-muenchen.de ___ 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/ ___ 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] Pros/Cons to *disabling* mac-address aging-time routed-mac
I have inherited a setup: - cat6509E's running IOS: various flavors for SXF. In the process of upgrading to a standard-flavor of SXI4a. I see that all 650x have mac-address-table aging-time routed-mac enabled by default. There is a fair amount of inter-SVI communication that happens but it is within the same switch. I am thinking: Turning-off(mac-address aging-time 0 routed-mac) can only help but won't hurt! Any thoughts/experiences wrt to above would be appreciated. Thanks, ./Randy ___ 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] Pros/Cons to *disabling* mac-address aging-time routed-mac
Leave it on. There are reasons for it that I don't have at home with me. But its needed for span and other things to stop unicast flooding. On Aug 16, 2011 12:03 AM, Randy randy_94...@yahoo.com wrote: I have inherited a setup: - cat6509E's running IOS: various flavors for SXF. In the process of upgrading to a standard-flavor of SXI4a. I see that all 650x have mac-address-table aging-time routed-mac enabled by default. There is a fair amount of inter-SVI communication that happens but it is within the same switch. I am thinking: Turning-off(mac-address aging-time 0 routed-mac) can only help but won't hurt! Any thoughts/experiences wrt to above would be appreciated. Thanks, ./Randy ___ 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] Brocade Vs Cisco
Brocade MLX/XMR/CER/CES can be really good, I just wouldn't try to do everything on them, ie, P and PE, IPv4 IPv6 full table routing, multicast video. They do it all, but in my experience more software problems tend to surface the more things you do at once and you don't want it taking out all your services when this happens - design your network properly and seperate your MPLS P and PE, and have seperate IP routers with a simplified L2-transport-to-L3-router model for IP services such as Macca recommended. Patrick Tue, Aug 16, 2011 at 10:03:59AM +1000, McDonald Richards wrote: We run a mix of Cisco and Brocade (Foundry). The CES/CER2000 units have proven to be incredibly high performing and reliable as an MPLS L2VPN PE device. If we need to offer IP services we haul it via a VLL back to a Cisco ASR1000 located at a central POP (high performance IP services but expensive forwarding so not suitable for transport) for termination. There have been issues inter-oping MPLS L2VPN with the Cisco gear (in our deployment) so I'd stick to a single vendor for your PE device and try to avoid using LDP at all on the CES/CER platform as it does not scale as well and performs poorly compared with RSVP. When it comes to price vs performance, the CES has been pretty hard to beat and we looked at a LOT of other vendors. As for their IP capabilities, since we only run these with infrastructure routes (ISIS) and terminate VLLs, I can't give you any feedback on how they perform as an IP edge. McDonald On Thu, Aug 11, 2011 at 11:45 PM, Bradley Williamson bwilliam...@eatel.comwrote: Does anyone have any horror stories or gotcha's concerning Brocade? What about success stories? We are looking at Brocade, Cisco, and Juniper for a couple of upcoming projects and I am familiar with both Cisco and Juniper, but not so much with Brocade. We have a few of their small switches in our network, but that?s about the extent of my experience. We want to build an MPLS core capable of delivering triple-play services and as part of that, we will be building our a MetroE network to provide ethernet backhaul for mobile providers and also deliver L2VPN and L3VPN services to our business customers. I am a little skeptical of Brocade. I just do not understand how they can provide the performance they claim at half the price of the other guys. Any insight/advice would be appreciated. Brad ___ 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/ ___ 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] Brocade Vs Cisco
On 8/13/2011 10:04 PM, Scott Granados wrote: You know that's interesting, I've been following this thread but I totally agree with you. I very much like Juniper on the core side and I really like their switches but it's hard to beat devices like the 7200 for circuit aggregation at the edges. Another place where I think Cisco wins hands down is on the VPN side. I really got to dig in to the ASA product line during my last gig and with some help from some really skilled folks on this list I really got pretty good with the devices pretty fast. I've used te Juniper SRX line for similar functions and the ASA just makes more sense, at least to me. I just wish Cisco was wirespeed more than they are. Juniper exists precisely because Cisco wasn't making adequate progress on this front during the late nineties. I don't see providing someone a gig interface but only be able to forward at a 3rd of that rate. Juniper does better in this area but then again I've found Junos to be more buggy, in surprisingly basic areas as well so it's a toss up. I think your comment makes a lot of sense. -Original Message- From: Ryan Finnesey Sent: Saturday, August 13, 2011 7:54 PM To: 'Derick Winkworth' ; 'Gert Doering' Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Brocade Vs Cisco If I have the option to engineer to our requirements I would use cisco at the edge and Juniper at the core. Cheers Ryan From: Derick Winkworth [mailto:dwinkwo...@att.net] Sent: Saturday, August 13, 2011 9:08 AM To: Gert Doering; Ryan Finnesey Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Brocade Vs Cisco Engineer to your requirements. Cisco and Juniper are good vendors to have for variety. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.com _ From: Gert Doering g...@greenie.muc.de To: Ryan Finnesey rfinne...@gmail.com Cc: cisco-nsp@puck.nether.net Sent: Fri, August 12, 2011 2:52:44 AM Subject: Re: [c-nsp] Brocade Vs Cisco Hi, On Thu, Aug 11, 2011 at 09:00:32PM -0400, Ryan Finnesey wrote: What would be your preference between just Cisco or Juniper depends on what you want to do with it Recently, OS and TAC support quality at Juniper seriously went down the drain, so the original reason to want Juniper high quality operating system and very motivated company to iron out the remaining wrinkles seems to have been lost... OTOH, Cisco is still stuck in we have too many operating systems and we spend half our resources with BU in-fighting mode - which, I guess, will now be fixed by firing 10.000 folks from engineering so they won't get in the way of the in-fighting anymore... Right now, I'm not sure I'm trusting either company enough. gert ___ 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] Brocade Vs Cisco
On 8/14/2011 8:55 AM, Mark Tinka wrote: On Sunday, August 14, 2011 10:04:17 AM Scott Granados wrote: You know that's interesting, I've been following this thread but I totally agree with you. I very much like Juniper on the core side and I really like their switches... Really? We use Juniper's EX3200/4200 products, and have had tons and tons of (software) problems since inception. Truth be told, it was Juniper's first foray into the switching space, and the whole of Junos 9 which launched the platform was basically a waste of time for even the most basic of features. In this space, Cisco spoilt us. A lot of effort and attention was diverted during the Junos 9 days towards finalizing the integration of the security product line with the core routing forwarding technologies. Things might have turned out differently had they been able to put more distance between the rollouts of the switching product line and the SRX series. The EX3200/4200 have certainly gotten better and easier to use with Junos 10, but we've come across strange hardware problems that can't be solved by software, it's quite sad. In one case, we had to swap out EX4200's with Cisco's new ME3600X's (Layer 2 only). I haven't played with the EX8200 (chassis model) much, but you can find both good and bad feedback about them on the 'j-nsp' mailing list. In general, they seem to be a little better than the 1U models. That's not accidental. Moreover, the EX was what finally showed that the single Junos advantage Juniper have been pushing really isn't feasible. And you know what, this isn't necessarily a bad thing. To a lesser extent, they're encountering challenges similar to the ones Cisco faced when trying to integrate/borg various purchased product lines. but it's hard to beat devices like the 7200 for circuit aggregation at the edges. Here, I have to agree. When it comes to non-Ethernet aggregation, the 7200 is great. We even choose it before the ASR1000, as it's unlikely a dedicated non-Ethernet NPE-G2 aggregation box will be running out of steam anytime soon. But then again, Juniper haven't had a strong competitor in this space. Non-Ethernet support on the M7i/M10i is present, but the 7200 simply does a better job. One area where Juniper need to quickly beef up is something to compete against the ASR1000. Juniper still don't have a box that will do 100Mbps, 1Gbps, 10Gbps and non-Ethernet at a reasonable $$ value. This is where the ASR1000 is cleaning house. I hear something is in the works, but the market is moving. For the Metro-E Access, Juniper fell short on the MX80, IMHO. They had such a huge opportunity there to eat up lots of Cisco, Huawei and ALU business. They need a 1U platform that is a proper Metro-E Access platform in terms of price, port density and features. Something is in the works, I hear. Another place where I think Cisco wins hands down is on the VPN side. I really got to dig in to the ASA product line during my last gig and with some help from some really skilled folks on this list I really got pretty good with the devices pretty fast. I've used te Juniper SRX line for similar functions and the ASA just makes more sense, at least to me. Not so heavy on the VPN side of things here. A couple of 2811's running IPSec/VPN's makes us happy. But if the market is anything to go by, the Netscreen's and SSG's have been very good VPN platforms, so I guess Juniper did something right there. Netscreen did something right there . . . From what I've been seeing on the 'j-nsp', the SRX is quite formidable but has been plagued by numerous software problems. Those seem to be getting cleared up, and I think this platform stands to be a serious force in the future. 4 billion dollars and 7 years later, we're reminded of how formidable integration challenges can be. I just wish Cisco was wirespeed more than they are. I don't see providing someone a gig interface but only be able to forward at a 3rd of that rate. Juniper does better in this area... You need to consider the platforms and their generation when comparing raw forwarding performance. If you look at the late '90's and early 2000's, Cisco were playing catch-up to Juniper for high-end forwarding. However, Cisco's ASR1000, ASR9000 and CRS are a good match for Juniper's M-, MX- and T-series routers, especially if you're looking at the advances both vendors have made in the last 3 - 4 years. That's why it was much easier for us to make a decision on which vendor to take as early back as 2005, purely on performance; but in 2011, it really isn't that easy to judge purely on performance. As I said before, not much technical difference for us, today, if we have a Juniper or Cisco in the network. 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] MTU - issue while doing VPLS over VPLS!
CISCO1941-SEC/K9 Cisco 1941 Security Bundle w/SEC license PAK CAB-ACSA AC Power Cord (India/South Africa), C13, BS 546, 1.8m S190UK9-15104M Cisco 1900 IOS UNIVERSAL PWR-1941-AC Cisco 1941 AC Power Supply ISR-CCP-EXP Cisco Config Pro Express on Router Flash MEM-1900-512MB-DEF 512MB Default DRAM for Cisco 1941 ISR MEM-CF-256MB 256MB Compact Flash for Cisco 1900, 2900, 3900 ISR SL-19-IPB-K9 IP Base License for Cisco 1900 SL-19-SEC-K9 Security License for Cisco 1900 CON-SNT-1941SEC SMARTNET 8X5XNBD Cisco 1941 Security Bundle w/SEC license Does above support GRE over VPLS as per the requirement below? Regards, Dipesh Basnet From: Dipesh Basnet [mailto:dipesh.basn...@gmail.com] Sent: Monday, August 15, 2011 12:51 PM To: 'cisco-nsp@puck.nether.net' Subject: RE: MTU - issue while doing VPLS over VPLS! I have requirement of GRE over VPLS ? 20 remote sites routers connect to one central cisco router. Remote router : 3 WAN interface , 100 kpps throughput , MPLS / VPLS /GRE over VPLS Central router : 4 WAN interface , 600-900 kpps throughput , MPLS / VPLS /GRE over VPLS Please provide me , make and model number to meet the above requirement of CISCO routers Regards, Dipesh Basnet From: Dipesh Basnet [mailto:dipesh.basn...@gmail.com] Sent: Tuesday, August 02, 2011 3:39 PM To: 'cisco-nsp@puck.nether.net' Subject: MTU - issue while doing VPLS over VPLS! Dear Sir , we are deploying Cisco metro Switch to create VPLS network as below. PC-Cisco Switch + Cisco switch E1 Link [ service provider] -Cisco Switch + Cisco Switch -internet For E1 link , we are using protocol converter that its Ethernet port only support MTU 1500. That means we have MTU 1500 for backhaul link. Now when we do VPLS or VPLS over VPLS , There are some application not working properly. I want to know , does Cisco Switch fragment the packet at its outer interface of the switch that is connect to E1 link. Or shall we ask Service provider to increase the MTU [ or place protocol converter that support higher MTU] Appreciate if you could help me with proper solution. Dipesh Basnet ___ 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/
