Re: [c-nsp] BFD in XR 3.9.1

[Richard A Steenbergen]

On Wed, Aug 25, 2010 at 09:08:42AM +1200, Pshem Kowalczyk wrote:
> that surprising).  We have encountered one limitation - currently BFD
> over ethtrunks is not supported (at least on 9k). We tested it with
> 20ms intervals (even though 15ms is the minimal value Cisco advised us
> to use 20ms).

BFD is an IP based protocol, it's completely ignorant of L2 multipath 
and will almost always get hashed over a single link arbitrarily. This 
means that most failures will not be detected at all, and even if the 
packets do happen to get hashed on the physical member which goes down, 
it will bring down the entire port-channel.

-- 
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
___
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] Hiding MPLS L3VPN hops from the CE

[Mark Tinka]

On Wednesday, August 25, 2010 05:15:43 am Gert Doering 
wrote:

> I don't really want to start a heated debate on whether
> topology hiding is good or bad -

I guess that ship has sailed :-).

> but it comes with some
> consequences :-)

We prefer not to hide our topology. Granted, for customer 
VPN's, we tend to implement l2vpn's over l3vpn's for obvious 
reasons. But since a number of our customers are ISP's, and 
we know a bunch of users have some clue re: traceroutes, 
MTR, e.t.c., we try not to make their lives hard by hiding 
the network topology.

Any determined attacker can always find ways to get into 
your network if it's weak. We'd rather focus energies on 
implementing secure router configurations, good operational 
practices and proper change management, rather than relying 
on obscurity :-).

But, YMMV :-).

Mark.


signature.asc
Description: This is a digitally signed message part.
___
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] BFD in XR 3.9.1

[Mark Tinka]

On Wednesday, August 25, 2010 02:11:11 am Vikas Sharma 
wrote:

> I am planning to test BFD in XR 3.9.1 (both on 12k and on
> CRS-1). Any testing already done and feedback is
> appreciated.

No support for 802.1AX LACP links. Planned for IOS XR 4.0 or 
later.

Mark.


signature.asc
Description: This is a digitally signed message part.
___
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] 3750 stack

[Alexander Clouter]

Bøvre Jon Harald  wrote:
> 
> We have a number of 3750 stacks with anything from 2 to 8 switches.
> 
> Our standard when configuring new stack:
> First switch numbered 9, second switch numbered 8
> Switch # 9 given priority 15 (highest)
>
Interesting, Cisco told us it is generally a bad idea going much above 
five switch stacks.  Something to do with the fact that at the rear of 
the switch you have a token ring-esque system and 40Gbps of backplane 
(off the top of my head).  In the early code they only had a single 
token flying around the switches which caused horrible latency woes I 
would imagine, but things improved when they had multiple tokens 
rotating through the loop.

Either way, I also thought when an 'interesting' decision had to be made 
traffic had to be punted upto the master switch and back down.  
Obviously the longer the chain the worse *everything* gets.

However I doubt our users would actually notice.  Any reason you do not 
split your stack in half?  Only curious.
 
Cheers

-- 
Alexander Clouter
.sigmonster says: BOFH excuse #330:
  quantum decoherence

___
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] 3750 stack

[Matt Zagrabelny]

2010/8/24 Alan Buxey :
> Hi,
>
>> We have a number of 3750 stacks with anything from 2 to 8 switches.
>>
>> Our standard when configuring new stack:
>> First switch numbered 9, second switch numbered 8
>> Switch # 9 given priority 15 (highest)
>>
>> Advantage?
>> We are able to add new switches 7 -6- 5 -> without any downtime and does add 
>> switches during daytime with no impact to customers
>
> I'm intrigued by the first switch being numbered 9 - why not just numbered
> 1 and go up incrementally?  obviously 'priority 15' is important... just 
> wondering
> what wierd little thing I missed...

You don't need to provision the switch before adding it to the stack,
it will come up as switch 1 and then you can configure it as being
part of the stack. FWIW, we start at switch number 1 and priority 15
and increment and decrement, respectively, from there (and do offline
provisioning before adding to the stack.)

-matt zagrabelny

___
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] Hiding MPLS L3VPN hops from the CE

[Gert Doering]

Hi,

On Tue, Aug 24, 2010 at 02:38:03PM -0500, Justin Shore wrote:
> On 8/22/2010 6:31 AM, Peter Hicks wrote:
> >Just out of interest - is this for marketing reasons, or technical?
> 
> At my ISP it was for security reasons.  Our infrastructure was privately 
> addressed to limit exposure to the outside world.  In theory, a true 
> MPLS P core is analogous to a pure L2 switching core.  There's no reason 
> for anyone to ever know that those hops even exist.  

Just to add a contrary point of view.  One of our uplinks is operating a
global MPLS network.  If we do a traceroute somewhere that's passing 
via that uplink, we see their edge router facing us, and then we see 
the first router "behind" their network.

We had a few issues with packet loss on certain paths, sometimes up to
50% over the course of *weeks*, which hinted at a defective or overloaded 
link "somewhere".  In one specific case, we had symmetric mtrs, proving 
that the problem was in their network - but due to the MPLS topology 
hiding, we could not further pinpoint it.  It was "somewhere between 
Frankfurt/DE and Los Angeles/US".

We opened a ticket, their support did a one-time ping, saw no loss,
closed the ticket.  We tried yelling at our account manager for a while,
but gave up after getting nowhere - and the ISP at the far end just
terminated their contract with this transit ISP, solving the problem
for us as well...  and when our contract is due for renewal, this will 
be one of the factors affecting decisions.

So - *if* you do topology hiding, taking away network diagnosis 
capabilities from those of your customers that know how to read "mtr"
output - *then* make sure that your own network monitoring is really
up to speed, and that you notice if links are overloaded, have packet
loss, etc. etc.

I don't really want to start a heated debate on whether topology hiding
is good or bad - but it comes with some consequences :-)

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


pgpadfizfitJJ.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] BFD in XR 3.9.1

[Pshem Kowalczyk]

Hi,

On 25 August 2010 06:11, Vikas Sharma  wrote:
> Hi,
>
> I am planning to test BFD in XR 3.9.1 (both on 12k and on CRS-1). Any
> testing already done and feedback is appreciated.

We've tested BFD on 3.9.1 on 9k. Work's without any problems,
detecting all failures. We tested it only on 10G interfaces. It
appears that with 10G WANPHY G.703 is sometimes faster (which is not
that surprising).  We have encountered one limitation - currently BFD
over ethtrunks is not supported (at least on 9k). We tested it with
20ms intervals (even though 15ms is the minimal value Cisco advised us
to use 20ms).
There is no BFD over RSVP-TE in that software version, but I heard
that it's planned.

kind regards
Pshem
___
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] 3750 stack

[Alan Buxey]

Hi,

> We have a number of 3750 stacks with anything from 2 to 8 switches.
> 
> Our standard when configuring new stack:
> First switch numbered 9, second switch numbered 8
> Switch # 9 given priority 15 (highest)
> 
> Advantage?
> We are able to add new switches 7 -6- 5 -> without any downtime and does add 
> switches during daytime with no impact to customers

I'm intrigued by the first switch being numbered 9 - why not just numbered
1 and go up incrementally?  obviously 'priority 15' is important... just 
wondering
what wierd little thing I missed...

alan
___
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] 3750 stack

[Bøvre Jon Harald]

Hi

We have a number of 3750 stacks with anything from 2 to 8 switches.

Our standard when configuring new stack:
First switch numbered 9, second switch numbered 8
Switch # 9 given priority 15 (highest)

Advantage?
We are able to add new switches 7 -6- 5 -> without any downtime and does add 
switches during daytime with no impact to customers



Jon Harald Bøvre



Fra: cisco-nsp-boun...@puck.nether.net [cisco-nsp-boun...@puck.nether.net] 
på vegne av James Greig [ja...@mor-pah.net]
Sendt: 24. august 2010 17:54
Til: Matt Bennett
Kopi: cisco-nsp@puck.nether.net
Emne: Re: [c-nsp] 3750 stack

  Hi Matt,

That's great, thanks for the advice.

Regards,
James Greig

On 24/08/2010 12:37, Matt Bennett wrote:
> Hi James,
>
> You could power off and un-provision the old switch letting you keep
> the rest of the config (but losing the port configs from the removed
> switch), otherwise your new switch will join the stack as module 3.
> Cisco example here:
> http://www.cisco.com/en/US/products/hw/switches/ps5023/products_configuration_example09186a00807811ad.shtml#stack6
>
> It doesn't really matter which is master if they have same IOS, so you
> could leave the existing 24port one powered up and add the new one to
> the stack.
>
> Regards,
> Matt
>
>
> On Tue, Aug 24, 2010 at 11:01 AM, James Greig  > wrote:
>
> Hi People,
>
> I've two live stacked 24 port 100meg 3750's in master/slave.  What
> i'm aiming to do is replace the 24 port master with a 48port
> gigabit 3750 (same image rev) switch with the gigabit provisioned
> as the new master.  At a guess the config is going to need redoing
> as the ports are no longer named fa*/*/* and will become gi*/*/*.
>  Are there any other issues i'm going to encounter?
>
> Kind Regards
>
> James Greig
> ___
> 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] VSS, ACE and RHI

[Pavel Dimow]

Hello,

I am planning VSS installation with one ACE and FWSM per physical
chassis. As FWSM is "behind" the ACE I have
no problem using RHI, but I was wondering is RHI supported in VSS
scenario or not?  I found some information about
FWSM not supporting RHI, but in my setup I think I should not worry
about it. We are running FWSM in routed mode.
___
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] Command authorization with RADIUS possible on IOS?

[Alan Buxey]

Hi,

> "RADIUS does not allow users to control which commands can be executed
> on a router and which cannot."

...on Cisco . other vendors have no problems using RADIUS as the
command control system... 

alan

___
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] Hiding MPLS L3VPN hops from the CE

[Justin Shore]

On 8/22/2010 6:31 AM, Peter Hicks wrote:

Just out of interest - is this for marketing reasons, or technical?


At my ISP it was for security reasons.  Our infrastructure was privately 
addressed to limit exposure to the outside world.  In theory, a true 
MPLS P core is analogous to a pure L2 switching core.  There's no reason 
for anyone to ever know that those hops even exist.  In addition, it 
also helps prevent a confused user from thinking something silly when 
they see a RFC1918 address in their traceroute.  Oh the stories I could 
tell like the time a guy thought IANA had hijacked our network because 
"their IPs" appeared in the middle of our network.  Classic...

___
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] Cisco CISCO7606-S Module

[Mohammad Khalil]

hi Arie

we made the hard reset and the logs still appear so TAC informed us that the 
module is faulty and we ordered a new one
Thanks a lot for your help

Regards,
Mohammad Khalil

> Subject: RE: [c-nsp] Cisco CISCO7606-S Module
> Date: Sun, 22 Aug 2010 15:37:16 +0200
> From: avay...@cisco.com
> To: eng_m...@hotmail.com; cisco-nsp@puck.nether.net
> 
> Mohammad,
> 
> This could be (after a very quick query) related to CSCef46923 "Group of
> 4 ports on WS-X6516-xx modules may stop forwarding traffic"
> 
> These are the release notes:
> PROBLEM/SYMPTOMS
> 
> Under very rare conditions, a group of ports on the same port-ASIC may
> experience connectivity issue. This issue can occur on any module which
> uses the same port-ASIC as WS-X6516-GE-TX.
> 
> The following syslog messages might also be seen, but is not required to
> observe the issue.
> 
> %PM_SCP-SP-6-LCP_FW_ERR_INFORM: Module 4 is experiencing the following
> error:
> Pinnacle #0, Frames with Bad Packet CRC Error (PI_CI_S_PKTCRC_ERR -
> 0xC7) = 
> 110
> 
> 
> Syslog Messages update  (3/14/05)
> ==
> 
> Examples of Syslog message from IOS:
> __
> %PM_SCP-SP-2-LCP_FW_ERR_INFORM: Module 5 is experiencing the following
> error:
> PINNACLE Pb transient parity error detected : ports - 1 3 5 7
> 
> %PM_SCP-SP-2-LCP_FW_ERR_INFORM: Module 5 is experiencing the following
> error:
> Bus Asic #1 transient Pb error.  Recovered. (0x1234, 0x5678)
> 
> 
> Examples of Syslog message from CatOS:
> __
>  
> %SYS-3-PKTBUFFERFAIL_ERRDIS:Packet buffer failure detected.
> Err-disabling 
> port 5/5.
>  
> %SYS-3-PKTBUFFERFAIL_PWRCYCLE:Packet buffer failure detected. Power
> cycling
> module 5.
>  
> __
> 
> Condition
> =
> The problem usually happens to a group of ports that are connected 
> through the same ASIC.
>   
> WORKAROUND
> ==
> The problem will usually recover after hard-reset the module.  If the
> problem
> keeps happening on the same module, please contact TAC.
> 
> 
> 
> 
> 
> 
> So, I would suggest you contact TAC for this...
> Arie
> 
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mohammad Khalil
> Sent: Sunday, August 22, 2010 10:26
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Cisco CISCO7606-S Module
> 
> 
> 
> 
> We
> are facing some issues with our Cisco CISCO7606-S on the
> module SFM-capable 48 port 10/100/1000mb RJ45 (Model Number
> WS-X6548-GE-TX) 
> please see the log below:Aug 21 03:53:18.275 EET:
> %PM_SCP-SP-2-LCP_FW_ERR_INFORM: Module 3 is experiencing the following
> error: Bus Asic #0 transient Pb error.  Recovered (0x, 0x0042) 
> Aug 21 03:53:31.327 EET: %PM_SCP-SP-2-LCP_FW_ERR_INFORM: Module 3 is
> experiencing the following error: Bus Asic #0 transient Pb error.
> Recovered (0x, 0x0042) 
> Aug 21 03:53:44.579 EET: %PM_SCP-SP-2-LCP_FW_ERR_INFORM: Module 3 is
> experiencing the following error: Bus Asic #0 transient Pb error.
> Recovered (0x, 0x0046) 
> Aug 21 03:53:57.631 EET: %PM_SCP-SP-2-LCP_FW_ERR_INFORM: Module 3 is
> experiencing the following error: Bus Asic #0 transient Pb error.
> Recovered (0x, 0x0042) 
> Aug 21 03:54:11.392 EET: %PM_SCP-SP-2-LCP_FW_ERR_INFORM: Module 3 is
> experiencing the following error: Bus Asic #0 transient Pb error.
> Recovered (0x, 0x0042)
> any ideas ?  
> 
> Thanks in advance
> Best Regards,
> 
> 
> 
> 
> ___
> 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] BFD in XR 3.9.1

[Vikas Sharma]

Hi,

I am planning to test BFD in XR 3.9.1 (both on 12k and on CRS-1). Any
testing already done and feedback is appreciated.

Regards,
Vikas Sharma
___
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] Jumbo Frames Support on Datacenter Switches

[Asbjorn Hojmark - Lists]

On Tue, 24 Aug 2010 15:17:18 +, you wrote:

> The 4500 series switches are not comparable to the 4900 switches.

I find that comment a bit funny. The Catalyst 4900 switches *are* in
all practical sense Catalyst 4500 switches.

4928  = 4500/SupV
4948  = 4500/SupV
4948-10G  = 4500/SupV-10G
4948E-10G = 4500/Sup6-E
4900M = 4500/Sup6-E

> 4900 series are targeted for datacenter use; 4500 is not. 

Yes, the 4900s have more line rate ports (and that *is* important in
the DC), but that's mainly because they have fewer of them.

-A

___
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] Command authorization with RADIUS possible on IOS?

[Peter Rathlev]

Just out of curiosity: Is command authorization (including
"config-commands") possible on Cisco IOS if you're using RADIUS and not
TACACS+?

A document on cisco.com comparing TACACS+ and RADIUS says:

"RADIUS does not allow users to control which commands can be executed
on a router and which cannot."

http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0080094e99.shtml#comp_router_mgt

The document is somewhat old, but they make it sound like it's a
protocol limitation.

If command authorization is possible with RADIUS a hint to some
documentation would be very welcome.

-- 
Peter


___
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] 3750 stack

[James Greig]

 Hi Matt,

That's great, thanks for the advice.

Regards,
James Greig

On 24/08/2010 12:37, Matt Bennett wrote:

Hi James,

You could power off and un-provision the old switch letting you keep 
the rest of the config (but losing the port configs from the removed 
switch), otherwise your new switch will join the stack as module 3. 
Cisco example here:

http://www.cisco.com/en/US/products/hw/switches/ps5023/products_configuration_example09186a00807811ad.shtml#stack6

It doesn't really matter which is master if they have same IOS, so you 
could leave the existing 24port one powered up and add the new one to 
the stack.


Regards,
Matt


On Tue, Aug 24, 2010 at 11:01 AM, James Greig > wrote:


Hi People,

I've two live stacked 24 port 100meg 3750's in master/slave.  What
i'm aiming to do is replace the 24 port master with a 48port
gigabit 3750 (same image rev) switch with the gigabit provisioned
as the new master.  At a guess the config is going to need redoing
as the ports are no longer named fa*/*/* and will become gi*/*/*.
 Are there any other issues i'm going to encounter?

Kind Regards

James Greig
___
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] Jumbo Frames Support on Datacenter Switches

[Ramcharan, Vijay A]

Google search for "4900 data sheet" 
First link goes to a product page for 4900 series switches 

Review data sheets
Catalyst 4948, 4948 10G, 4948E, 4928, 4900M
Jumbo frame support on all ports 

If in doubt, contact Cisco TAC or your local Cisco sales representative.

The 4500 series switches are not comparable to the 4900 switches. 4900
series are targeted for datacenter use; 4500 is not. 

Vijay Ramcharan 
 

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Bulleri, Carlos
Sent: Tuesday, August 24, 2010 10:21 AM
To: 'cisco-nsp@puck.nether.net'
Subject: [c-nsp] Jumbo Frames Support on Datacenter Switches


We currently have a 4500 switch with a SupII+ on our Datacenter and all
our server farm is ran through it. I'm trying to redesign our
Architecture to add multiple path to  gain some redundancy so I'm trying
to replace the one switch with 2 switches directly mounted on the server
rack.

I'm looking at the 4900 series as a possibility, I like the capacity and
throughput as well as the power redundancy options available, but I have
a question in regards to Jumbo Frame support. The 4500 series will only
support Jumbo frames on non-blocking ports. This limits the amount of
ports available and I need to enable this feature on a larger amount of
ports to increase performance on  our iSCSI storage device. I've found
no documentation on the 4900 series in regards to jumbo frame support
and I've even found some references indicating that they have the same
limitation as their 4500 series predecessors.

Has anyone successfully implemented Jumbo Frames on a 4900 series?
Should I be looking on a different line of switches all together??



Thanks!!

Carlos.



___
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] Jumbo Frames Support on Datacenter Switches

[David Prall]

Carlos,
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps6021/product_da
ta_sheet0900aecd8017a72e.html

Layer 2 Features
Jumbo frames on all ports (up to 9216 bytes)

Layer 3 Features
Jumbo frames on all ports (up to 9216 bytes)

David

--
http://dcp.dcptech.com

> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Bulleri, Carlos
> Sent: Tuesday, August 24, 2010 10:21 AM
> To: 'cisco-nsp@puck.nether.net'
> Subject: [c-nsp] Jumbo Frames Support on Datacenter Switches
> 
> 
> We currently have a 4500 switch with a SupII+ on our Datacenter and all
> our server farm is ran through it. I'm trying to redesign our
> Architecture to add multiple path to  gain some redundancy so I'm
> trying to replace the one switch with 2 switches directly mounted on
> the server rack.
> 
> I'm looking at the 4900 series as a possibility, I like the capacity
> and throughput as well as the power redundancy options available, but I
> have a question in regards to Jumbo Frame support. The 4500 series will
> only support Jumbo frames on non-blocking ports. This limits the amount
> of ports available and I need to enable this feature on a larger amount
> of ports to increase performance on  our iSCSI storage device. I've
> found no documentation on the 4900 series in regards to jumbo frame
> support and I've even found some references indicating that they have
> the same limitation as their 4500 series predecessors.
> 
> Has anyone successfully implemented Jumbo Frames on a 4900 series?
> Should I be looking on a different line of switches all together??
> 
> 
> 
> Thanks!!
> 
> Carlos.
> 
> 
> 
> ___
> 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] Jumbo Frames Support on Datacenter Switches

[Bulleri, Carlos]

We currently have a 4500 switch with a SupII+ on our Datacenter and all our 
server farm is ran through it. I'm trying to redesign our Architecture to add 
multiple path to  gain some redundancy so I'm trying to replace the one switch 
with 2 switches directly mounted on the server rack.

I'm looking at the 4900 series as a possibility, I like the capacity and 
throughput as well as the power redundancy options available, but I have a 
question in regards to Jumbo Frame support. The 4500 series will only support 
Jumbo frames on non-blocking ports. This limits the amount of ports available 
and I need to enable this feature on a larger amount of ports to increase 
performance on  our iSCSI storage device. I've found no documentation on the 
4900 series in regards to jumbo frame support and I've even found some 
references indicating that they have the same limitation as their 4500 series 
predecessors.

Has anyone successfully implemented Jumbo Frames on a 4900 series? Should I be 
looking on a different line of switches all together??



Thanks!!

Carlos.



___
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] Storm-Control on server switch uplinks.

[Saku Ytti]

On (2010-08-24 09:48 -0400), Christina Klam wrote:

> Thank you everyone.  I will set the broadcast and multicast
> storm-control to 0.35 (35%) on the interinks between the distribution
> and access layer switches.   At a later time, I will add the filters to
> all edge ports as well.

0.35 in IOS config is 0.35% not 35%. 0.35 would be 3.5Mbps on 1GE, which in
turn could be 300pps to 10kpps, assuming MTU of 1500.

It is shame not all platforms allow setting the limit as pps.

-- 
  ++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/

Re: [c-nsp] VWIC2-1MFT-G703

[Lauri Turunen]

On 24.8.2010 16:39, Andrew Gabriel wrote:

Hi,

We are deploying a bunch of E1s across Asia and EMEA, and were told by
our provider that for the sites that are G.703 they would recommend
the VWIC2-1MFT-G703 card rather than the regular channelized E1 cards.

Most of the E1 links G.703 connectivity I have seen typically work
fine with the VWIC2-2MFT-T1/E1 type card.

So would the VWIC2-2MFT-T1/E1 work for any E1 link, or do we really
need to buy the VWIC2-1MFT-G703 card that is more expensive and
difficult to source?

Thanks,
-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/


Hello,

VWIC2-(1|2)MFT-G703 is more expensive probably because it provides both 
G.703 (unstructured) and G.704 (unstructurized) services. E1 means G.704 
which steals one timeslot 0 for synchronization purposes providing 64kb 
less capacity than an unstructured G.703 (2,048kbps and 1,984kbps 
respectively). And of course with E1 you can provide 64kb timeslots & 
voice services


So VWIC2-2MFT-T1/E1 is only capable of structured service. It depends on 
your provider what they are willing to provide. If they provide G.704, 
it doesen't matter which card you have. The cheaper, the better, aye?


Btw, if you are going to have two E1s one one card, remember to take 
into account the clocking independence from different lines. If 
secondary port syncs to the primary port and the lines happen to have 
different clocking, the second line will experience slips. Thats one 
nasty thing to forget to take into account :-)


Regards,
/Lauri
___
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] VWIC2-1MFT-G703

[cisconsp]

Unframed E1 support. Some telcos in EMEA sometimes do that and refuse to
change so we had to start shipping the VWIC2-2MFT-G703 instead of the
regular VWIC2-2MFT-T1/E1 that we would use in the americas.

John


-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Andrew Gabriel
Sent: Tuesday, August 24, 2010 8:40 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] VWIC2-1MFT-G703

Hi,

We are deploying a bunch of E1s across Asia and EMEA, and were told by
our provider that for the sites that are G.703 they would recommend
the VWIC2-1MFT-G703 card rather than the regular channelized E1 cards.

Most of the E1 links G.703 connectivity I have seen typically work
fine with the VWIC2-2MFT-T1/E1 type card.

So would the VWIC2-2MFT-T1/E1 work for any E1 link, or do we really
need to buy the VWIC2-1MFT-G703 card that is more expensive and
difficult to source?

Thanks,
-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/

___
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] Storm-Control on server switch uplinks.

[Christina Klam]

Thank you everyone.  I will set the broadcast and multicast
storm-control to 0.35 (35%) on the interinks between the distribution
and access layer switches.   At a later time, I will add the filters to
all edge ports as well.

Thank you for your help,
Christina

> 
> Today's Topics:
> 
>1. Re: Storm-Control on server switch uplinks. (Saku Ytti)
>2. Re: Storm-Control on server switch uplinks. (Phil Mayers)
>3. Re: Storm-Control on server switch uplinks. (Peter Rathlev)
>4. 3750 stack (James Greig)
>5. Re: Storm-Control on server switch uplinks. (Saku Ytti)
>6. Re: Cogent IOS upgrade == BGP-3, "update malformed" (Tima Maryin)
>7. Re: 3750 stack (Matt Bennett)
>8. Re: Juniper M20 to Cisco 2600 Multilink Frame Relay &   FRF.16
>   issues (Keegan Holley)
> 
___
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] VWIC2-1MFT-G703

[Andrew Gabriel]

Hi,

We are deploying a bunch of E1s across Asia and EMEA, and were told by
our provider that for the sites that are G.703 they would recommend
the VWIC2-1MFT-G703 card rather than the regular channelized E1 cards.

Most of the E1 links G.703 connectivity I have seen typically work
fine with the VWIC2-2MFT-T1/E1 type card.

So would the VWIC2-2MFT-T1/E1 work for any E1 link, or do we really
need to buy the VWIC2-1MFT-G703 card that is more expensive and
difficult to source?

Thanks,
-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] Juniper M20 to Cisco 2600 Multilink Frame Relay & FRF.16 issues

[Keegan Holley]

Well the cisco is getting LMI from the juniper.  Do you see the lmi counters
incrementing on the Juniper side?


On Mon, Aug 23, 2010 at 2:09 PM, Jim Lucas  wrote:

>
> > Does it work with normal frame relay encapsulation.
>
> Yes
>
> > What are your DLCI statuses on the cisco?
>
> Currently, they are in-active
>
> > Also doesn't the IETF on the end of the frame relay dlci command change
> the lmi
> > type for that DLCI?  Is this intended?
>
> Didn't catch that one.  I removed the IETF from that line.  Didn't seem to
> make
> a difference.
>
> Router#show interfaces summary
>  Interface  IHQ   IQD  OHQ   OQD  RXBS RXPS  TXBS TXPS TRTL
> 
>  Ethernet0/0  0 00 0 00 000
>  Serial0/00 00 0 00 000
>  Ethernet0/1  0 00 0 00 000
>  Serial0/10 00 0 00 000
>  Serial1/00 00 0 00 000
>  Serial1/10 00 0 00 000
>  MFR0 0110 0 00 000
>  MFR0.16  - -- - -- --   -
>  Virtual-Access1  0 00 0 00 000
>
> Thank you for your time spent on this issue!
>
> Jim
>
> >
> > On Mon, Aug 23, 2010 at 1:22 PM, Jim Lucas  wrote:
> >
> >> Keegan,
> >>
> >> > I haven't looked at MLFR in a long time, but it looks like both sides
> are
> >> > trying to be DCE.  That may be a problem.
> >>
> >> Sorry, that was leftover from a previous config test.  I have it running
> >> without
> >> the  "frame-relay intf-type dce" on the Cisco.  The Juniper side is DCE
> and
> >> the
> >> Cisco is not specified.  My assumption has been that the default for
> Cisco
> >> is
> >> DTE.
> >>
> >> > Are they setup back to back or is there an actual frame network in the
> >> middle?
> >>
> >> A network.  They are in different buildings with a MUX or two between
> them.
> >>
> >> If I setup the connection with normal MLPPP it works and standard T1
> setups
> >> work
> >> just fine.  It shows a hardware level connection, but the protocol is
> down.
> >> This makes me think it has something to do with my config and probably
> not
> >> anything involving the equipment between the devices.
> >>
> >> Thanks!
> >>
> >> Jim
> >>
> >> >
> >> >
> >> >
> >> > On Mon, Aug 23, 2010 at 12:06 PM, Jim Lucas  wrote:
> >> >
> >> >> Note: I initially sent this to the Juniper-NSP list.  I was told by
> >> Nilesh
> >> >> Khambal (Juniper Engineer) that I have setup the Juniper side
> correctly.
> >> >>  So,
> >> >> I'm hoping someone here might have a little more information on the
> >> Cisco
> >> >> side
> >> >> of it all.
> >> >>
> >> >> TIA!
> >> >>
> >> >> First off, sorry for such a long email.  But I figured I would give
> as
> >> much
> >> >> information as possible upfront to try and give a clear picture about
> >> what
> >> >> I
> >> >> have and what I am currently running.
> >> >>
> >> >> Central Office Equipment:
> >> >> Juniper M20 running v7.5R1.12
> >> >>1x Link Services module (ls-3/0/0)
> >> >>
> >> >> Customer Equipment:
> >> >> Cisco 2611 running c2600-ipbase-mz.124-23
> >> >>2x Eth  (e0/0, e0/1)
> >> >>4x T1 wic (s0/0, s0/1, s1/0, s1/1)
> >> >>
> >> >> The following is the important parts of the config of the Cisco
> router
> >> >>
> >> >> interface MFR0
> >> >>  description my interface
> >> >>  no ip address
> >> >>  frame-relay lmi-type ansi
> >> >>  frame-relay intf-type dce
> >> >>
> >> >> interface MFR0.16 point-to-point
> >> >>  ip address 66.39.177.130 255.255.255.252
> >> >>  no cdp enable
> >> >>  frame-relay interface-dlci 16 IETF
> >> >>
> >> >> interface Ethernet0/0
> >> >>  ip address 66.39.177.133 255.255.255.252
> >> >>  half-duplex
> >> >>
> >> >> interface Serial0/0
> >> >>  no ip address
> >> >>  encapsulation frame-relay MFR0
> >> >>  no arp frame-relay
> >> >>
> >> >> interface Serial0/1
> >> >>  no ip address
> >> >>  encapsulation frame-relay MFR0
> >> >>  no arp frame-relay
> >> >>
> >> >>
> >> >> Here is my Juniper config:
> >> >>
> >> >> > show configuration chassis fpc 3 pic 0
> >> >> mlfr-uni-nni-bundles 32;
> >> >>
> >> >> > show configuration interfaces t1-1/1/0:0
> >> >> description "Bendtel Test leg #1";
> >> >> encapsulation multilink-frame-relay-uni-nni;
> >> >> lmi {
> >> >>lmi-type ansi;
> >> >> }
> >> >> unit 0 {
> >> >>family mlfr-uni-nni {
> >> >>bundle ls-3/0/0:0;
> >> >>}
> >> >> }
> >> >>
> >> >> > show configuration interfaces t1-1/0/0:19
> >> >> description "Bendtel Test leg #2";
> >> >> encapsulation multilink-frame-relay-uni-nni;
> >> >> lmi {
> >> >>lmi-type ansi;
> >> >> }
> >> >> unit 0 {
> >> >>family mlfr-uni-nni {
> >> >>bundle ls-3/0/0:0;
> >> >>}
> >> >> }
> >> >>
> >> >>

Re: [c-nsp] 3750 stack

[Matt Bennett]

Hi James,

You could power off and un-provision the old switch letting you keep the
rest of the config (but losing the port configs from the removed switch),
otherwise your new switch will join the stack as module 3. Cisco example
here:
http://www.cisco.com/en/US/products/hw/switches/ps5023/products_configuration_example09186a00807811ad.shtml#stack6

It doesn't really matter which is master if they have same IOS, so you could
leave the existing 24port one powered up and add the new one to the stack.

Regards,
Matt


On Tue, Aug 24, 2010 at 11:01 AM, James Greig  wrote:

> Hi People,
>
> I've two live stacked 24 port 100meg 3750's in master/slave.  What i'm
> aiming to do is replace the 24 port master with a 48port gigabit 3750 (same
> image rev) switch with the gigabit provisioned as the new master.  At a
> guess the config is going to need redoing as the ports are no longer named
> fa*/*/* and will become gi*/*/*.  Are there any other issues i'm going to
> encounter?
>
> Kind Regards
>
> James Greig
> ___
> 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] Cogent IOS upgrade == BGP-3, "update malformed"

[Tima Maryin]

Cogent probably hit CSCsy27511

I saw such thing when router affected by that bug sent malformed update 
to router that do not support 4 byte ASn.



On 23.08.2010 2:49, randal k wrote:

Cogent did an IOS upgrade to our local router, and immediately after our
peering with them started flapping wildly - gets about 10 seconds and
~69,000 prefixes in and resets with the following:

729078: Aug 22 16:21:39 MDT: %BGP-3-NOTIFICATION: sent to neighbor A.B.C.D
3/1 (update malformed) 21 bytes 31FE420C 31FE58C8 124683E8 0206CC67 00
729079: Aug 22 16:21:39 MDT: BGP: A.B.C.D Bad attributes    
    0060 0200  4140 0101 0040 020C 0205 00AE 0CB9 235A
2046 5BA0 4003 0426 6532 7580 0404  5DE8 C008 0800 AE52 0800 AE55 FD31
FE42 0C31 FE58 C812 4683 E802 06CC 6700  0002 1854 1608 1854 1609

I of course thought max as-path issues, but we already fixed that network
wide and confirmed that it is already set to 100. Our transit_input
route-map strips off everything; any idea what they could be sending us that
would cause our router to kill the session? Anybody seen anything similar?
We are thinking may something random with 4-byte ASNs or something community
related; as such we've asked for a similar stripper on their output, and if
that doesn't work, a code downgrade.

They're on a 7609 running God-knows-what, we were on 12.4(13c) and upgraded
to 12.4(24)T3, same issue.

___
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] Storm-Control on server switch uplinks.

[Saku Ytti]

On (2010-08-24 11:57 +0200), Peter Rathlev wrote:

> Hm... I thought "storm-control unicast" was exactly for _unknown_
> unicast. Otherwise it seems a little retarded (excuse my french).
> Blocking/policing unicast as such isn't really helpful, is it?
> 
> If it really is just unicast (and not unknown unicast) I understand now
> why the 3560G blocked traffic.

First CSCO box to support policing unknown unicast is EARL7.5 but it is 
per chassis instead of per port. I'm not sure if any Cisco can support
per port unknown unicast policing, but if Nexus7k/EARL8 doesn't do it,
I'm betting there isn't any box which does it.
It is one of the two big WTFs I have with Cisco switches, the 2nd is
inability to limit port MAC count without also employing port-security,
which murders convergency budget.

-- 
  ++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/

[c-nsp] 3750 stack

[James Greig]

Hi People,

I've two live stacked 24 port 100meg 3750's in master/slave.  What i'm 
aiming to do is replace the 24 port master with a 48port gigabit 3750 
(same image rev) switch with the gigabit provisioned as the new master.  
At a guess the config is going to need redoing as the ports are no 
longer named fa*/*/* and will become gi*/*/*.  Are there any other 
issues i'm going to encounter?


Kind Regards

James Greig
___
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] Storm-Control on server switch uplinks.

[Peter Rathlev]

On Tue, 2010-08-24 at 11:27 +0300, Saku Ytti wrote:
> But of course you can use 50% too if you have 50% excess capacity to
> handle the storm and you know your devices can handle it. In typical
> network 1kpps of broadcast is very high number for even 10GE L2,
> unless there is some special application.

We chose the 50% based on the fact that we didn't exactly know how much
broadcast/multicast was "normal"; we have since been measuring (via
SNMP/Cacti) this level and will probably adjust downwards.

You're right about the spare capacity needing to be there. We naively
concluded that a loop induced storm would tend to settle down as long as
there's some kind of limit imposed.

I guess it's time to adjust things now. :-)

> I think that the unicast storm-control is quite useless, unknown
> unicast storm control would be much more useful.

Hm... I thought "storm-control unicast" was exactly for _unknown_
unicast. Otherwise it seems a little retarded (excuse my french).
Blocking/policing unicast as such isn't really helpful, is it?

If it really is just unicast (and not unknown unicast) I understand now
why the 3560G blocked traffic.

It would like the 6500 to support "storm-control action shutdown" by the
way. It can be EEM scripted of course, but that's a kludge.

> If storm happens behind many edge ports, you could get aggregated rate
> multiple times higher than individual access port limit. So you might
> want to limit edge port to 1 unit and core to say 5 units.

Agreed.


___
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] Storm-Control on server switch uplinks.

[Phil Mayers]

On 24/08/10 09:27, Saku Ytti wrote:

On (2010-08-24 09:50 +0200), Peter Rathlev wrote:


We use broadcast og multicast storm-control on downlinks towards access
switches, generally at 50% just to make sure a broadcast storm doesn't
spread too much.


I would run<1% broadcast storm control, preferably entered in pps and
rather low number. On 10GE 7600 receiving<0.34% bps broadcast (L3 or L2
port, doesn't matter) it can still drop IGP on unrelated interface and
cause serious downtime.


Doubtless you know this because you specified 0.34, but for other 
readers, a cautionary tale: We recently deployed an edge 10gig port on a 
6716, and I set the broadcast storm level to 0.10 as per our standard 
config:


 storm-control broadcast level 0.10

Unfortunately on this linecard, anything <0.34 == 0, i.e. all broadcasts 
trigger it. This makes things like ARP rather unhappy! So beware the 
varying linecard limits.


It's a real shame the broadcast limiter (along with all the other limits 
on this platform) aren't more granular e.g. per-vlan broadcast and glean 
limits on a trunk port, etc.

___
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] Storm-Control on server switch uplinks.

[Saku Ytti]

On (2010-08-24 09:50 +0200), Peter Rathlev wrote:
 
> We use broadcast og multicast storm-control on downlinks towards access
> switches, generally at 50% just to make sure a broadcast storm doesn't
> spread too much.

I would run <1% broadcast storm control, preferably entered in pps and
rather low number. On 10GE 7600 receiving <0.34% bps broadcast (L3 or L2
port, doesn't matter) it can still drop IGP on unrelated interface and
cause serious downtime. 
But of course you can use 50% too if you have 50% excess capacity to handle
the storm and you know your devices can handle it. In typical network 1kpps
of broadcast is very high number for even 10GE L2, unless there is some
special application.

> I'm not sure I understand unicast suppresion; it sometimes triggers even
> when I would think it shouldn't. I haven't been able to grab the data

In some switches (e.g. 3550) if multicast triggers, all traffic is
suppressed, not just multicast.
Otherwise, I've not seen unicast blocked unless unicast is exceeded. I
think that the unicast storm-control is quite useless, unknown unicast
storm control would be much more useful.
I've used unicast storm-control in office LAN, to stop infected PC's from
congesting firewall. But I wouldn't run it on my customers as standard, as
our products do not dictate pps limit.

> I'm not sure why one would use it on uplinks, i.e. on the access switch
> side of things. AFAIK storm-control is an ingress thing.

If storm happens behind many edge ports, you could get aggregated rate
multiple times higher than individual access port limit. So you might want
to limit edge port to 1 unit and core to say 5 units.

-- 
  ++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/

Re: [c-nsp] problems with NAT

[Lee Starnes]

Hi Jon,

Thanks for the input. It would seem that this fixed almost everything.

We have 10.2.2.x at the office which is connected to the router in the colo
(the new 7206) which works now with this config change, but the IP range
172.20.1.x which is used between the 7206 and the router at the office does
not seem to get nat'd. Since the office router terminates SIP traffic from
the outside... 10.10.100.x is in the colo and this seems to still work. I
broke down the access-list 10 be separate entries for the three netblocks to
get the office to work.

access-list 10 permit 10.0.0.0 0.255.255.255
access-list 10 permit 172.20.1.0 0.0.0.255

changed to:

access-list 10 permit 10.10.100.0 0.0.0.255
access-list 10 permit 10.2.2.0 0.0.0.255
access-list 10 permit 172.20.1.0 0.0.0.3


I'm wondering if this is an issue where NAT is not wanting to match more
than one subnet/netblock per interface source. Seems kind of odd, but this
does seem to be what is happening.

Thanks for your help.

-Lee

2010/8/23 Bøvre Jon Harald 

> Try changing nat source list to a route map:
> ip nat inside source list 10 pool pool1 overload
>
> access-list 10 permit 10.0.0.0 0.255.255.255
> access-list 10 permit 172.20.1.0 0.0.0.255
>
> to
> access-list 10 permit 10.0.0.0 0.255.255.255
> access-list 10 permit 172.20.1.0 0.0.0.255
>
> route-map NAT permit 10
> match ip address 10
>
> ip nat inside route-map NAT pool pool1 overload
>
>
>
> Jon
>
> -Opprinnelig melding-
> Fra: cisco-nsp-boun...@puck.nether.net [mailto:
> cisco-nsp-boun...@puck.nether.net] På vegne av Lee Starnes
> Sendt: 22. august 2010 21:03
> Til: cisco-nsp@puck.nether.net
> Emne: [c-nsp] problems with NAT
>
> Hi,
>
> We are seeing a problem with NAT on a Cisco 7206VXR that has us completely
> stumped. The setup is working using a 1721, but when replacing that with
> the
> 7206 it does not seem to work.
>
> Current setup:
>
> Internet connection comes into a 2950 switch switch. They is handed to
> several devices on vlan 10 including the 1721 as a trunked vlan on its
> fa0.1. The 1721 also have fa0.2 on vlan 20 which is the private network.
> There are 2 T1s connected to this router on s0 and s1 in a multilink bundle
> (multilink1). Interfaces multilink1 and fa0.2 are configured as ip nat
> inside. fa0.1 is configured as ip nat outside. Static nat mappings to
> devices on the private ethernet and to the T1 network work great.
>
> Now, we replaced that 1721 with a 7206VXR and the NAT does not work
> correctly and the behavior is different depending upon what IOS version we
> load. The difference is network configuration now is that instead of using
> a
> trunk of vlans, there are individual fast ethernet ports. So fa0.1 and
> fa0.2
> get replaced with fa0/0 and fa0/1.
>
> Here is the issue. On c7200-is-mz.123-25.bin, NAT only works on devices on
> the private ethernet. On c7200-is-mz.122-3.bin, NAT works on everything
> except for SIP traffic (udp 5060) from the multilink1. On
> c7200-advipservicesk9-mz.124-
> 2.T5.bin, NAT does not seem to work on any traffic on the multilink and
> only
> partially works on private ethernet traffic. Seems to not want to NAT some
> traffic and leaves it as sourced from the private IP.
>
> I have included the interface and NAT portions of the config below. There
> are more NAT mappings than shown, but just included the first two. Does
> anyone know why this would work on the 1721 and not the 7206?
>
> interface Multilink1
>  description T1s to office
>  ip address 172.20.1.1 255.255.255.252
>  ip nat inside
>  load-interval 30
>  ppp multilink
>  ppp multilink fragment disable
>  ppp multilink links maximum 2
>  ppp multilink links minimum 1
>  ppp multilink group 1
>  service-policy output adtran-VoIP-policy
> !
> interface FastEthernet0/0
>  description Public internet at colo
>  ip address y.y.y.17 255.255.255.240
>  ip nat outside
> !
> interface FastEthernet0/1
>  description Private network at colo
>  ip address 10.10.100.254 255.255.255.0
>  ip nat inside
> !
>
>
> ip nat translation max-entries 1
> ip nat pool pool1 y.y.y.18 y.y.y.18 netmask 255.255.255.240
> ip nat inside source list 10 pool pool1 overload
>
>
> ip nat inside source static 172.20.1.2 y.y.y.19
> ip nat inside source static 10.10.100.21 y.y.y.21
> ip nat inside source static tcp 10.2.2.3 443 y.y.y.51 443 extendable
> ip nat inside source static tcp 10.2.2.3 80 y.y.y.51 80 extendable
> !
> access-list 10 permit 10.0.0.0 0.255.255.255
> access-list 10 permit 172.20.1.0 0.0.0.255
>
>
> Thanks,
>
> -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/
>
___
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] Storm-Control on server switch uplinks.

[Peter Rathlev]

On Mon, 2010-08-23 at 13:07 -0400, Christina Klam wrote:
> A couple weeks ago, I added storm-control for all of the (two 1-gig
> fiber)uplinks to our Cat6500 gateway switch.  Because of the large
> amounts of drops from the data center switch uplinks, I removed unicast
> storm-control.  What are your thoughts on using storm-control, in
> general, on switch uplinks?

We use broadcast og multicast storm-control on downlinks towards access
switches, generally at 50% just to make sure a broadcast storm doesn't
spread too much.

I'm not sure I understand unicast suppresion; it sometimes triggers even
when I would think it shouldn't. I haven't been able to grab the data
(via SPAN) so I can't say exactly why it happens. The scenario was
without any L2 redundancy, which could otherwise explain unknown
unicast.

I'm not sure why one would use it on uplinks, i.e. on the access switch
side of things. AFAIK storm-control is an ingress thing.

-- 
Peter


___
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] Cogent IOS upgrade == BGP-3, "update malformed"

[Heath Jones]

Agreed. I haven't gone to the effort of double checking Brett's work - but
the approach is definately the right one. It's very common for a developer
to screw up a pointer or boolean operation, just sometimes these bugs
actually make it past testing. I wouldn't be surprised.. Also, what's the
point of having a log entry if it doesnt get read? :)



On 24 August 2010 03:52, Pete Lumbis  wrote:

> I'm with Brett here. The update is malformed and you are just the victim.
> I'd try to gather a packet capture as well and you should be able to go to
> your provider armed with the bogus BGP update in both pcap and log form and
> tell them it's their fault.
>
> -Pete
>
> On Mon, Aug 23, 2010 at 10:06 AM, Brett Frankenberger <
> rbf+cisco-...@panix.com  <
> rbf%2bcisco-...@panix.com >> wrote:
>
> > On Mon, Aug 23, 2010 at 01:34:50PM +0100, Zoe O'Connell wrote:
> > > On 23/08/10 13:07, Florian Weimer wrote:
> > > > * Zoe O'Connell:
> > > >
> > > >
> > > >>> 729078: Aug 22 16:21:39 MDT: %BGP-3-NOTIFICATION: sent to neighbor
> > A.B.C.D
> > > >>> 3/1 (update malformed) 21 bytes 31FE420C 31FE58C8 124683E8 0206CC67
> > 00
> > > >>> 729079: Aug 22 16:21:39 MDT: BGP: A.B.C.D Bad attributes  
> >  
> > > >>>     0060 0200  4140 0101 0040 020C 0205 00AE
> 0CB9
> > 235A
> > > >>> 2046 5BA0 4003 0426 6532 7580 0404  5DE8 C008 0800 AE52 0800
> AE55
> > FD31
> > > >>> FE42 0C31 FE58 C812 4683 E802 06CC 6700  0002 1854 1608 1854
> 1609
> > > >>>
> > > > 5BA0 suggests its related to 32 bit ASNs.  We've got the prefixes in
> > > > our table, apparently with a proper 32-bit ASN:
> > >
> > > Yes, that's the conclusion we came to as well when we had it. (Luckily,
> > > it was an iBGP link to a firewall so easier to troubleshoot than a
> > > customer link). As far as I can recall, without Capability Negotiation
> > > it can't send 4-byte ASNs and some devices have a bug or differing RFC
> > > interpretation that means they can't handle being on the receiving end
> > > properly - if Cogent won't change their end, an IOS upgrade on the
> > > original psoters end should resolve it. I'm sure I sent a mail to
> > > someone about it at the time with more precise detail, but I can't seem
> > > to find it now.
> >
> > There's no IOS upgrade that's going to make the router happy with the
> > message shown above.  After the community attribute, it contains an
> > attribute startin with: 31FE420C.  Among other things, that's
> > specifying a length of 0x420C, which is much longer than the entire
> > message.  And it has the "partial" bit set on an optional,
> > non-transitive attribute, which isn't allowed.  And it's Attribute Code
> > 254, which doesn't exist (shouldn't cause a NOTIFY, though ... the
> > NOTIFY is likely being triggered by the length field.)  And the 0x01 bit
> > it set in the flags byte, which is also wrong (but also shouldn't cause
> > a NOTIFY).  It's pretty obviously a seriously malformed attribute.
> >
> > Assuming the router is correctly logging the message it received, the
> > problem is on the sending end.
> >
> > (It's disappointing how people troubleshoot these days.  Shot in the
> > dark IOS upgrades and parameter changes, when the entire objectionable
> > message is logged and can be decoded with a copy of the BGP RFC and 10
> > minutes.)
> >
> > -- Brett
> > ___
> > 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/