Re: [c-nsp] IOS-XE?

[Reuben Farrelly via cisco-nsp]

--- Begin Message ---



On 10/11/2020 10:33 am, Scott Voll wrote:

16.9.6 or 16.12.4?
and Why?

Any issues seen in the 16.12 line?  I've seen some unexplained reboots in
the 16.9.5 train that TAC can't explain so need to upgrade.  16.9.6 is the
Starred release.  I've not been impressed with the whole 16.9.x train over
the last two years so really thinking hard about 16.12.4.

Thanks

Scott


You haven't mentioned which platform specifically.

However 16.9 has been announced EoL and reaches End of Software 
Maintenance in January so a move to 16.12 is probably the logical next step.


https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9300-series-switches/eos-eol-notice-c51-742700.html

In other words, likely no more fixes in 16.9 now anyway.

Reuben

--- End Message ---
___
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] Devil's Advocate - Segment Routing, Why?

[Reuben Farrelly via cisco-nsp]

--- Begin Message ---

On 21/06/2020 7:30 am, Mark Tinka wrote:

Personally I would only recommend Meraki for a small business with
very basic and well defined requirements.  Even then once you factor
in the cost of licensing + hardware and compare it to a low end Cisco
Enterprise product that does not have said limitations, you may find
the cost is about the same over 3 or more years.


Sounds like pfSense might be a better option :-).

If I can summarize it in one sentence, is Meraki meant to be Cisco's
SD-WAN job?

Mark.


No.  Meraki is their "Small Enterprise" product line.  The SDWAN 
capability is there in Meraki MX - yes - but it is very basic.


The full SDWAN solution is what was Viptela, which is now being baked 
into mainstream IOS XE.  It's very good, but very complex, very capable, 
runs on existing IOS-XE devices, requires multiple VMs and a lot of 
infrastructure to use, and of course very expensive.


Unfortunately there's no middle ground Cisco SDWAN solution; you're 
either going big (Viptela) or small (Meraki) and with matching pocket 
depths.


Reuben

--- End Message ---
___
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] Devil's Advocate - Segment Routing, Why?

[Reuben Farrelly via cisco-nsp]

--- Begin Message ---



On 20/06/2020 4:14 pm, c...@marenda.net wrote:



I've been told Merak is very nice...  if all you're interested in is "sell

to

Enterprise customers and make lots of cash".


We asked the sales-person weather that meraki devices can handle ipv6
(as customer traffic) and for the cloudy management access (in an ipv4 free
world)
But they did not know this, told us they will ask, but we did not get any
answer yet ...


Meraki doesn't currently support IPv6 in any way, shape or form.

Some other things you'll find missing in Meraki products:

- Zone based firewalls - Meraki MX doesn't do zones
- Routing protocols for all but the most absolutely basic use cases
- Client side VPN.  More specifically it does PPTP but not so many 
people are sold on the security and NAT problems that come with PPTP

- Modern crypto - IPSec Auth is limited to MD5/SHA1 for example.
- Any sort of xDSL, they only have Ethernet models.  If you need xDSL 
you'll need a bridge modem for the carriage circuit
- Extremely limited NAT capabilities, no ALG, no ability to disable NAT 
between eg WAN and LAN ports which means it's almost useless for an MPLS 
circuit.  The lack of control over NAT also makes it impossible to run a 
publically addressable DMZ

- SSL decryption which makes content filtering a bit less useful
- Cellular is limited to not all 4G bands (notably does not support 
700MHz here in Australia) and Cell backup is not supported in an HA setup


And dare I say it, Segment Routing and MPLS definitely are not part of 
the featureset ;)


There are many good things about Meraki (eg dashboard, autovpn, updates, 
ease of provisioning), but in my recent experience with MX/MS products 
you have to spend as much if not more time working out what Meraki 
products *can not* do as what they *can* do - and know the product 
limitations before you design and deploy not during (don't assume anything).


Personally I would only recommend Meraki for a small business with very 
basic and well defined requirements.  Even then once you factor in the 
cost of licensing + hardware and compare it to a low end Cisco 
Enterprise product that does not have said limitations, you may find the 
cost is about the same over 3 or more years.


Reuben


--- End Message ---
___
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] ASR920 is a ticking timebomb (CSCvk35460)

[Reuben Farrelly via cisco-nsp]

--- Begin Message ---

On 24/01/2019 6:23 am, Giles Coochey wrote:
I think the tack the OP was meant to imply that Cisco Bughunt for issues 
leaves a lot to be desired, with terse messages attached to bugs, 
incomplete versions affected, etc...


The thing that sends me off the deep end with bugs like this is when 
they are marked with a status of "Terminated" especially if they have a 
high severity.


Perhaps it is just a case of a bad choice of words, but that reads to me 
the effect of "we have made a conscious decision to not fix this bug" 
and implies that it's most likely a waste of time opening a TAC case 
about it.


Reuben
--- End Message ---
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Multicast within VLAN on Nexus7K over vPC

[Reuben Farrelly via cisco-nsp]

--- Begin Message ---

Hi,

Have you read the Best Pratices guide:

http://www.cisco.com/c/dam/en/us/td/docs/switches/datacenter/sw/design/vpc_design/vpc_best_practices_design_guide.pdf

Specifically the section about vPC multicast?

Reuben


On 20/10/2016 9:27 PM, Yham wrote:

Hi All,

I have two cisco nexus 7K as core switches and two cisco 4500 as
distribution/access switches. Nexus switches have vPC with each downstream
4500 switch and there is no connection between 4500 switch. Vlan100 exist
on all four switches and all devices part of this vlan are connected to
4500 switches. I believe this is pretty standard design.
Though vlan 100 has regular users and services that communicate over
unicast but there are some devices that need to send and receive multicast.
Both Multicast sender and receivers are in same vlan but receivers are
spread across both 4500 switches.

In diagram (no link below), receivers connected to switch 4K-1 (where
source is connected) can receive the multicast stream but receivers
connected to 4K-2 don't see anything. I believe its expected behavior due
to IGMP snooping enabled on switches by default but i am trying to figure
out how to make receivers on other switch able to get multicast stream.

I did some research and found different ways but unfortunately i don't have
non-production devices to test which one actually works. Here what i found

1) configuring IGMP querier for vlan 100 on all four switches
2) only enable 'ip pim sparse-mode' under SVIs (interface vlan100) at
N7K-01 & N7K-02
3) disable IGMP snooping for vlan 100 on all four switches (which i don't
think a right solution)

Topology Diagram
https://s22.postimg.org/3tsnta4s1/topology.png


Your any help will be highly appreciated.

Thanks
YH
___
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/


--- End Message ---
___
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] ASR920 "console" port....ugh

[Reuben Farrelly via cisco-nsp]

--- Begin Message ---



On 16/01/2016 10:43 PM, Gert Doering wrote:

Hi,

On Sat, Jan 16, 2016 at 09:07:00AM +, CiscoNSP List wrote:

Cheers for the replies guys - I'm really interested in the rational
behind moving to USB from traditional RJ45
portsrealestate?boggles the mind.


Well, if done properly, it's actually easier to the admins than
having to carry around a usb-to-serial adapter all the time (since
almost all current machines do not have a built-in serial port
anymore).

"properly" implies something else, though, like:

- the "real" USB console has a mini-b or micro-B plug, so a
bog-standard USB cable otherwise used to charge your mobile will do
the job (as for driver installation, well, if you can find a
USB-to-serial chip that windows supports by default, even better -
but otherwise, unavoidable misery.  On Linux, it just works with the
common chipsets)


USB console is a good idea but the execution of this changeover was botched.

As of today we have most routers and switches rolling out with USB 
serial ports and what appears to be USB->Serial chips onboard to do the 
translation.  This required only a standard mini-b to USB cable to work.


Big tick there.  The hardware teams did a good job on their part of the 
job and the implementation of hardware is usually good.


But where Cisco seriously lost all credibility with this was the 
software/driver support.


As of today:

Windows 7 driver - available on CCO and works OK
Windows 8 driver - never supported
Windows 8.1 driver - never supported
Windows 10 driver - seems to be built into Windows 10

Note that the Windows 7 driver did not work on Windows 8.  And in 
practice on every laptop I tried it on the driver got in a messed up 
loop whereby it created 255 COM ports in Windows before deciding that 
there were none left.  This left a right royal mess in device manager to 
clean up.


At least a part of this bug was being tracked under CSCuh52585 which has 
never been made customer visible.


There was some comment on this in:

https://supportforums.cisco.com/discussion/11996231/usb-console-drivers-windows-8

In the end I just went and bought a decent dongle that did have good 
driver support and haven't had to deal with the problem since.


There are still some routers which don't have USB console ports such as 
the C819G's though.  So it's not quite yet ubiquitous.  But that's the 
exception not the norm.


Reuben
--- End Message ---
___
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] switch for SAN

[Reuben Farrelly via cisco-nsp]

--- Begin Message ---



On 9/01/2016 3:53 AM, Chuck Church wrote:

What are your needs?  10GE?  Layer 3 capable?  There are a lot of small
Cisco switches.  The main difference between the 3650 and 3850 is the
wireless controller thing to my knowledge.  Not really beneficial to a SAN
switch.  Since Cisco tends to not publish buffer sizes for a lot of these
small switches, it's a bit of a guess.  The 2960X are decent for a lot of
purposes, maybe SAN.  That's just a guess though.


http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3650-series-switches/qa_c67-729531.html

As of 3.7.1E the 3650 supports the same number of AP's (50) as the 3850.

If you only need a standalone switch or one with limited stacking 
capabilities and no need to change uplink modules, then the 3650 is much 
better value than a 3850.


Definitely more suited to the task than a 2960X.

Reuben
--- End Message ---
___
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] Multihoming

[Reuben Farrelly via cisco-nsp]

--- Begin Message ---



On 1/09/2015 6:43 AM, Justin M. Streiner wrote:

On Mon, 31 Aug 2015, Jason Berenson wrote:


Was interested in getting any pointers anyone might have about
multihoming. I've got an ASN and am working on a /24 from ARIN now.  I
was thinking about a pair of Cisco 3560's one for each provider and I
was going to take default routes from each, one with a higher metric
and announce my prefix over the primary link and pad the secondary
link.  No customer or full tables needed.

I was thinking about vlan'ing each switch into half public half
private side also.  Any pointers or tips or recommendations would be
greatly appreciated. It's been a while since doing this type of stuff.


You might need to get your IPv4 space from one of your upstream
providers. As far as ARIN is concerned, that well is dry.

You will also want to start giving serious thought to IPv6.

I don't know how well 3560s handle BGP, but if you're just taking
default routes from your upstreams, the resource needs are pretty
light.  As the other person who responded mentioned - 4-byte ASNs could
be an issue as well.


3560's handle 4 byte ASNs just fine provided:

- You have sufficient flash.  4 byte ASN support in the Catalyst 
platforms was introduced in 15.2(1)E so this is the absolute minimum 
version you will need to run - and this image (in fact anything newer 
than 12.2(55)SE) requires 32M flash.


- You have the IPSERVICES image/license as BGP is not supported in IPBASE.

As you're only handling a handful of prefixes if you meet the 
requirements above you should be fine.


Reuben
--- End Message ---
___
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] ME3600 migration to something with more 10 gig ports

[Reuben Farrelly via cisco-nsp]

--- Begin Message ---

On 14/07/2015 9:34 PM, Gert Doering wrote:

Hi,

On Tue, Jul 14, 2015 at 11:06:37AM +, Adam Vitkovsky wrote:

Or from a different angle why would they bother designing test
procedure that tests every possible permutation making sure the box
is error free if no one is using certain config combinations. The
live audience makes sure they only need to deal with the widely
used features and not waste money on fixing features that almost no
one actually uses.


While that is a bit cynical, it would actually work *IF* they gave
TAC enough developer resources to then fix anything that comes up in
reasonably short time *AND* add regression tests to their setup to
ensure that they are not breaking this (obviously important) feature
again with new code...

The "not enough support from dev" is one of my major gripes with TAC
- these folks are friendly and helpful, but if they are left dangling
without backend support, there's not much they can do.


Unfortunately I have to agree with this about insufficient dev resources 
as well - and the situation appears worse than I think it has ever been.


I have 6 TAC cases open at the moment - some have been open 6+ months,
practically all are awaiting a response from engineers who have 
contacted DE to either fix a bug or respond with where to go next given 
a collection of outputs that clearly illustrate problems and that the 
engineer needs to escalate.


Most have been waiting a double digit number of weeks (not days) for 
responses from DE.


Unfortunately this means that the engineer who assisted is probably 
going to be lumped with a very poor survey score for "Timely Resolution" 
even though it may not be his/her fault :-(


Reuben
--- End Message ---
___
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] ASR920 - ISR4431

[Reuben Farrelly via cisco-nsp]

--- Begin Message ---

On 3/06/2015 7:59 PM, Nick Cutting wrote:

Thank you for the suggestion - I've been using these in the lab quite
a bit lately as I've lost faith in GNS3 (watching it fall apart when
showing clients proof of concept - "this won't happen on the real
kit..") , however I am a little scared to run the internet vlan(s)
into the esx estate at this time, there is a rather old fashioned
security policy in place. Perhaps if we had dedicated hosts

I think we can pick up 2 of the new little 3560's-CX's for £~5k each
with ip services & netflow  - just hoping 11k prefixes is enough.


It probably won't be. Here's from a WS-C3560CX-12PD-S:

switch-2#show sdm prefer
The current template is "default" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.

number of unicast mac addresses: 16K
number of IPv4 IGMP groups + multicast routes: 1K
number of IPv4 unicast routes: 5K
number of directly-connected IPv4 hosts: 4K
number of indirect IPv4 routes: 1K
number of IPv6 multicast groups: 1K
number of IPv6 unicast routes: 5K
number of directly-connected IPv6 addresses: 4K
number of indirect IPv6 unicast routes: 1K
number of IPv4 policy based routing aces: 0.25K
number of IPv4/MAC qos aces: 0.375k
number of IPv4/MAC security aces: 0.375k
number of IPv6 policy based routing aces: 0.25K
number of IPv6 qos aces: 0.25K
number of IPv6 security aces: 0.375k

switch-2#

There's only one SDM template at this stage.

A 3650 switch (not a 3560) would be sufficient though - think this is as 
low as you could go while fitting that many prefixes in tcam.


Aside from this I'm quite disappointed with how the ISR 4300/G3 platform 
has been put together in so far as the licensing and throughput 
restrictions. It seems to me that it's a big step backwards from the ISR 
G2 platform, and the upgrade from G2 to G3 is a hard sell. I would be 
most interested to see how the sales figures are looking...and other 
peoples thoughts on this.


Reuben

--- End Message ---
___
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 Security Advisory: Cisco IOS Software RSVP Vulnerability

[Reuben Farrelly via cisco-nsp]

Another similar change I've noticed recently in so far as release notes 
and details of changes go is this - release notes for 15.1(4)M9:


http://www.cisco.com/c/en/us/td/docs/ios/15_1/release/notes/15_1m_and_t/151-4MCAVS.html#pgfId-62747

"All resolved bugs for this release are available in the Cisco Bug 
Search Tool through the fixed bug search."


For that release the release notes just point to the Bug Search Tool on 
CCO.   Which for me I find an abominable tool in all browsers - it's 
slow, really kills performance on all other open browser windows as well 
and the Load Saved Search function is just unusable - it tries to 
emulate real menus but fails badly (things need to be double clicked to 
work, it doesn't work well if you have folders and bugs saved in any 
sort of hierarchy for example).


I hope that the pointing to BST for details at the expense of listed 
summaries is not a strategy that is going to be deployed across the 
board for other release notes.  There's a lot to be said for being able 
to quickly skim through the open P1 and P2 caveats of a new release in a 
plain HTML page.



It's probably a good candidate function/feature that could be replaced 
by another classy Java/JRE app on the CCO website ;)



Reuben


On 25/09/2014 11:18 PM, Clay Seaman-Kossmeyer (ckossmey) wrote:


Hi Folks -

We definitely appreciate the feedback and will put some thought into
how we can satisfy this request.  Behind the scenes, we’ve moved to a
very different infrastructure for compiling vulnerability information
for each IOS release, which allows us to greatly improve our ability
to show granular, real-time exposure vs. a 6-month static snapshot.

The compromise that we always struggled with in the tables was the
lack of release-level granularity, especially given the depth of
branching in some (many) IOS trains.

We’ll put our heads together and kick around some ideas for how we
can provide some quick-reference, summary information, though it’s
unlikely we’ll be able to do anything in short order for this
bundle.

Thanks again for the feedback.

Clay

On Sep 25, 2014, at 7:50 AM, Gert Doering 
wrote:


Hi,

On Thu, Sep 25, 2014 at 11:35:01AM +0200, Peter Rathlev wrote:

IOS Software Checker is a nice tool, do keep it. But for the
"helicopter view" the comprehensive list is a really great help.


This! +1


___
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] Basic BGP Cisco Router

[Reuben Farrelly]

On 26/05/2014 4:39 PM, Andrew Miehs wrote:


On 26 May 2014, at 3:58 pm, Mark Tinka  wrote:

If you're looking for something really modest, with little to no
opportunity for growth, consider the CSR1000v.


Thats actually a pretty cool idea! I keep forgetting that the thing
exists. Although - however, once I start looking at software routers,
I really wonder whether it wouldn't be just as effective running a
competing product or even open source

Will need to ponder on that


Low end branch ISR G1/G2 routers are still for the most part software 
routers anyway.  So it's not really any different in that regard - but 
at least with the CSR you have the ability to vMotion it around within 
VMware if there's an underlying hardware failure.


The advantage in the CSR is the IOS command line, vendor support and 
ease of configuration access to complex features (try configuring and 
debugging MPLS on a Gentoo or Fedora Linux box, for example...).  If 
none of those things matter to you then by all means, an open source 
product may be a better fit.


Reuben
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Cisco ME3800X with EIGRP

[Reuben Farrelly]

On 10/03/2014 11:45 AM, Chris Russell wrote:


A cisco switch/rtr without eigrp.. first time I've encountered it!


Hi Steve,

  Debated this with Cisco a while back - apparently more aimed at PE
edge, so less routing capabilities more MPLS.

  Last time I asked the scaled metro license was only for scale - below
from an SE 6 months or so back so might have changed:


ME3800-X P/PE
· The Metro Aggregation Services license gives you the following
features, MPLS, EoMPLS, MPLS VPN, MPLS TE, FastReroute, VPLS in addition
to the features in the Metro IP Services license.

· You may also wish to consider the Scaled Metro Aggregation
Services license, the following table shows you the difference in scale:

Supported feature


...


ACL entries
4 K  (Metro)
16 K  (Scales)


Apparently the scaled license is also required in order to support 
Policy Based Routing.  It seems counter-intuitive given it's a "scale" 
not a "feature" license, but it's documented here:


http://www.cisco.com/c/en/us/td/docs/switches/metro/me3600x_3800x/software/release/15-4_1_S/configuration/guide/3800x3600xscg/swpbr.html

I ran into this 18 months ago.  I think it's inconsistent and a pretty 
nasty gotcha for the uninitiated.


Reuben


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3600 autoroute & 10G EFP issues

[Reuben Farrelly]

On 15/01/2014 4:33 PM, Mark Tinka wrote:

I can't recall for which platform, but I think there are
some restrictions with running MPLS and/or MPLS-TE on an
SVI.


Prior to 15.3(1)S it wasn't supported on the ME3600/ME3800, although it 
largely worked (from what I recall).  Official support for this was 
added in 15.3(1)S:


http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software/release/15.3_1_S/release/notes/ol28239.html#wp952856

--

VPLS over MPLS SVI uplink, EVC Xconnect with MPLS SVI uplink (Switchport 
or EVC), SVI L3VPN over SVI uplink - MPLS IP on SVI Support—This feature 
supports the qualification of SVI as an MPLS uplink. For details about 
using this feature, see:


http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software/release/15.3_1_S/configuration/guide/swmpls.html 



-

I'm guessing that's what you were thinking of.

Reuben

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] C6500 IPv6 redistribute with route-map?

[Reuben Farrelly]

On 10/12/2013 8:43 PM, Nick Hilliard wrote:

If you want to do it with BGP, I'd recommend setting up a couple of VMs to
act as route reflectors (with e.g. bird or quagga or something) and
creating a very simple BGP community policy: tag your transit prefixes,
your peering prefixes and your internal prefixes using different community
values.  Then you can use the route reflectors to control how the prefixes
are distributed around your network.  It's a small amount of work, but it's
an approach that scales well in practice.


...and it's a LOT, LOT easier to migrate to this sort of design while 
the network is small, than when it grows.  Start small, start simple, 
only set a couple of communities till you are comfortable with how it 
works, take some time and work out how you want to plan your community 
setting and matching, and like a work of art develop both the network 
and your BGP operational skills over time.


It may seem a bit counter-intuitive to start implementing this before 
you need it, but it's a lot easier to grow into this design than to grow 
out of a non iBGP core and have the change forced upon you.


Been there done that, and once there's lots of live paying customers 
with expectations around uptime, this stuff gets more and more tricky to 
retrofit and learn.


Reuben

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] Access to CCO - "sso.cisco.com" over IPv6

[Reuben Farrelly]

Hi

I've been having intermittent problems logging into CCO in the last few 
weeks - and the troubleshooting I've done so far seems to indicate the 
problem only occurs when I'm connecting to it over IPv6.  It seems the 
actual authentication to www.cisco.com is handled by a site with 
hostname sso.cisco.com.


There are both A and  records for it in DNS, and it resolves 
consistently across multiple locations.  It looks like this isn't one of 
the CDN delivered components of the site.


The end accepts the IPv6 connection and refuses to send data, eventually 
closing the connection and timing out.   The IPv4 connection works fine. 
 Tested with port 80.


Emails to TAC so far have solicited responses along the lines of 
restarting the PC/clearing browser caches/clearing cookies/changing 
browsers etc trying to push it back on me despite it happening on at 
least two different machines across a period of time including a newly 
installed VM and appearing broken even with a telnet client manual test.


Is anyone else who has IPv6 access and who is accessing cisco.com over 
IPv6 had issues to this site in the past 2-3 weeks?  I get the feeling 
that IPv6 access to parts of CCO systems isn't well monitored, 
blogs.cisco.com was completely broken over IPv6 some weeks back for a 
while, but it came good after I posted a comment on there stating it was 
broken (from IPv4 only work).


Maybe one of those dodgy Cisco load balancers is upset again and needs a 
restart ;)


Or is there someone on here from Cisco who knows who/how to poke to get 
this looked at?


Thanks,
Reuben
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Best Support of Tier 1 ISP

[Reuben Farrelly]

On 9/07/2013 10:32 PM, Gert Doering wrote:

Or, after an external DoS hit their Frankfurt node which we're connected
to, we received an unsolicited e-mail "we had a DoS here, leading to some
packet loss.  Problem has been fixed, our apologies".  We didn't even
notice up to that point...  experience with other carriers is more along
the lines of "we call them, tell them there's packet loss, and they won't
find anything and close the ticket".

So, yes.  Happy customer.


+1 here.  Happy ex-customer (only because I changed job) after a similar 
couple of DDOS incidents.  We also had both an international MPLS 
circuit as well as Internet transit based out of Sydney, Australia.


NTT have a pretty decent IPv6 backbone too, FWIW.

Reuben





___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] IOS XR 4.3.0 or 4.3.1

[Reuben Farrelly]

On 27/05/2013 10:37 AM, Jared Mauch wrote:

Basically all the images go through EFT with almost no exceptions.
Problem most vendors have is getting good feedback from the sites
with that early code. Seen that for over a decade with many vendors.

Jared Mauch


Valuing good feedback hasn't been my experience, although to be fair I'm 
dealing with IOS space rather than IOS-XR so it may be different.  It is 
typically taking me upwards of 2 months and sometimes nearer a year of 
TAC case time to have reproducible defects confirmed and bug reports filed.


I'm too small to have a Cisco AM or deal direct, so I don't have that 
avenue open to me either and it's unlikely the reseller who has sold me 
gear will want to spend time chasing Cisco for this sort of thing. 
However the fact that I'm a small player also means I'm able to test and 
offer feedback a lot easier than say, a big customer with a 24x7 
operation where there is no option for downtime or testing.


There must be a better way to submit feedback and log bug reports, but 
I'm baffled as to how/where.  TAC certainly don't seem to want to deal 
with them and I'm losing interest in spending lots of my time debugging 
Cisco's products to be left feeling like they've done /me/ a favour by 
opening a bug report and fixing it.


So, the question is, are there any better ways to submit engineering 
type feedback than simply opening TAC cases all the time?


Reuben

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] NAt issue - two isp connections, need to nat 2nd isp for two dest addresses only

[Reuben Farrelly]

Yes it certainly should work, however I found that it doesn't always 
work properly, specifically for SIP traffic (TCP and UDP traffic worked 
fine).  The SIP ALG is broken and you'll find traffic will exit one 
interface but the SIP ALG will sometimes rewrite the SIP header to have 
the other interfaces' outside IP.


It looked like an elegant solution to a simple problem; the config I had 
was something like this:


route-map internet-nat-access permit 10
 match interface FastEthernet0/1
!
route-map tunnel-nat-access permit 10
 match interface Tunnel0

ip nat inside source route-map internet-nat-access interface 
FastEthernet0/1 overload

ip nat inside source route-map tunnel-nat-access interface Tunnel0 overload

I was controlling which interface the traffic went out with static 
routes.  Disabling the SIP ALG didn't resolve the problem either.


I had a TAC case open for over 15 months in which I had a 100% 
reproducible test case across multiple platforms and multiple versions 
of IOS, and eventually after much "persistence" and 3 or so TAC 
engineers later, TAC agreed that yes, it was indeed a bug.


It was raised as CSCue13042 in January (SR 619832003).

Unfortunately, and to my extreme frustration, it changed status without 
warning to "Terminated (Unreproducible)" just last week.


So - YMMV.  The config suggested "mostly" works.  Which is more than I 
can say for TAC in this instance.


Reuben


On 19/04/2013 5:03 PM, CCIE Ninja wrote:

I guess this would work, if you match on outgoing interface?

route-map SP_A_NAT
match interface $MY_OUTGOING_INTERFACE

ip nat inside source 155.1.5.5 155.1.13.7 route-map SP_A_NAT


___
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] VSS to vPC - vPC to Etherchannel

[Reuben Farrelly]

Using that logic you could probably also argue recovery time would be 
even quicker again by disabling Spanning Tree entirely.


Funnily enough, not too many people seem to recommend completely 
disabling STP to achieve that goal though.


Reuben


On 17/03/2013 11:34 AM, Andrew Miehs wrote:

The cisco documentation recommends static as the recovery times are
supposedly faster due to no negotiation. Not really sure if the
downsides make up for that though.

___
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] Private IP in SP Core

[Reuben Farrelly]

On 11/03/2013 9:43 PM, Gert Doering wrote:

Hi,

On Mon, Mar 11, 2013 at 10:18:31AM +, Gordon Bryan wrote:

Can I ask what your thoughts are on core IP addressing? Do you have
specified global ranges for this purpose with matching  iACLs or do
you use another method altogether.


We use a dedicated IPv4 /24 for all core links which is heavily ACLed
at all external borders.


+1.


What we're currently not so good at is "protect the PE-CE link" -
the customer infrastructure is so heterogeneous that we can't do
"every PE-CE link gets a /30 from a well-known /22 (or whatever) and
that is also strongly filtered" (as ytti suggested).


We also started to move from /30s to /31s 12 months before I left. 
Saves 50% of public addresses and given we were supplying and managing 
almost all of the CPE routers, it was a non issue in so far as which 
ones would work (anything recent Cisco-wise did).


If a customer asked why a /31, I would suggest they try it and then if 
it doesn't work we'll go back to a /30.  But between Cisco and Juniper 
it all did just work...


Side issue I know, but a 50% saving makes it a bit less costly in terms 
of the operational cost of burning public IP addresses.


Reuben

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Private IP in SP Core

[Reuben Farrelly]

On 11/03/2013 8:52 PM, Gordon Bryan wrote:

Andrey/Andrew,

It will be a very small network to begin with - single P router,
single PE router and a number of switches for hosting. This will
hopefuly quickly scale to a dual-site configuration with two P
routers and two PE routers but even then it will still be small in
the grand scheme of things.

In terms of Internet services, I was planning on delivering these in
an Internet VRF and there is no requirement for a full routing table
yet


"Yet" perhaps being the operative word here - it's much harder to undo 
these sorts of things later on - so yes, perhaps a good time to be 
asking the question.  Faced with moving from a VRF to the global table 
in the future is, well, I shudder at the thought.


For that smaller number of routers and core, it's probably also a 
relative non-issue as to if you use public IPs or not - just do it, it's 
not like you're going to need lots and lots of public IP addresses to do 
this sort of thing anyway.  It guarantees you'll have unique IPs to iBGP 
or eBGP to, with traceroutes that probably work especially if the 
business sells or acquires or needs to join with another AS, for example 
(or even if one of your downstream suppliers uses BGP for a L3 service).


I would also recommend you keep Internet in the global VRF - that's what 
"most" people seem to do and what "most" people seem to do is often also 
the "most" tested code path and "most" likely you'll not run into issues 
that "most" other people haven't done before.


I've worked with both - and in $JOB-1 I built everything with fully 
public IPs.  For a PE with perhaps 200 tails terminated on it, it only 
cost us 3 public IPs for the MPLS and IP network, so it really wasn't 
much overall.


You'll use 60x or more IP addresses of you use public IPs on customer 
facing PE-CE WAN interfaces.  Not that I'm advocating either way on 
that, but keeping this all in perspective here - using a tiny number of 
public IPs for your MPLS and core IP routing is an easy win with 
relatively little price to pay.


It would have been fantastic if we could run MPLS over IPv6 transport 
instead as this would have been a totally moot point then, but I don't 
think that's an option yet :-(


Reuben
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 2960 -> 4948 - no more drops :)

[Reuben Farrelly]

On 19/02/2013 9:21 PM, Peter Rathlev wrote:

This is a classic example of when a Gig port in name is not a Gig port
in throughput, ie it may link up at that speed but you'd be lucky to get
the rated throughput in all but ideal circumstances.


Funny thing is that many lower end switches (i.e. cheaper) have better
buffer characteristics than a 2960 or similar. And even though the 2960
is cheap compared to other high end switches it isn't compared to
gigabit switches in general.


Notwithstanding that this is a Cisco list, is this limited buffer 
problem something common to many other vendor's lower end switches too? 
 Do switches from vendor J, Mikrotik and HP also have a similar problem?


It's obviously used as a differentiator of high and low end switches for 
Cisco, but I've often wondered if it's used as a deliberate "cripple" to 
the kit, surely it can't be THAT hard and expensive to engineer 
increased shared buffer space in a low end chassis from 12M to, say 60M?


(As an example, I'm especially looking at differences like those between 
the ME3600 and ME3800, the ME3600X has 44M of buffer and the ME3800 has 
352M, and it's double the list price but otherwise is almost identical; 
at $job-1 I had to explain why I wanted an ME3800 vs an ME3600 for a POP 
when the buffer size was the only difference).


Reuben

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 2960 -> 4948 - no more drops :)

[Reuben Farrelly]

This documents may help answer your questions about buffer sizes and how 
they are shared amongst ports on the two switches:


http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/tpqoscampus.html

Look down at the QoS and queueing information (ignore the bits about 
TelePresence)


Reuben


On 17/02/2013 11:14 AM, CiscoNSP_list CiscoNSP_list wrote:



Hi Rob (Sorry for not replying inline, but hotmail screws the
formatting)

We did try tuning qos buffers (It did improve the drops, but they
were still significant), and we also tried disabling mls qos (Still
saw significant drops)Im really interested to know why there is
such a difference between the two platformsi.e. is it buffers/how
they are allocated, architectural differences or combination of
both?

Cheers.


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 2960 -> 4948 - no more drops :)

[Reuben Farrelly]

The 2960 is a floor/access switch - and at the low end of the range.  It 
isn't positioned or designed to be used in the type of bursty traffic 
environment that the OP was using it for.


This is a classic example of when a Gig port in name is not a Gig port 
in throughput, ie it may link up at that speed but you'd be lucky to get 
the rated throughput in all but ideal circumstances.  Unfortunately the 
concepts around buffers, drops and architecture, and what makes a 2960 
different from a 4948 or ME series switch (because they all have 'Gig' 
ports - but a big price difference) are still concepts foreign to many 
engineers - more so in enterprise land than service provider land, IMHO.


I doubt it's an attempt at guerrilla marketing.  It's no real surprise 
that once upgrading to a switch that was designed for the purpose that 
performance and output drops improved significantly.


Reuben

On 17/02/2013 11:25 AM, Alex Pressé wrote:

Not sure if guerrilla marketer trying to get readers to google this
fantastic switch...


On Sat, Feb 16, 2013 at 5:14 PM, CiscoNSP_list CiscoNSP_list <
cisconsp_l...@hotmail.com> wrote:




Hi Rob (Sorry for not replying inline, but hotmail screws the formatting)

We did try tuning qos buffers (It did improve the drops, but they were
still significant), and we also tried disabling mls qos (Still saw
significant drops)Im really interested to know why there is such a
difference between the two platformsi.e. is it buffers/how they are
allocated, architectural differences or combination of both?

Cheers.




Date: Sun, 17 Feb 2013 00:27:31 +0100
Subject: Re: [c-nsp] 2960 -> 4948 - no more drops :)
From: robh...@gmail.com
To: cisconsp_l...@hotmail.com
CC: cisco-nsp@puck.nether.net


We recently upgraded a 2960G(Only doing L2) that was hitting

~500Mb/sec on one port, and we were seeing 40,000+ output drops (5Min) -
Since the swap to the 4948, we see zero output drops. Is the difference in
performance purely buffer size?  I *think* the 2960 has 1.9Mb (Per ASIC)
and the 4948 has 16Mb (total?)?


___
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] stp on me3600 on efp's with locally connected older switch

[Reuben Farrelly]

On 25/01/2013 7:25 AM, Aaron wrote:

Why does " l2protocol peer stp" show up as an option if it's not supported?  Is 
that one of those things with ios that commands are there but don't work type of thing?   
...anyway, is MST (802.1s) supported on efp's?

Aaron

sv-b-ME3600-test#
sv-b-ME3600-test#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
sv-b-ME3600-test(config)#int g0/22
sv-b-ME3600-test(config-if)#service instance 675 ethernet
sv-b-ME3600-test(config-if-srv)#l2protocol peer ?
   cdp   Cisco Discovery Protocol
   dtp   Dynamic Trunking Protocol
   lacp  LACP Protocol
   lldp  Link Layer Discovery Protocol
   pagp  Port Aggregation Protocol
   stp   Spanning Tree Protocol
   udld  UDLD Protocol
   vtp   Vlan Trunking Protocol
   


If the 4500 is one of your core devices then just configure the port as 
a normal switchport trunk.
IMHO EFP's are more suited and designed to be used on customer facing 
ports (PE->CE) rather than core facing uplinks (P-PE).


Aside from that, the restriction about only being able to peer with MSTP 
across EFP's is a pretty horrendous one, I was really surprised to find 
that even Cisco's Rapid PVST isn't supported and it's not on the roadmap :-(


Reuben

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 7204VXR reboots

[Reuben Farrelly]

On 24/01/2013 1:29 AM, Joe Maimon wrote:

One thing thats really biting me atm is that per-user aaa/qos support,
available in 124 mainline seems to have moved only to S train for 15x,
leaving me (again) with the interesting dilemma of which features on
which routers I want to continue using or upgrading.


This stuff /changed/ in late 12.4T and in turn 15M, but it's there in 
the non S builds too, just not with the old commands.


See CSCte95297 .

I've had advipservices-k9 15.0(1)M and 15.1(4)M running and doing just 
this for a while.  The commands have changed, the applied config is now 
invisible, but the functionality is there.  (It was broken in early 
15.0M builds though prior to 15.0(1)M3).


You'll need to look at:

rt1.nsw#show subscriber session uid 988 detailed

and

rt1.nsw#show policy-map int virtual-access 12

to see what is applied.

Going back some 3 years now since I ran into this; show int and show int 
configuration no longer showed the policy statements applied to the 
config, but it is actually applied - just not visible in the config. 
'show policy-map session' also returns nothing.  I tried to get Cisco to 
restore the commands, as it used to show useful output there, but they 
said we had to speak with account management as it was a "feature 
request" and not a "bug".  It's only cosmetic but annoying nonetheless..


Reuben




___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 7204VXR reboots

[Reuben Farrelly]

On 22/01/2013 9:59 PM, Gert Doering wrote:

Nobody knows what's inside any given IOS build.  As a rule of thumb,
whenever you want to turn on something new, the specific combination of
hardware + software + feature pack that you have will not support it.

(Yes, this does annoy me to no end)


Killer missing feature for me was that the S train (ie 
15.0S/15.1S/15.2S) does NOT have Netflow code in CEF on the 7200, while 
the M train does.  That breaks things like top-talkers, having 'ip flow 
egress' on interfaces etc.


If you don't find it out before hand, you certainly will afterwards, 
when your CPU utilisation goes up to 100% with only 20M or so of traffic.


Been there done that, went back to 15.1M quick smart (now on 15.2M and 
all good so far).


Reuben


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] spanning tree on me3600x

[Reuben Farrelly]

Hi Aaron

See:

http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software/release/15.2_4_S/configuration/guide/swevc.html#wp1002521

•When STP mode is PVST+ or PVRST, EFP information is not passed to the 
protocol. EVC only supports only MSTP.


We're running Rapid-PVST but it only operates on normal trunk and access 
ports, and not via EVCs.


I had a TAC case going where there was suspicions that STP was the cause 
of a problem we were seeing, advice from the BU engineer at the time was 
that Rapid-PVST would and could never be supported across EFP.  It's MST 
or nothing.


Reuben

On 27/12/2012 2:02 AM, Aaron wrote:

I don't see any instances of spanning tree running for various efp's I've
created in my ME3600.



Is there something different with spanning tree and the Me3600x that is much
different than older cisco switches ?



voice-3600#sh spanning-tree interface g0/4 efp 336

no spanning tree info available for GigabitEthernet0/4



voice-3600#sh run | in span

spanning-tree mode rapid-pvst

spanning-tree extend system-id

spanning-tree vlan 336 priority 24576



voice-3600#sh spann vl 336

Spanning tree instance(s) for vlan 336 does not exist.



voice-3600#sh run in g0/4



interface GigabitEthernet0/4

description ring 3 - 3y6 vlans

switchport trunk allowed vlan none

switchport mode trunk

load-interval 30

service instance 316 ethernet

   encapsulation dot1q 316

   rewrite ingress tag pop 1 symmetric

   bridge-domain 316

!

service instance 336 ethernet

   encapsulation dot1q 336

   rewrite ingress tag pop 1 symmetric

   l2protocol peer stp

   bridge-domain 336

!

End



___
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] Issues with MTI on multicast VPN (ME3600) Waris help ; )

[Reuben Farrelly]

Hi Daniel

On 21/12/2012 8:26 PM, daniel@reaper.nu wrote:

Hi,

I'm trying to setup Multicast VPN (MVPN) on a Cisco ME3600. It's a
ME-3600X-24FS-M and the software is
me360x-universalk9-mz.151-2.EY1a.bin. There seems to be an issue with
the MTI. I only see packets outbound but no packets coming in. This is
the configuration used, I had to remove some information that can't be
displayed publically.


http://www.cisco.com/en/US/docs/ios-xml/ios/ipmulti_mvpn/configuration/15-2s/imc_cfg_mc_vpn.html

The feature was new in 15.2(2)S.  Your -EY release is older than this 
(it pre-dates even 15.2(1)S), so what you are doing is probably 
technically unsupported.


Is there any reason you haven't tried code that is a bit more recent, 
such as 15.2(4)S2 (or 15.3(1)S if you're really brave) though?


Reuben

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] TAC Support [was Re: Moving Routing from 7206VRX to 6509-E]

[Reuben Farrelly]

On 17/12/2012 8:57 PM, Gert Doering wrote:

Hi,

On Sun, Dec 16, 2012 at 02:32:27PM -0800, Randy wrote:

It also may be worthwhile for your $Employer to consider some form of 
*service-contract* with Cisco. CCO has a wealth of information (for your own 
edification). You will need a valid-contract to have access to said info! 
Google-Foo will only get you so-far.


Actually, almost all technical documentation on CCO is available without
a contract.

Still, unless you have spare parts on site plus the experience to work
around IOS bugs, a support contract is a good recommendation.  (Not that
I'm always happy with the outcome of our tac cases...)


Completely agree.  The value for us has been in replacement hardware. 
I've never had any issues having hardware replaced when it's broken, so 
for this reason alone I'd recommend a contract (even if only a basic 
8x5xNBD one).  That's the real value that will get you out of a messy 
ugly situation in the event of hardware failure.  There is only so far 
you can go obtaining spares using a credit card, in a dire situation 
like a Sup failure or line card losing the plot.  It's usually easier to 
get an RMA on a card than buy a new one, as sparing seems to be based on 
smartnet, not distributor sales.


So I'd definitely recommend you get something to cover yourself.

In terms of TAC support, I've just this evening filled in one "feedback" 
form where I put 2 out of 5 for 3 sections and 1 out of 5 for two more 
on a single survey.  About the only good thing was the "courteous" 
treatment.  I've never given feedback with so poor numbers before.


That was for a CEF switching issue (or rather, lack of it) on a 2851, 
and after 3 months of going nowhere the case has been closed and I've 
been advised to talk to another engineer who was working on a completely 
unrelated crash on the box.  I don't think he knows he has acquired the 
case yet ;)  It just feels like a huge lob off and not a co-ordinated 
response.


Given past experience with much better scores I imagine I'll be 
contacted quite soon about that one.


I've got four more cases which I have had on the boil (one including a 
low priority SIP/NAT ALG problem ongoing for 54 weeks and counting, and 
we've only JUST in the last 5 days figured out the trigger and a 
workaround).  Metrics on happy vs unhappy cases aren't looking too good 
at the moment, and have gotten worse than ever before this year.


Having said that, I have had much better luck with the bigger platforms 
though, such as the 6500/7600, but then I've also had far fewer problems 
with them to begin with.


Reuben

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ISP Dual AS

[Reuben Farrelly]

On 6/12/2012 10:54 PM, mert ozkul wrote:

Hi All,
I have query about ISP Design.
Why some ISP`s (Ex: BT) using dual AS`es on their network?
What are the advantages of using more than one AS in the ISP network?What can 
be achieved if you use more than one AS?
Thanks,Best Regards,
-Mert


I operate a network where we have two AS's.  We inherited the second AS 
when we took over the second network.


Why haven't we merged this into one big AS?  Well the two AS's have two 
completely separate routing policies.  One of those AS's supplies only 
schools as downstream users, and the upstream connectivity to them is 
via a specific supplier (a regional educational/research network) whose 
rules of engagement are that they only supply to education/non corporate 
clients.


Our other AS is a bit more relaxed, and there is no such restriction 
with any suppliers to that network.


The two AS's peer with each other though so it doesn't cost anything for 
data to transit between them anyway.


It does pose some fairly minor complications in terms of training and 
one-bgp-as-per-IOS but given we have full control over both AS's and all 
the equipment in them, it means on the other hand that we get to work 
with some slightly more exciting things like inter-AS MPLS that you 
don't get to experiment with when it's all one vanilla system ;-)


Just one reason why an ISP may have more than one AS.

Reuben


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ISR G2 Licenses - Permanent vs Right To Use

[Reuben Farrelly]

On 28/11/2012 10:52 PM, Steve McCrory wrote:

Hi Group,

We've had a complaint from a customer that their security license on a
1941K9 is showing as Right To Use when they are expecting it to show
Permanent:

Index 2 Feature: securityk9

  Period left: Life time
  License Type: RightToUse
  License State: Active, In Use
  License Count: Non-Counted
  License Priority: Low

We've had this checked with our distributor who shipped us the router
pre-installed with the required license and they are happy that Right To
Use is correct. They even raised it with Cisco and they came back
quoting the Wassenaar Arrangement.

Can someone clear up the difference between the two terms as the Cisco
literature on the subject is confusing and our customer is like a dog
with a bone over this.


RightToUse (RTU) license are licenses that essentially are just honor 
based, ie you can freely use the features providing you have purchased 
the license, and there is no enforcement of the featureset on or off. 
This is basically how Cisco has historically licensed IOS for many years.


Permanent licenses are ones where a license key has been imported into 
the router IOS and are based on a cryptographic license key file.  These 
are node-locked licenses and tied to the serial number of the chassis. 
With a bit of messing around these can be transferred if you do an RMA.


If you've paid for and are entitled to a given featureset then yes, you 
should be getting what is called a Product Activation Key (PAK), which 
in turn you enter in to www.cisco.com/go/license, which then spits out a 
tiny license key file that you install on the router.  This then shows 
up as a 'permanent' license in the IOS.  Either that, or the license is 
pre-installed at the factory in which case it will show as a permanent 
license out of the box.  This is how it normally works, I've had dozens 
of routers shipped to us from our distributor that are done this way.


Cisco went down the path of enforcing licensing (ie permanent licenses, 
no RTU) on some newer IOS platforms but did a fast backpedal in a 
15.0/15.1 maintenance rebuild of IOS.  Presumably a few people seriously 
objected to it and the messing around involved in processing licenses, 
and Cisco realised it probably was causing more pain and lost sales than 
it was worth.  So pretty much across the board in so far as branch 
routers now we're back to where we started, ie honor based RTU licenses 
where the real proof of entitlement is a purchase order proving you've 
bought the license :-)


Reuben

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] MST Experiences: was Re: Dell switches (specifically PowerConnect 7048P) and Ciscos

[Reuben Farrelly]

On 27/11/2012 9:30 PM, Phil Mayers wrote:

Normally I'm not a big fan of "proprietary" protocols, but MST is so
awesomely sucky for Campus environments ("map all your VLANs to
instances before you start, and never change it" - yeah, right!) that we
mandate Cisco compatible PVST in all our edge.


Wow.  I thought it was just me and my lack of MST experience that was 
the problem when I've looked at migrating to MST - so it's reassuring to 
know it isn't just me who had had a bad experience with it.  Even 
starting by rolling it out at home on a small 4 switch (two vendor) in a 
ring topology seemed relatively painful.  Most definitely far far more 
pain than gain.  The thought of rolling it out to dozens of switches 
across multiple states just doesn't bear thinking about.


The main thing that has attracted me to look at MST was the widespread 
multivendor support for it.  The vlan-to-spanning-tree mapping concept 
seems good in theory - but as Phil has said you really only get one shot 
at getting it right.


What vendors, other than Cisco, support some form of Rapid-PVST?  I 
believe Arista do on their switches - are there any others?  If it's 
proprietary, did Arista license it from Cisco or...?  It seems so 
patently obvious that PVST would be a smart idea, yet so few vendors 
seem to support it.  What gives?


Reuben

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Multicast through Cisco ME-3600

[Reuben Farrelly]

On 24/11/2012 9:16 PM, Hitesh Vinzoda wrote:

Hi,

I have recently noticed that routers running OSPF connected to two
different ports and communicating via EFP's configured on Cisco ME3600 can
not form OSPF neighborship.



Cisco IOS Software, ME360x Software (ME360x-UNIVERSAL-M), Version
12.2(52)EY3, RELEASE SOFTWARE (fc1)


That is a very very ancient version of code for this platform - in fact 
it was the first branch of code ever even made for these switches. 
There were some pretty rough edges around the earlier releases but it 
has been getting better of late.


I recall having similar problems with something like this, but it was 
quite some time ago - so can you try an upgrade to something more 
recent, say, 15.2(4)S1 ?


Chances are TAC are going to suggest you try this anyway.

Can you also confirm you have the same MTU set on both edge routers and 
can ping at least 1500 end to end?  What does 'show ip ospf interface 
brief' and 'show ip ospf neigh' show as the state of the OSPF on each 
interface?


Reuben

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3800X, Policy Routing and SDM

[Reuben Farrelly]

On 7/11/2012 3:56 PM, Mal wrote:

Did you scope the purchase yourself ?

Mal


-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Reuben Farrelly
Sent: Wednesday, November 07, 2012 3:10 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] ME3800X, Policy Routing and SDM


Yes.  The SCALED license was documented (and still is) on CCO as public 
information as increasing the limits of MAC/IP and other platform 
limits, and not being something required to enable any new features:


"The ME 3800X supports these licenses plus a scaled license that can be 
installed with any of these licenses to increase the supported values 
for that license, for example, more MAC addresses, VLANs, IPv4 routes, 
and so on. "


We hadn't budgetted on having to purchase a SCALED license in order to 
get more functionality, because CCO indicates that's not what the SCALED 
license provides, and the business case was approved some months ago 
based on that premise.


So the question still is, is this license actually required (see my 
previous post in so far as it looks like it might work) or was this a 
mistake in the release notes?


Reuben
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] ME3800X, Policy Routing and SDM

[Reuben Farrelly]

We've recently purchased 3 ME3800s to use as core/aggregation switches 
and I'm in the process of labbing up and starting to apply 
configuration, in what at the moment is an isolated environment.


One of the features we need to use for a small number of customers in 
order to do some basic URL filtering, is Policy Based Routing.  We only 
need to policy route port 80 traffic from a select number and range of 
IP addresses.


This feature is new in 15.2(4)S on this platform.  We've got the 
MetroAggrServices license on all three units - the license that in 
theory has "the works".


Reading the release notes, I'm struggling to find out definitely how 
this feature works on the ME3600/ME3800.  Not so much the actual policy 
routing itself, but more so the licensing.


http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software/release/15.2_4_S/configuration/guide/swpbr.html

Firstly, this feature apparently requires simply an SDM change on the 
ME3600.  That's easy enough to do.  However the documentation states 
that on the ME3800 we need to purchase a SCALED license.  For those who 
haven't looked this up, it isn't a cheap line item, it's something like 
AUD$14,000 RRP on top of existing licenses, per unit (less a reseller 
discount).  Ouch.


Secondly, despite not having a SCALED license and with the default SDM 
template, the ME3800 actually allows me to configure PBR.  Is this 
intentional or is it going to collapse in a smouldering heap of process 
switched goup when I start pushing larger amounts of data through it?


The default SDM looks like this:



sw1#show sdm prefer current
The current License is MetroAggrServices
The current template is "default" template.

Template values:
  number of mac table entries=  128000
  number of ipv4 routes  =  24000
  number of ipv6 routes  =  12000
  number of routing groups   =  2000
  number of multicast groups =  2000
  number of bridge domains   =  4096
  number of acl entries  =  4000
  number of MDT mroutes  =  1000
  number of ipv6 acl entries =  1000
  number of ipv4 pbr entries =  2000

---

[Note the 2000 PBR entries, which suggests that hw resources are 
allocated, so it looks like it could work?!?!]


Thirdly, if I enable the evaluation of the SCALED license and reload, a 
new default SDM template is applied automatically, which removes all of 
my PBR TCAM:


sw2#show sdm prefer current
The current License is ScaledMetroAggrServices
The current template is "default" template.

Template values:
  number of mac table entries=  256000
  number of ipv4 routes  =  32000
  number of ipv6 routes  =  16000
  number of routing groups   =  4000
  number of multicast groups =  4000
  number of bridge domains   =  8192
  number of acl entries  =  16000
  number of MDT mroutes  =  1000
  number of ipv6 acl entries =  1000
  number of ipv4 pbr entries =  0

Then I have to set one of the VPNv4-only OR VPNv4-v6 SDMs to get any PBR 
space allocated again.  So it looks to me like enabling the SCALED 
license actually removes PBR capability from the default SDM, not adds them.


Fourthly, is the PBR VRF-aware?  It looks like not, but

And lastly, are the restrictions in regards to PBR (the lack of 
route-map deny and by the looks of it, the lack of deny support in ACEs 
relating to PBR) likely to be removed in the future?  Compared to the 
7609-S we're moving away from, this is a step backwards.


I'm confused, and the questions have been raised internally as to why we 
seem to need to spend yet more money on top of the existing hardware and 
licenses, just in order to enable PBR.  We don't otherwise need the 
SCALED license on this platform and we had figured previously that the 
most advanced license covered every -feature- we'd need.


To add insult to injury, it's actually going to work out very 
significantly cheaper to purchase a 3560-X floor switch or even another 
ME3600X just to do PBR.  But to do that just seems really silly.  I'd 
really like a bit more clarity on how this works on the ME3800 so we 
don't need to go down that path...


Reuben


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] npe-g2 + shaping

[Reuben Farrelly]

On 29/10/2012 7:11 PM, BALLA Attila wrote:

Hello,
   I met an interesting issue: there is a Cisco 7200 NPE-G2 with
12.4(24)T7, this router terminates some broadband users, we applied
shaping on the virtual-template and we surprised: shaping was not
working. We upgraded (downgraded?) to 12.2(33)SRE6 and the shaping was
working properly, so I think it is not a config issue.
This router has a SA-VAM2+, but SRE does not support this module.
First question: is it normal, that shaping is not working on
virtual-template at 12.4(24)T7?
Second question: is any release which supports shaping on
virtual-template and sa-vam2+?


I ran into the same problem with 12.4 releases on the 7200 and ISR 
G1/G2s some time ago when applying a QoS policy via RADIUS, (can't 
remember if it was in 12.4T but certainly was a problem in 12.4 
mainline).  This may be what you're running into.


The bug IDs for this were CSCte95297 and CSCti80776 .

Fixes for it were integrated in earlier 15.0M builds which in turn means 
15.1M and 15.2M also have the fixes.


The syntax for checking the QoS also changed - you need to use 'show 
subscriber session' commands from then on to see if the policy has 
applied and what, if any, drops are occurring.  It was a source of 
frustration that the old style 'show policy-map interface' commands 
didn't work anymore after that but restoring the old CLI output was 
considered an 'enhancement request' and I had no such luck getting that 
bit fixed :-(


Reuben




___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3600x sub-interfaces

[Reuben Farrelly]

On 27/10/2012 5:58 AM, Andrew K. wrote:

A downfall for using the SVI on the ME3600 is you can not apply an
inbound/outbound policy map to the SVI.


You can apply inbound and outbound policy maps to a Service Instance 
though (which are the ports that are facing your customer):


policy-map police-10M
 class class-default
  police cir 1000 bc 1024000
   conform-action transmit
   exceed-action drop

policy-map shape-10M
 class class-default
  shape average 1000

interface GigabitEthernet0/13
 description CUSTOMER
 switchport trunk allowed vlan none
 switchport mode trunk
 service instance 2003 ethernet
  description CUSTOMER
  encapsulation untagged
  service-policy input police-10M
  service-policy output shape-10M
  bridge-domain 120
 !
end

This achieves the same as on an SVI but with additional flexibility that 
you can apply the policy to whatever criteria you can match in your 
service instance (such as inner -q tags, CoS markings etc if you want to 
get more complex).


> We are applying them on the layer 2 trunk interface, gets annoying
> when you can to aggregate the rate-limit between multiple
> interfaces.

It looks like you can aggregate different classes across different 
ports, using qos-groups:


http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software/release/15.2_4_S/configuration/guide/swqos.html#wp1051872

Reuben
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] EVC traffic statistics over SNMP (ASR903 and ME3600x)

[Reuben Farrelly]

On 25/10/2012 1:44 PM, Pshem Kowalczyk wrote:

Hi

I have a bunch of ASR903 and ME3600x with EVCs configured on them. I
can see the traffic statistics using 'show ethernet service instance
detail ' or even 'show ethernet service instance id 2 interface
gigabitEthernet 0/4/0 stats'. Is there a way to extract them using
SNMP? I had a look in Cisco-EVC-MIB, but nothing obvious stands out.
Any hints?


Cacti and Solarwinds pick up all the Service Instances for me, as normal 
pollable interfaces like this:


GigabitEthernet0/20.ServiceInstance.3306
TenGigabitEthernet0/2.ServiceInstance.625
TenGigabitEthernet0/2.ServiceInstance.626

That's on ME3600X's with (currently) 15.2(4)S1 but it worked just fine 
on 15.2(2)S as well.


Reuben
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] LX GBIC at half duplex?

[Reuben Farrelly]

On 24/10/2012 7:44 PM, Phil Mayers wrote:

The only places we disable autoneg in our network are to connect to same
$FORMER_GOVT_TELCO, which makes me sad :o(


A bit OT, but a similar $FORMER_GOVT_TELCO here in Australia does the 
same thing on their business grade ethernet products.


They attempt to disable autoneg on 1000TX by hard setting speed and 
duplex (likely because this 'worked' for 10/100TX), but in practice this 
then forces autonegotiation but disables anything other than 1000/FULL. 
 A device with a 100M port connected won't even link up let alone pass 
data.


It seems to work this way on the ME3400E switches (and I think many others).

It's a royal pain if the customer has a low end branch router such as an 
1841 or an 881 that can't do 1000TX but does 100TX just fine - and the 
customer only needs a 10M or 20M circuit so can't justify a bigger 
router.  Or they need to do an emergency swap out and only have a low 
end router available at hand.


Of course we could just force upstream $TELCO to do 100/FULL for those 
customers who can't get link up, but, well, it must generate far more 
support work both on our side and the telco side to do this rather than 
the 'auto-by-default' approach and fall back to hard-set if all else fails.


Reuben




___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Cisco 7200G1 LNS IOS version?

[Reuben Farrelly]

No issues whatsoever with 15.1M (and very recently 15.2M) on the NPE-G1 
here.  I've got MPLS/L2TP/BGP running on it and I haven't had a single 
problem with this code so far.  I suggest you keep to the latest 
rebuilds though.


12.4 is probably a bit of a lost cause as it's not going to see many (if 
any) more bug fixes.


Reuben


On 24/10/2012 4:07 PM, Skeeve Stevens wrote:

Hey all,

We've got some Cisco 7200VXR-NPEG1 running as LNS's for DSL/etc... anything
with L2TP really.

For years we've gone with IOS 12.2SR trains as they seem to work just fine.

I am having some issues at the moment which I will post separately.

But, What IOS are others running/recommending for IOS 12.2, or should we be
looking at 12.4 or something else entirely... preferably not going to 15
though.

...Skeeve

___
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] Advanced Metro license, ME-3600

[Reuben Farrelly]

The Eval license does not require a license be obtained from CCO.  Only 
permanent non-expiring licenses require the special file/key.


sw6.nsw(config)#license boot level advancedMetroIPAccess

Pretty sure this is all you need to activate the 60 day eval.

Unfortunately I don't have any ME3600s around that don't have the ADV 
license to test with.


This is the exact same process as other newer Catalyst switches, FWIW. 
It's not unique to this platform.


Reuben


On 28/09/2012 8:23 AM, Eric A Louie wrote:

I don't see an eval license for "ME 3600X Advanced Metro" under Routers
& Switches
Much appreciated,
Eric Louie
619-743-5375


--------
*From:* Reuben Farrelly 
*To:* Aaron 
*Cc:* Mattias Gyllenvarg ; Eric A Louie
; cisco-nsp@puck.nether.net
*Sent:* Thu, September 27, 2012 2:56:05 PM
*Subject:* Re: [c-nsp] Advanced Metro license, ME-3600

If you get an E-License Delivery instead of the license coming
preinstalled on the switch, the process is still actually very
straightforward.

All you have to do is fill in a short form online and enter a key from
the E-License PDF, the actual license file itself then gets emailed back
to you straight away, and it's just then a case of uploading the file to
the switch.

http://www.cisco.com/go/license/

I'm not a big fan of complexity, but this process really is as easy (or
complex) as downloading an IOS image from CCO.

If the E-license doesn't turn up with the hardware there's always the 60
day Eval License which you can activate without any keys to buy more time.

Reuben


On 28/09/2012 5:22 AM, Aaron wrote:
 > I get some with and some without... the ones without I send system serial
 > number to my cisco account se and she sends me a license file
 >
 > Aaron
 >
 >
 > -Original Message-
 > From: cisco-nsp-boun...@puck.nether.net
<mailto:cisco-nsp-boun...@puck.nether.net>
 > [mailto:cisco-nsp-boun...@puck.nether.net
<mailto:cisco-nsp-boun...@puck.nether.net>] On Behalf Of Mattias Gyllenvarg
 > Sent: Thursday, September 27, 2012 1:40 AM
 > To: Eric A Louie
 > Cc: cisco-nsp@puck.nether.net <mailto:cisco-nsp@puck.nether.net>
 > Subject: Re: [c-nsp] Advanced Metro license, ME-3600
 >
 > Have had both ways. Always get them preinstalled now.
 >
 > Licencing process is a pain.
 >
 > On 27 September 2012 00:35, Eric A Louie mailto:elo...@yahoo.com>> wrote:
 >
 >> Hey folks, I'm trying to get the straight scoop on the licensing issue
 >>
 >> I received an ME 3600x from my reseller, without the Advanced Metro
 >> license.  I did order the license from them.  Is there a normal wait
 >> for getting it, or is the reseller trying to smokescreen me?  Or,
 >> should I have received the license on shipment of the switch?
 >>
 >>  Much appreciated,
 >> Eric Louie



___
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] Advanced Metro license, ME-3600

[Reuben Farrelly]

If you get an E-License Delivery instead of the license coming 
preinstalled on the switch, the process is still actually very 
straightforward.


All you have to do is fill in a short form online and enter a key from 
the E-License PDF, the actual license file itself then gets emailed back 
to you straight away, and it's just then a case of uploading the file to 
the switch.


http://www.cisco.com/go/license/

I'm not a big fan of complexity, but this process really is as easy (or 
complex) as downloading an IOS image from CCO.


If the E-license doesn't turn up with the hardware there's always the 60 
day Eval License which you can activate without any keys to buy more time.


Reuben


On 28/09/2012 5:22 AM, Aaron wrote:

I get some with and some without... the ones without I send system serial
number to my cisco account se and she sends me a license file

Aaron


-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mattias Gyllenvarg
Sent: Thursday, September 27, 2012 1:40 AM
To: Eric A Louie
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Advanced Metro license, ME-3600

Have had both ways. Always get them preinstalled now.

Licencing process is a pain.

On 27 September 2012 00:35, Eric A Louie  wrote:


Hey folks, I'm trying to get the straight scoop on the licensing issue

I received an ME 3600x from my reseller, without the Advanced Metro
license.  I did order the license from them.  Is there a normal wait
for getting it, or is the reseller trying to smokescreen me?  Or,
should I have received the license on shipment of the switch?

  Much appreciated,
Eric Louie


___
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] Are Nexus and per-interface or FEX MTU settings possible?

[Reuben Farrelly]

I'd like to further clarify this - as I think the subtleties here 
between layer 2 and layer 3 MTU may be giving a misleading picture.


The Layer 2 MTU (AKA frame size) is set globally, in the same way as on 
a Catalyst floor switch such as a 3560/3750 is done.


This is performed by something like this in the config:

-

policy-map type network-qos enable-jumbo-frames
  class type network-qos class-default
mtu 9216

system qos
  service-policy type network-qos enable-jumbo-frames

--

However the Layer 3 MTU is customisable, per VLAN interface:

---

SWT01(config)# int vlan 22
SWT01(config-if)# mtu ?
  <64-9216>  MTU size in bytes

SWT01(config-if)#

interface Vlan22
  no shutdown
  mtu 9216

-

In the majority of cases you will probably want to have a high layer 2 
MTU globally, and then perhaps be more careful with your layer 3 MTU 
settings at your layer 3 boundaries (the default is almost always 1500 
so unless you specifically modify it, that's what it'll be, regardless 
of your layer 2 MTU).  If you aren't doing any Layer 3 switching on the 
device then the layer 3 MTU setting obviously won't be necessary on there.


The config above is from a 5548UP running 5.2(1)N1 (that has the L3 
daughter card).


I'm not aware of any negative side effects on this platform from setting 
the layer 2 MTU to a high value globally.  Things most certainly break 
badly when the L2 MTU is set too small, but not usually when it's too big.


Reuben


On 20/09/2012 4:01 PM, Lars Christensen wrote:

Hi Joshua,

You can't set a per interface MTU on the Nexus 5500-series switches.
However, you can do it on per Class of Service.

So in order to do increased MTU for your iSCSI traffic, you should
create a policy-map identifying your iSCSI traffic, place the traffic
in a separate queue with increased MTU.

This is the way to go forward.


Lars Christensen CCIE #20292

___
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] ME3600X - Bridge Domain Routing with SVI

[Reuben Farrelly]

Hi Steve

A few things to check:

1. You have vlan 200 created on the 3524 (the commands you have in the 
diagram will be permitted without the actual vlan existing on the switch)


2. You may need to set the q-in-q outer tag on the 3524 with the 
following commands on the Fa0/1 port:


switchport mode dot1q-tunnel
switchport access vlan 200

And just have the 1841 pass single tagged frames to the 3524, allowing 
the 3524 to add the extra (outer) q tag.  Obviously this is slightly 
different to what you are doing now but it's more common - may be what 
you actually want to do.  Assuming that the 3524 supports dot1q-tunnel - 
3550s, 3560s and above all do, can't remember if the 3524 can or not.


3.  Don't forget to increase the MTU globally on the 3524 and on the 
ME3600 per-port to at least 1504 to account for the extra q tag.  You'll 
definitely need more than 1500 (the default) to avoid very nasty layer 2 
MTU problems.  This won't fix the pinging problem but it will cause much 
hair loss later on if you don't address it at the time of setup ie now.


4.  And lastly, I have run into problems with this sort of thing before 
with carriers in between the various devices permitting (or more 
specifically, not actually permitting) double tagged frames across their 
networks.  Not sure if this applies to you or not.


Hope this helps.  I've been down this learning curve myself in the last 
12 months, once you master it the metro ethernet gear is simply 
fantastic at this sort of stuff and you'll wonder how people ever build 
customer facing networks without it :-)


Reuben


On 4/09/2012 8:30 PM, Steve McCrory wrote:

Hi list,



I'm having a play about with the EVC features of the ME3600 and I've hit
a problem with Bridge Domain Routing.



I have a CE configured with stacked VLANs connected to the trunk port of
a 3524, with an outer VLAN of 200 and an inner VLAN of 100. The 3524 has
a trunk port connected to an ME3600X. VLAN 200 is defined locally on the
3524 and allowed on both trunk ports.



The corresponding port on the ME3600 has been configured with a service
instance, matching double-tagged frames (200/100). I've popped the two
tags and I'm trying to ping from an SVI on the ME3600 back to the CE
interface but without success. I've followed the Cisco config guide for
enabling bridge domain routing with two tags


___
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] me3600 svi's not showing in and out bit counts that i see on corresponding phy int

[Reuben Farrelly]

15.2(2)S2 released today for this platform has this as a "Fixed" defect:

CSCtw79488
Symptoms: Multicast is not forwarded out on EVC.
Conditions: This has been observed with Cisco IOS Release 15.1(2)EY and 
EY1a and with the following configuration:


So you may be in luck.

Reuben


On 10/08/2012 12:25 AM, Andrew K. wrote:

Would be great if multicast worked corrected through the efp.

On 8/9/2012 10:19 AM, Aaron wrote:

Thanks Reuben.  By efp's, I take it you mean the command structure for
Ethernet service instance, bride domain, etc.  right ?


___
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] me3600 svi's not showing in and out bit counts that i see on corresponding phy int

[Reuben Farrelly]

It seems to be an architecture thing - this has been the case across all 
of the code drops on this platform so far to date.  I suspect only 
process switched data is counted in those interfaces.


You'll need to poll EFP's on these switches instead of VLAN interfaces 
for measuring data flows - those are per-service+per-port and the SNMP 
counters on those do get populated.  And if you're not yet using EFP's 
then you're probably not using these switches to their full potential :-)


Reuben


On 8/08/2012 11:54 PM, Aaron wrote:

anybody know why me3600 svi doesn't seem to show in and out bit counts that
the underlying phy int shows?  all svi's (10,11,13) are in a vrf running
over mpls l3vpn



___
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] MPLS over GRE/IPSEC

[Reuben Farrelly]

No it won't.  The OP wants a device which can handle 1G of throughput.

A 1941 has the required MPLS, MTU and crypto functionality with a DATA 
and SECURITY license (and are quite adequate as a low end MPLS device of 
say, sub 100M) but it won't handle anywhere /remotely/ near 1G of 
throughput - let alone 1G of encrypted throughput.


Are you sure you are not confusing the 1G physical port speed with 1G of 
actual data pushing throughput?


Reuben


On 8/08/2012 5:16 PM, Aivars wrote:

Well, 19xx with a proper licensing will work. Everything else depends
on pps and scale.


  Aivars


___
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] Replace 3750 with 3600x

[Reuben Farrelly]

On 7/07/2012 11:45 AM, Dan Letkeman wrote:

Hello,

Looking at replacing a 3750G-12S-12 with an ME-3600X-24FS-M.  I have
never used or seen a 3600x, and I was wondering for the basic switch
services does it have the same command line options.  Just doing dot1q
trunking, maybe some qos marking, rstp, eigrp, etherchannel, and some
simple ipv4 acls.

Thanks to anyone who can comment.


Yes, generally speaking the same command line options apply.  It's still 
15.S IOS code in both.


However note that the hardware between the 3750G and 3600X is totally 
and completely different though (the ME3600X hardware is much much 
better).  The software follows different trains too but like most IOS it 
still has more or less the same command line options.


Notable points/things that you may run into:

- No VTP (although I'd never use VTP in an SP environment anyway so 
that's not a bad thing)


- VLAN interfaces and trunk ports can be configured the same as a normal 
enterprise switch if you want to, however you will gain a lot of very 
cool flexibility by configuring your trunks/customer facing ports using 
EVC's instead.  So take the plunge and set things up the EVC way where 
possible from day dot, as it'll allow you to take advantage of many of 
the metro ethernet edge features that this platform has to offer that 
you don't get on a switch like the 3750G.  Plus it'll give you 
per-service-instance counters.  The VLAN interface counters on this 
platform don't populate with the total traffic flow (same as the 3750G), 
but the service instances /do/ have counters which allow per-vlan and in 
turn per-EVC graphs to be generated.

QoS and ACLs can be applied on EVCs as well.

- From memory the units do not ship with any power supplies.  Check 
before you place the order :-)


But otherwise, everything you've listed is easily do-able and shouldn't 
present any problems, and you should be able to copy and paste config 
across between the two units with few surprises.


Having run these switches for over a year now in production, I really 
like them and I wouldn't want to ever go back to making do with 3750s in 
my network core or edge.


Reuben

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3600X IOS Version

[Reuben Farrelly]

I'd recommend 15.2(2)S1.  15.1(2)EY is a branch release which probably 
won't have a long lifespan now that these switches have been integrated 
into mainline S code.


15.2(2)S1 has been solidly stable for us with the exception of what 
appears to be a cosmetic bug in that these messages are printed to the 
console:


"Jun 25 17:10:02.164: %SFF8472-3-THRESHOLD_VIOLATION: Te0/2: Rx power 
high alarm; Operating value:   1.4 dBm, Threshold value:   0.0 dBm."


I vaguely recall seeing a DDTS Caveat about this problem too.

Otherwise all good, no other issuesand really like the hardware.

Reuben


On 25/06/2012 5:08 PM, Ivan wrote:

Hi,

I know the ME3600X has come up quite a lot recently on this list, but as
far as I recall and can find, it has been a while since there have been
any comments regarding the "best/most stable" version.

I am currently running 151-2.EY but will deploying some more hardware
shortly and would be interested  what versions others are successfully
using, especially 15.2S or 15.2S1.  151-2.EY has been good so far but I
am aware of the rapid development on software for this platform and also
that there are quite a few issues around.


___
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] VS-S720-10G alternative

[Reuben Farrelly]

I have a requirement for a 1G/10G access switch also for a meet-me room 
project I am working on, and the 4500-X ticks all the boxes - except for 
the MPLS capability.  The lack of this feature means I will likely have 
to backhaul data back to an MPLS capable switch or an ASR1k in another 
location.


I don't need a unit which can handle 24x10G (240G) of sustained 
throughput but I do need to plan for a handful of 10G handoffs which may 
do 2 or 3 Gbps in the near future.  Two 10G uplink ports isn't enough, 
and the 7600 platform looks to be ridiculously expensive for this sort 
of thing (not to mention space and power requirements).


A cross between a 4500-X and ME3600X/ME3800X would be an absolutely 
killer box.  Then again, I guess that would involve Enterprise and 
Service Provider BU's within Cisco talking (Gert?) ;)


Reuben


On 13/06/2012 10:44 PM, Andrew Miehs wrote:

Sent from a mobile device

On 13/06/2012, at 22:00, scott owens  wrote:


for those of you looking at the sup720-10G or 7k ( I have sets of both of
them as well ), take a look at Ciscos new 4500X 1U 10G/1G switch/router.




With an SFP+ ZR optic this can do just about anything an X2 or XenPak
6704/6708/6716 could do.



Except mpls :(
___
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] setting max mtu on switch (Jumbo)

[Reuben Farrelly]

On 29/05/2012 6:09 PM, Gert Doering wrote:

Is it best practice to set all switches to max mtu?


"Big enough to achieve what you need to achieve".  If all your L3 devices
only use 1500 bps MTU, and no EoMPLS tunneling or whatnot, there is no
real benefit in upping the switch MTU.  There does not seem to be a
downside either, though.

gert


I've often wondered about supposed downsides myself.  Why is it that we 
don't see the layer 2 MTU set as high as possible on Cisco devices out 
of the box, but a relatively "normal" routing MTU set to 1500 in the 
default config?   Are there any "bad things" that could come out of this 
config?


Some of the HP (Flex 10 etc) switches we run here do jumbos by default 
and I don't think there is any way to lower it. Then again these are 
storage switches so


Reuben
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Stacking 3750X vs diverse 4948E

[Reuben Farrelly]

Yes - the 5548 does routing.  We have 2x 5548UP's with the Layer 3 
daughtercard in our small corporate DC.


It does routing, yes, but you need to be aware of caveats around the 
feature.  I suppose you could say that about any Cisco switch, but bear 
in mind that NX-OS is aimed and targeted at the Data Centre market more 
so than the Service Provider market so you you'll probably find it far 
more feature rich in DC features such as Fibre Channel, than SP features 
like EVCs (which btw it doesn't support).


You'll probably also find that there aren't a lot of choice of software 
releases of code since the daughter card was introduced (and there are 
now two variants of this, the second hardware revision has more onboard 
resources).  The quality of the code is reasonable but there aren't many 
to choose from, and well, I'd be interested to know of anyone who has 
really hammered the BGP code to the limits ;)


It's also nice to be able to go from 1G to 10G by just upgrading SFP's.

We've had to leave a 3560 in production to do IPv6 routing and policy 
routing as it just can't be presently done on the Nexus 5000, and 
there's no word when IPv6 routing will be supported on it, if ever.


Reuben



On 20/05/2012 3:25 PM, Alexander Lim wrote:

I think Nexus 5500 series support L3.

Regards,
Alexander Lim

On May 20, 2012, at 12:54 PM, Skeeve Stevens  
wrote:


Feature / Nexus 5010 / 3750X

VLANs / 507 / 1005
MAC / 16k / 4k-12k
L3 / N / Y
vPC / Y / N

Nexus 5010 - less VLANs, no Layer 3, vPC
3750X - more VLAN, Layer 3, no vPC


*Skeeve Stevens, CEO*
eintellego Pty Ltd
ske...@eintellego.net ; www.eintellego.net 

Phone: 1300 753 383 ; Fax: (+612) 8572 9954

Cell +61 (0)414 753 383 ; skype://skeeve

facebook.com/eintellego

twitter.com/networkceoau ; www.linkedin.com/in/skeeve

PO Box 7726, Baulkham Hills, NSW 1755 Australia

The Experts Who The Experts Call
Juniper - Cisco – IBM



On Sun, May 20, 2012 at 10:03 AM, scott owens wrote:


How about Nexus 5010s.

I think they bundle them for less than 2 x 3750X .
We have both but the 3750s are used where we needed L2/L3, the 5Ks for just
L2 up to VSS or 7Ks.


you can boot them separately and they do LACP / Etherchannel just fine.





  2. Stacking 3750X vs diverse 4948E (David Coulson)
Message: 2
Date: Fri, 18 May 2012 14:55:57 -0400
From: David Coulson 
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Stacking 3750X vs diverse 4948E
Message-ID: <4fb69b3d.3060...@davidcoulson.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

In a datacenter environment, we typically deploy 4948 top-of-rack
switches with L2 uplinks to our 6500 core - Systems get connections into
two different switches and rely on OS NIC bonding (mostly Linux) to
support switch failures. Switches running STP and in the last four years
we've had no issues with this design (including failures of systems
connected to diverse switches).

A new proposed configuration utilizes stacked 3750X switches, where
servers would be connected to multiple switches within the same stack. I
have next to no experience in the low-end switches that do stacking, but
from a general risk management perspective, it seems like a many eggs
and single basket configuration.

Does anyone have any solid experience with 3750X switches, or stacking
in a datacenter in general? I've seen plenty of stacks for
closets/end-users, but I don't see many in a top-of-rack config. Is
Cisco stacking typically 'reliable', in that when a switch fails it will
leave the remainder of the stack functional? What about a software
issue? Does the whole stack crap out and reload, or does the master just
fail and a new one get elected?

I realize it's a pretty broad question, but it boils down to - Is a
stacked switch config significantly less reliable/resilient/available
than two TOR switches?

David



___
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] Small DC switch design

[Reuben Farrelly]

In the absense of Waris chiming in, PBR isn't yet supported on the 
ME3600, I believe.


Last posting about this as of Dec 2011 was that PBR was on the roadmap, 
and I haven't yet seen it come up as a new feature in any of the 
software releases subsequent to this.


You may (or may not) be able to configure it in the CLI, but it isn't 
supported, so YMMV.


My understanding of most access/floor switches such as the 3560/3750 
that do support PBR though is that PBR can be done at line rate on those 
platforms.  Certainly it will load up a software based router but on a 
hardware based switch it should be nearly if not totally hitless.


Reuben


On 17/05/2012 12:08 PM, Dan Letkeman wrote:

This switch will never need to hold a bgp table.  I do how ever want
to do PBR, and I am finding mixed messages on if it works or not.  And
if it does work will it work in my situation or will it switch in
software and have poor performance?   The idea of using it as an
aggregation switch would mean that it would have to do PBR at line
speed which it probably won't do.  I don't know if there is a better
way to do what I am trying to accomplish but my scenario is like this:

traffic -->---me3600x-router a--firewall
  |
  -router b-firewall

All I want to do is PBR some traffic to router b.   The link speed
will be either 1gbps fiber or 2gbps etherchannel, and if I apply a
route-map on an interface at that speed will it choke?  If so what
other option do I have?

___
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] 7206VXR NPE-G2 IOS

[Reuben Farrelly]

12.4(24)T End Of Life notice:

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8802/ps6968/ps6441/eol_c51-632350.html

What tool are you referring to - what is the "Cisco feature tool" ?  Do 
you mean Feature Navigator?  And what are you trying to look up?


Reuben


On 17/05/2012 12:04 AM, ar wrote:

Thanks.

How come 12.4 has March 2012 update?
Same with 12.2 SRE?
Is 15.1 more stable?

Weird thing about 15.1 is whenever I check cisco feature tool for that
IOS, it displays the message below:

"The Image Name you entered does not match any supported Cisco software
releases in this tool. Please change the Image Name and search again.
Thank you."

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 7206VXR NPE-G2 IOS

[Reuben Farrelly]

I'd probalby go 15.1M - but not 12.4.24T.

12.4T is gone, dead, buried and won't see many (if any) more bug fixes. 
 I wouldn't bother going there.  The upgrade path from that is 15.0(M) 
or 15.1(4)M anyway which has 'MD' status.


You could also consider 15.1(3)S2 as that seems to be quite good for us 
(on a 7200 NPE-G1 though, but the code should be largely the same on the 
G2).  However 15.1(3)S does NOT have Netflow support, so if Netflow is 
important to you then 15.1(4)M4 will probably be the more logical choice.


Apparently the last IOS builds that we'll see for the 7200s are to be 
15.2(4)M and rebuilds due out in a couple of months.


Reuben


On 16/05/2012 8:02 PM, ar wrote:

My requirements are:
- MPLS PE functionality
- LNS/L2TP with IP TOS Reflection


I am eyeing the following:

12.4.24T7(ED)
c7200p-advipservicesk9-mz.124-24.T7.bin

or

12.2.33 SRE6
c7200p-advipservicesk9-mz.122-33.SRE6.bin

Both released March2012.



Or should I go up to 15.1?

___
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] Apply service policy via Radius?

[Reuben Farrelly]

It works on 15.1M - at least on the 2800s and 7200s (I've got 15.1(4)M3 
in production and planning 15.1(4)M4 which just came out a couple of 
days ago).


The secret combo probably relates to how you are checking out the feature:

rt1.nsw#show subscriber session username xxx@yyy
Unique Session ID: 259
Identifier: xxx@yyy
SIP subscriber access type(s): VPDN/PPP
Current SIP options: Req Fwding/Req Fwded
Session Up-time: 2w6d, Last Changed: 2w6d
Interface: Virtual-Access17

Policy information:
  Authentication status: authen

Session inbound features:
 Feature: QoS Policy Map
  Input Policy Map: police-0.512M

Session outbound features:
 Feature: QoS Policy Map
  Output Policy Map: police-0.512M

Non-datapath features:
 Feature: Interface-Config

Configuration sources associated with this session:
Interface: Virtual-Template10, Active Time = 2w6d

rt1.nsw#

Note: nothing shows up if you do a 'show policy-map interface 
virtual-access 10', you need to use the 'show subscriber' command instead.


I did ask the TAC engineer at the time of resolving the bug if the 
command syntax could be fixed as well so that it is consistent across 
interface types, but apparently this needed to go through as an 
'enhancement' via our AM and needed a business case before it would be 
considered etc etc


Reuben


On 29/03/2012 11:26 AM, Cassidy Larson wrote:

Just resurrecting an old thread.

Anybody have any new information on "Per-user QoS policies via RADIUS" on 15.1?
I have a 1941 running 15.1(4)M1 that I'd like to accept the above, but
am unable to figure out the secret combo.

Thanks,

-c


On Mon, Mar 8, 2010 at 3:00 AM, Reuben Farrelly
  wrote:

What version of IOS code are you running?

Just in case this apples to you, note that the feature "Per-user QoS
policies applied via RADIUS" is broken in all versions of IOS 15.0, and as
far as I can tell, many versions of 12.4T including 12.4(15)Tx and possibly
earlier, on multiple platforms.  Apparently the code is "broken" on the 7200
and "the feature is not present" on the ISRs.  I reported this bug to TAC
and tested on both 7200 and ISR (2851) platforms.

12.4M works OK on both platforms so you might want to try out 12.4(25)c on
either platform, where the code "exists" and "works".

See CSCte95297 for the gory details.

Reuben



m...@adv.gcomm.com.au wrote:


Hi,

Have DSL users terminating on LNS(7204) via Eth, with radius auth -
Trying to apply the following service policy(Configured on LNS) upon
successful auth:

policy-map JF-2MB-ADSL
class class-default
shape average 185


___
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] ME3600 BGP Route-Maps and IPv6 (WAS: Re: preference on bgp route advertisements)

[Reuben Farrelly]

No - as opposed to having no route-map matching IPv6 at all.

So, if I have a route-map that (after my correction) actually matches an 
IPv6 route at the top of the route-map sequence and sets the community 
value of that IPv6 matched route, then it works as expected.


If I have a route-map that parses IPv6 routes, but does not match any 
IPv6 routes (no match ipv6 ... defined anywhere in any of the route-map 
sequence entries) then it matches on the first _IPv4_ route map entry 
and sets the community of that IPv6 route to the IPv4 match instead. 
That's the bug :)


Reuben


On 8/03/2012 2:48 PM, Mark Tinka wrote:

On Wednesday, March 07, 2012 06:01:41 AM Reuben Farrelly
wrote:


Correction.  I made a mistake in my testing there...

If I have:

ipv6 prefix-list PERMIT-IPV6-ANY seq 10 permit ::/0 le 64

Then yes the IPv6 specific route-map matches first and
the correct community is set.


You mean as opposed to "... le 48"?

Cheers,

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] ME3600 BGP Route-Maps and IPv6 (WAS: Re: preference on bgp route advertisements)

[Reuben Farrelly]

On 6/03/2012 10:29 PM, Reuben Farrelly wrote:


Have you tested whether having a dedicated route-map for the
IPv6 session works around this problem?


Yes - it doesn't work around it. I have just replicated the route-map
exactly but removed the IPv4 specific match (seq 10) from the new copy
and it works as expected (ie correct community set as a default/fall
through even for IPv6 routes).

And...get this...if I add:

ipv6 prefix-list PERMIT-IPV6-ANY seq 10 permit ::/0 le 48

route-map IBGP-STATICS permit 5
match ipv6 address prefix-list PERMIT-IPV6-ANY
set origin igp
set community 38858:202

at the top of the route-map sequence (which should match first for IPv6
routes, right?), then IPv6 BGP routes seemingly do NOT match that
route-map even across session resets - as that (unique) community value
is never set.

So it looks to me very likely it's a matching problem in that the match
ip prefix list is matching IPv6 routes when it should be an IPv4 only
match and then, only a specific IPv4 match.


Correction.  I made a mistake in my testing there...

If I have:

ipv6 prefix-list PERMIT-IPV6-ANY seq 10 permit ::/0 le 64

Then yes the IPv6 specific route-map matches first and the correct 
community is set.


Reuben
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3600 BGP Route-Maps and IPv6 (WAS: Re: preference on bgp route advertisements)

[Reuben Farrelly]

On 6/03/2012 9:46 PM, Mark Tinka wrote:

On Tuesday, March 06, 2012 04:29:45 PM Reuben Farrelly
wrote:


WTF?  The IPv6 prefix has been matched by the IPv4
specific route-map sequence 10, and the community from
that route map of 38858:2504 'set' on the router. It
should be falling through to sequence 100 on account of
a no-match on sequence 10, I thought.  I mean it's not
even the same friggin protocol...

(And no, there's no IPv6 prefix lists defined at all,
anywhere, on that switch)


Interesting.

Well, that's one of the reasons we use dedicated routing
policies for both IPv4 and IPv6, including different route-
map names as well, to avoid potential issues such as these
(unintended or otherwise).

Have you tested whether having a dedicated route-map for the
IPv6 session works around this problem?


Yes - it doesn't work around it.  I have just replicated the route-map 
exactly but removed the IPv4 specific match (seq 10) from the new copy 
and it works as expected (ie correct community set as a default/fall 
through even for IPv6 routes).


And...get this...if I add:

ipv6 prefix-list PERMIT-IPV6-ANY seq 10 permit ::/0 le 48

route-map IBGP-STATICS permit 5
 match ipv6 address prefix-list PERMIT-IPV6-ANY
 set origin igp
 set community 38858:202

at the top of the route-map sequence (which should match first for IPv6 
routes, right?), then IPv6 BGP routes seemingly do NOT match that 
route-map even across session resets - as that (unique) community value 
is never set.


So it looks to me very likely it's a matching problem in that the match 
ip prefix list is matching IPv6 routes when it should be an IPv4 only 
match and then, only a specific IPv4 match.


Only reason I've kept route-maps and other things constant is to 
essentially overlay IPv6 atop of the existing IPv4 network as far as 
possible.  Much easier to administer and support if the 
communities/policies/route-maps are the same etc but obviously this has 
the drawback that a problem with one part of the config can then screw 
up both protocols, or as I have just found out it makes it a bit more 
tricky to work around bugs in one or the other :-(.


Reuben

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] ME3600 BGP Route-Maps and IPv6 (WAS: Re: preference on bgp route advertisements)

[Reuben Farrelly]

On 6/03/2012 4:54 PM, Mark Tinka wrote:

For static routes, assigning a tag to the routes and
referencing that in a route-map which is attached to a BGP
policy will get you what you want. The tag is useful to
ensure you don't end up redistributing more routes into BGP
than you should.

For Connected routes, well, to ensure you don't redistribute
interface routes that shouldn't be in BGP, you'd need to add
another match condition such as a prefix list.

You need to evaluate whether the efforts of both options
above are more or less efficient than the 'network'
statement option, in your particular environment.


It's actually rather topical that your two postings today Mark have been 
separately about BGP route advertisements and the ME3600's because just 
a few hours ago I logged a TAC case on the BGP route-map broken-ness I 
am currently seeing on the ME3600/ME3800s I have.


This config (simplified a bit):

router bgp 38858
 address-family ipv6
  redistribute static route-map IBGP-STATICS
 exit-address-family

route-map IBGP-STATICS permit 10
 description Customer Subnet
 match ip address prefix-list PERMIT-CUSTOMER-SUBNET
 set origin igp
 set community 38858:2504
!
route-map IBGP-STATICS permit 100
 description Set a community on static routed internal only subnets 
which are not otherwise defined above

 set community 38858:201 no-export

ip prefix-list PERMIT-CUSTOMER-SUBNET seq 20 permit 203.56.29.0/24

ipv6 route 2401:8C00:99::/64 Null0


Gives this:

sw7.nsw#show ip bgp ipv6 unicast 2401:8C00:99::/64
BGP routing table entry for 2401:8C00:99::/64, version 271
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  Local
2401:8C00::42 (metric 1) from 2401:8C00::41 (124.158.18.41)
  Origin IGP, metric 0, localpref 100, valid, internal
  Community: 38858:2504
  Originator: 203.56.29.230, Cluster list: 124.158.18.41
  Local
2401:8C00::42 (metric 1) from 2401:8C00::40 (124.158.18.40)
  Origin IGP, metric 0, localpref 100, valid, internal, best
  Community: 38858:2504
  Originator: 203.56.29.230, Cluster list: 124.158.18.40
sw7.nsw#

WTF?  The IPv6 prefix has been matched by the IPv4 specific route-map 
sequence 10, and the community from that route map of 38858:2504 'set' 
on the router. It should be falling through to sequence 100 on account 
of a no-match on sequence 10, I thought.  I mean it's not even the same 
friggin protocol...


(And no, there's no IPv6 prefix lists defined at all, anywhere, on that 
switch)


On other platforms such as ISR G1s and ISR G2s running 15.1(4)M3 this 
works as expected.  IPv4 and IPv6 routes that fall through have these 
community values set right.


15.1(2)EY1a, TAC case SR 620949745 for anyone who is interested.  The 
TAC engineer is currently assessing the business impact and researching. 
 Bit hard to emphasize the severity of this one in terms of impact to 
end users...


Reuben

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3400 GRE

[Reuben Farrelly]

On 21/02/2012 8:18 PM, ar wrote:

Any known issue with ME3400 metroipaccess IOS?


I am thinking that as the ME3400 is more of a "Catalyst" switch than a 
router, it won't be supported (or if it does work at all it will be in 
software not hardware) in much the same way that other low end Catalyst 
switches that run almost the same software also have similarly severe 
limitations in terminating GRE.


You should consider a router such as a 1941 for this job, it should be 
able to do >100M of throughput if you don't do anything too fancy, and 
list price is about the same as the ME3400 anyway.


Reuben


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] Cisco's new 4500-X 10G Aggregation Switches

[Reuben Farrelly]

Looks like just up on CCO in the last week:

http://www.cisco.com/en/US/prod/collateral/switches/ps10902/ps12332/data_sheet_c78-696791.html

So finally - a 10G 1RU SFP+ access device.  It seem to be targeted at 
enterprise aggregation but I imagine would have some appeal in service 
provide space too given the form factor and the fact that the only 10G 
alternates are 3560E-12D's (with X2), Nexus, and upwards from there is 
of course the 4500/6500 chassis based units.


Running IOS XE, has no MPLS (not surprising), and no release notes as of 
yet it seems.  No idea of list price either at this stage.


Reuben
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] BGP outbound route-map support for community-lists not working ?

[Reuben Farrelly]

I've been experimenting with a new (and what I thought was improved 
design/modification) in terms of our internal and external BGP routing, 
and I've hit a bit of a snag.


We are largely an end user AS but we do have a couple of eBGP customers 
connecting to us who require AS transit.


Essentially the design I have in mind is like this:

(internet,ebgp) rt1 -- sw1 -- sw2 -- sw3 - sw4 - rt2 (internet,ebgp)

rt1 and rt2 are 2851 ISRs running 15.1(4)M3.  I also have a 7200 running 
the same version of code in another POP.


Between rt1 all the way towards the right, through the switches and to 
rt2 we're running the same AS - but not a full table - just prefixes 
specific to our AS and our customers only.  The two ebgp routers would 
not have a direct iBGP relationship.  There are a whole lot of /28s, 
/29s, /30s etc within iBGP of which most are allocated to end customers 
who do not have their own IP range (the majority of customers).


I'm looking to create a configuration that requires minimal changes if, 
for example, a new customer connects in with their own IP block and more 
importantly, allows maximum flexibility in terms of selecting upstream 
route advertisements.  [In practice we have three upstream facing 
routers, and about another six peers so anything I can do to avoid 
reconfiguring each and every router every time we need a prefix added is 
a big part of the end goal].


The grand big picture plan I had was to use communities to do all the work.

I was looking to tag all of the iBGP generated routes with a community 
of 100:700 and 100:701 (so customer statics and connecteds get a 
different community) and set no-export on them.  They can stay within 
our AS.
I was also looking to install a static route to Null0 for the /21 and a 
couple of /23's at other POPs that our network runs, and tag these with 
the community 100:7 using a route-map combined with a prefix-list.


When a new customer comes along the plan was to add a static route, and 
tag that route with 100:74XX.  Thus we can easily distinguish between 
customer owned and our own internally generated routes.


This all pretty much works as planned.  The addition of communities to 
routes in the inbound direction works as expected.  No problem there.


Now what I was intending to do on the edge of the network facing our 
upstreams (eBGP) is to use the communities that are already set, to 
control what prefixes are advertised to our upstreams, something like this:


1. Routes with 100:100 and 100:101 would be dropped on account of the 
no-export community on those routes (just to be sure).


2. Customer /24 routes all fall within a well defined match of community 
values depending on the POP - 7400-7499.  Easy enough to come up with a 
regex to match...


3. Our /21 and /23's which are null0 holddown routes, are tagged with 
the community 100:7


The problem lies in #2 and #3.

I was expecting this would work:



router bgp 100
<>
 address-family ipv4
  neighbor 10.1.1.1 activate
  neighbor 10.1.1.1 send-community
  neighbor 10.1.1.1 inherit peer-policy UPSTREAM-POLICY
 exit-address-family

 template peer-policy UPSTREAM-POLICY
  route-map POLICY-OUT out
  prefix-list BOGON-PREFIXES in
  remove-private-as
  maximum-prefix 45 98 warning-only
 exit-peer-policy

route-map POLICY-OUT permit 10
 description description Advertise all Customer Subnets Upstream
 match community CUSTOMER-BGP
!
route-map POLICY-OUT permit 20
 description description Advertise Core Subnets (null routes) Upstream
 match community CORE-EXTERNAL-BGP

ip community-list expanded CUSTOMER-BGP permit 100:74..

ip community-list expanded CORE-EXTERNAL-BGP permit 100:7

-

But it seems it doesn't work:

rt1#show ip bgp neighbors 10.1.1.1 advertised-routes
Total number of prefixes 0
rt1#

What am I missing here?

Adding a static route, adding a route map and adding a single entry 
prefix-list to one core router and then everything else working like 
clockwork because of community settings would be ideal :-)


If outbound route-maps cannot be used to match communities for the 
purposes of route advertisements, are there any other mechanisms to 
achieve this goal without "touching" each edge router every time a 
change is required?


Are there any alternatives or tweaks that I could make to this design to 
perhaps even improve it?


Thanks,
Reuben
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] LNS router options

[Reuben Farrelly]

Hi John,

Firstly I wouldn't even bother looking at the 2851 or 3845 now - these 
are the first generation of ISR's and have been superseeded by the ISR 
G2's (2951, 3925 etc).  You'll get perhaps 2-3x the performance of a 
2851 out of a 2951 for much the same money, as well as being able to 
take advantage of future software updates, as it looks like there will 
be no more T releases for the ISR G1's.  Not that you would want to run 
T releases, but the pattern of recent software from Cisco suggests that 
we're not going to see all that many more major releases and hence new 
features for the first generation ISR G1's going forward.


Refer:

http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf

http://www.cisco.com/en/US/prod/collateral/routers/ps5853/qa_c67-631674_ps5854_Products_End-of-Life_Notice.html

Q. What IOS releases will be supported on the Cisco Integrated Services 
Router 1800, 2800, and 3800 Series until End of Software maintenance period?
A. IOS release 15.1(4)M will be the long term IOS release supported on 
the 1800, 2800, and 3800 Series through the end of software maintenance. 
Software maintenance on 15.1(4)M will be offered until Nov. 1, 2014.



I also wouldn't go with the 7200s unless you are purchasing second hand 
- but even then a higher end ISR G2 will likely perform better anyway 
depending on your budget.  It's all about the ASR's now and the 7200s 
are somewhat on the way out (although still very handy to have).


Refer:

http://www.cisco.com/en/US/prod/collateral/routers/ps341/end_of_life_c51-681414.html

Now in terms of practical experience, I have a couple of older 2851s 
maxed out with DRAM taking full BGP tables, some MPLS and terminating 
some DSL services at small POPs, and they cope just fine.  Featurewise 
you will want an ADVIPSERVICES license, but yes the 2800s will happily 
terminate sessions and do all these things without much trouble.  They 
will of course become CPU bound if you have a lot of BGP changes but 
normal Internet feeds aren't going to cause a problem - just be prepared 
for them to get hammered for a few minutes when BGP first connects to 
your upstream and 400k prefixes come pouring down.


100 xDSL tails should be fine on a 2951 unless you have very demanding 
users.  Anything you can of course offload to a Layer 3 switch at your 
POP you should though as these routers are all (largely) software based 
and thus the more load then the more CPU you'll burn up.  So any routing 
you can do on a L3 switch at your POP you should.


When things grow you can just upscale with a new ISR G2 or another IOS 
based device and pretty much keep the config as-is when you move it 
across.  Heck for the price of them nowadays you could just about fit 
out two of them in your POP and have a hot spare for a fairly reasonable 
sum.


Regardless of what you put in, keep an eye on the CPU load, upgrade if 
it starts getting high and you should be fine.


Reuben


On 13/01/2012 3:07 PM, John Elliot wrote:


Thanks Hotmail - Ill resend to accommodate the (lack of)
formatting..

Have a potential new pop that we are looking to terminate dsl
tails(+MPLS,MPBGP, single Inet(full table), and some ethernet tails)
- Have some space restrictions(RU)

Looking for some "real life" experience with the following
platforms(Or alternatives?) on how many dsl tails they can support:

2851 - Cisco stated performance: 220,00PPS (2RU)

2951 - Cisco stated performance: 580,000PPS (2RU) but assume quite
$$?

3845 - Cisco stated performance: 500,00PPS (3RU?)

3925 - Cisco stated performance: 833,000PPS(3RU?) but assume quite
$$?


(NB would max out the ram on them for the bgp table)

Initially we are looking at ~100 dsl tails, with growth to 150 in
6monthsare we better off looking at the old faithful 7200?

___
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] GRE Tunnelling on the ME3600/ME3800 Switches ?

[Reuben Farrelly]

Hi guys

Is GRE tunnelling supported on this platform?

I can see no reference to it in any of the configuration guides - but 
also no reference to it in the unsupported commands section.


Has anyone tried to do this?

We've a need to run GRE tunnels for a URL filtering solution at our Head 
Office from outside the firewall, and policy routing + GRE is the only 
way this can be set up with the upstream vendor.


[Pretty sure policy routing is not supported on this platform yet also 
but confirmation of this would be good as well].


Thanks,
Reuben

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Cisco 2811 performance issue - dual(new) isp

[Reuben Farrelly]

The command:

router#show ip cef switching statistics feature

Will show you which feature is causing traffic to be punted to CPU.

Reuben


On 23/12/2011 7:42 AM, Chuck Church wrote:

You're on the right path.  The more important number is the packets in/out,
as opposed to the characters.  Look at the ratio of packets in/out for
processor vs. Route-cache for the two interfaces.  Fa0/1 is process
switching about 80% of them inbound.  That's pretty bad.The output looks
better.  Compare that to VLAN 10, where in both directions, only about 10%
are process switched.  The stats for the switchports are meaningless, so you
can ignore those as the switch ASICs deal with those, until they hit the
VLAN int.  Figure out what feature (or IOS bug??) is causing so much process
switching, and I think it'll get better.

___
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] ME3600X IOS 15.1(2a)EY1a Code: [Was: Re: Cisco ME3600X and Bridge-Domain Routing config question}

[Reuben Farrelly]

On 15/12/2011 1:58 PM, Mark Tinka wrote:

On Thursday, December 15, 2011 07:33:32 AM Reuben Farrelly wrote:


Yikes.  I don't have this problem in my deployment so far as I have
pushed this job onto edge routers to do this function on all
ingress/egress points to our network.


Are you saying you have egress ACL's applied on dual-stack interfaces
and you're not seeing the issue?


Yes - but not on this platform.  I have the switches within our IGP and 
the edges (both CPE and at the other end - transit+peering) are on IOS 
software based routers which don't have this problem.


So it's likely your problem is actually valid, as our environment isn't 
quite the same.



My requirement has to date been to do this on VLAN interfaces -
maybe I should look into doing this on an EFP on this platform to
see if it's any better.


It certainly is, for us. We don't bother applying QoS on SVI's. Just
physical interfaces or EFP's.


Coming up.  We have outage night tonight where I can be a bit more 
liberal in terms of testing, so I might convert over just one low 
priority connection that I have full control over end to end - which 
should give me some more options to test in the coming days.



:-), for me, it's still better than the Catalyst - I'm happy not to
need 'mls qos' and all the havoc that comes with it like 'srr or wrr
queues', e.t.c.


Oh...I hadn't gotten that far.  In that case I agree - that's the stuff 
that seemed needlessly complex that I was hoping to avoid.



- A wholesale carrier hands off a 1G dot1q trunk port to us - Each
end customer is assigned an individual VLAN on that trunk by the
carrier - We need to be able to rate limit/police (or shape I
guess) all traffic in and out on the specific EVC/VLAN for a
customer to a given contracted amount (tricky if it works at all)


We're doing this today - every child VLAN for the wholesale provider
is an EVC. So you can apply ingress/egress QoS policies on each EVC
which represents a remote child of the wholesale provider.

This is why we don't do this stuff on SVI's :-).


Ok, worth noting.  I'm going to have to start some internal re-education 
about EFP's as this is a new concept for our helpdesk and some of our 
other engineers.  They are far more familiar (as I am) with SVI configs 
as our company had more of a history of integration than SP type work 
and configurations...as a carry over from traditional IOS devices.


Progress on this platform is encouraging though, as long as the code 
keeps moving along and the bugs keep being fixed and releases become 
more frequent.  Goal for me for next year is to be able to remove a 
power hungry half rack height 7613 access router and replace with a 
couple of ME switches, provided the QoS and rate limit stuff gets 
sorted, and we get policy routing support.  I understand it's on the 
roadmap with no ETA, so we'll just have to live in hope.


Thanks for your help and comments Mark - has been useful to share your 
experiences with this platform and learn some new things along the way.


Reuben
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3600X IOS 15.1(2a)EY1a Code: [Was: Re: Cisco ME3600X and Bridge-Domain Routing config question}

[Reuben Farrelly]

On 15/12/2011 10:33 AM, Reuben Farrelly wrote:

- We also need to be able to see and graph interface counters for each
EVC/VLAN for Cacti/Solarwinds (at present this does not work on VLAN
interfaces)

Now:

sw1.qld#show ethernet service instance detail
Service Instance ID: 780
Service Instance Type: static
Associated Interface: GigabitEthernet0/15
Associated EVC:
L2protocol drop
CE-Vlans:
Encapsulation: untagged
Interface Dot1q Tunnel Ethertype: 0x8100
State: Up
EFP Statistics:
Pkts In Bytes In Pkts Out Bytes Out
52516561 14944728475 56861858 28340980592


Bad form to reply to myself but for the record, anyone else who is 
looking for this - EVCs show up as an SNMP pollable interface in their 
own right:


IF-MIB::ifDescr.20507 = STRING: GigabitEthernet0/15.ServiceInstance.780

I've now got nice graphs coming up for traffic in the EVC.

Reuben
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3600X IOS 15.1(2a)EY1a Code: [Was: Re: Cisco ME3600X and Bridge-Domain Routing config question}

[Reuben Farrelly]

On 15/12/2011 4:06 AM, Mark Tinka wrote:

- IPv6 is in, enabled, and it works well carrying 50+
prefixes and OSPFv3 within our AS.  Not a hugely taxing
environment, but IPv6 works.


I tested IPv6 - yes, it's enabled but massively broken:

...

o As much as every bone in my body was saying,
  "What's left is v4 stuff, you can't possibly be
  thinking about that", I decided to remove an
  outbound v4 ACL. And voila! You can imagine how
  wide I had to open my mind to do that :-).


Yikes.  I don't have this problem in my deployment so far as I have 
pushed this job onto edge routers to do this function on all 
ingress/egress points to our network.



- Issues CSCtr83500 and CSCtr83418 are fixed - so hardset
and auto speed/duplex ports is no longer a showstopper.


We do see issues in 12.2(52)EY2 where the Gig-E ports don't
report utilization statistics for the interface. I'm not
running any traffic on any of the Gig-E ports in my lab
right now, so can't tell whether this issue is fixed in the
new code.

Not sure whether you're seeing anything like this. The
10Gbps uplink ports are fine, though, even in the older
code. The issue only affects the Gig-E ports.

I'll get a chance to pump some traffic through and test.


I'm not seeing this, no.

But I have noted that VLAN interfaces do not have accurate counters (on 
any release).  This is unlike my ME6524 and 7600's where I have SNMP 
pollable counters for these interfaces.



As it stands now, I'm glad to see that the issues with QoS
are not hardware related, so far.


For example applying a very basic 10M
inbound and outbound policer on a VLAN interface to rate
limit a customer for example, is not as simple as say, a
software based router.


We normally apply the service policy either on the physical
interface or EVC.


My requirement has to date been to do this on VLAN interfaces - maybe I 
should look into doing this on an EFP on this platform to see if it's 
any better.


I've been able to get away with this functionality on 7200s and 
1800/1900/2800/2900 ISR's and more or less on the 7600 and ME6524 in the 
past:


policy-map police-10M
 class class-default
  police cir 1024 bc 125
   conform-action transmit
   exceed-action drop

On those platforms this allows me to rate limit (in both directions if 
need be) a customer port or VLAN or subinterface to 10M and is 
presumably independent of whether the traffic is IPv4 or IPv6.  The 
point is it's simple and it works.


Trying to apply this on the ME3600X results in:

sw6.nsw(config-if)#service-policy output police-10M
QoS: Invalid target for service-policy
QoS: Configuration errors for policymap police-10M
sw6.nsw(config-if)#
sw6.nsw(config-if)#service-policy input police-10M
QoS: Invalid target for service-policy
QoS: Configuration errors for policymap police-10M
sw6.nsw(config-if)#

The documentation:

http://www.cisco.com/en/US/partner/docs/switches/metro/me3600x_3800x/software/release/15.1_2_ey/configuration/guide/swqos.html

suggests it's not nearly that straightforward to set up, and looks more 
like Catalyst QoS hell :-(




Note:  there are 21 pages of resolved caveats in this
code compared to the original 15.1(2)EY release.  It's
undoubtedly a good thing that problems are being fixed,
however 21 pages of caveats resolved (about 180 bugs)
and IPv6 support appearing is arguably more than a
"minor rebuild" as the version number would indicate,
but sounds rather like some serious fixes have gone on
behind the scenes.


Do you have a link to the release notes? I normally follow
the one in the download section but that one definitely
isn't 21 pages long :-).


http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software/release/15.1_2_ey/release/notes/ol25360.html#wp954239

Additionally the configuration guide now includes a section on 
configuring IPv6.



PS: some key things we're still missing on this box (there's
 more but these are the ones I think the list would find
 more generic across operators):

- v4 and v6 uRPF support.
- EVC SNMP monitoring.
- 4-byte ASN support.
- MC-LAG.


Yep I'm still missing a bit of basic stuff too - picture this:

- A wholesale carrier hands off a 1G dot1q trunk port to us
- Each end customer is assigned an individual VLAN on that trunk by the 
carrier
- We need to be able to rate limit/police (or shape I guess) all traffic 
in and out on the specific EVC/VLAN for a customer to a given contracted 
amount (tricky if it works at all)
- We also need to be able to see and graph interface counters for each 
EVC/VLAN for Cacti/Solarwinds (at present this does not work on VLAN 
interfaces)


Now:

sw1.qld#show ethernet service instance detail
Service Instance ID: 780
Service Instance Type: static
Associated Interface: GigabitEthernet0/15
Associated EVC:
L2protocol drop
CE-Vlans: 


Encapsulation: untagged
Interface Dot1q Tunnel Ethertype: 0x8100
State: Up
EFP Statistics:
   Pk

[c-nsp] ME3600X IOS 15.1(2a)EY1a Code: [Was: Re: Cisco ME3600X and Bridge-Domain Routing config question}

[Reuben Farrelly]

I took the plunge and have now gradually upgraded 5 ME3600X units in 
production to 15.1(2a)EY1a software which was released a couple of weeks 
ago.


So far:

- IPv6 is in, enabled, and it works well carrying 50+ prefixes and 
OSPFv3 within our AS.  Not a hugely taxing environment, but IPv6 works.


- IPv4 OSPF with limited iBGP worked in previous builds and still seems OK.

- Issues CSCtr83500 and CSCtr83418 are fixed - so hardset and auto 
speed/duplex ports is no longer a showstopper.


- Limited MPLS testing shows no issues that I can tell.

- Bridge domain routing restrictions relaxed somewhat are welcome!

- QoS options seem still very much like a Catalyst switch than a router. 
 For example applying a very basic 10M inbound and outbound policer on 
a VLAN interface to rate limit a customer for example, is not as simple 
as say, a software based router.


Note:  there are 21 pages of resolved caveats in this code compared to 
the original 15.1(2)EY release.  It's undoubtedly a good thing that 
problems are being fixed, however 21 pages of caveats resolved (about 
180 bugs) and IPv6 support appearing is arguably more than a "minor 
rebuild" as the version number would indicate, but sounds rather like 
some serious fixes have gone on behind the scenes.


I am hoping the next rebuild release will be in 6 weeks with 30 caveats 
fixed, and not 5 months with 150+ queued up.  ME guys if you are 
listening...more releases with fewer changes is easier to manage and 
deploy and less risky to upgrade in the field than fewer, far between 
drops of code.


Having said that, things are looking good and I'm giving this code a 
thumbs up.  Well worth the upgrade from 12.2(EY)3a.


I'd be interested in hearing any other feedback.

Reuben



On 15/11/2011 2:44 AM, Arie Vayner (avayner) wrote:

I just got a confirmation from the BU, and the restrictions were reduced
with 15.1(2)EY, as it now supports IRB for unicast.
So now the restrictions for 15.1(2)EY are:
*You must configure SVIs for bridge-domain routing.
*The bridge domain must be in the range of 1 to 4094 to match the
supported VLAN range.
*You can use bridge domain routing with only native packets.
*MPLS is not supported.

So basically if you upgrade, it should work.

___
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 ME3600X and Bridge-Domain Routing config question

[Reuben Farrelly]

On 14/11/2011 9:32 PM, Arie Vayner (avayner) wrote:

Reuben,

On the ME3600X you cannot have the same VLAN used as an SVI for Layer 3
bridge-domain on a service-instance, and at the same time also applied
as a regular allowed VLAN on a trunk or as the VLAN of an access port.

Check that VLAN780 is not allowed anywhere on the system (trunks and
access ports), and it is only used as "bridge-domain" on a single
service-instance EFP.


That'll be it.  VLAN 780 is not set on any access ports or used anywhere 
else, but there are a few trunk ports on that switch and some others 
which have no restrictions on which VLANs can pass (eg switch-switch 
within the same POP and rack which are "trusted") such as:


interface GigabitEthernet0/23
 description NETWORK - Link to sw2.qld Gi0/23
 port-type nni
 switchport mode trunk
 mtu 1546
 storm-control broadcast level 2.50 1.50
 storm-control action trap
end

Hrm, it's going to be fun to retrospectively restrict trunk ports on 
both ends all through the network to get around this.  Maybe EVC's just 
isn't going to work for me afterall.


Thanks for the help Arie.  Much appreciated.

Reuben

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] Cisco ME3600X and Bridge-Domain Routing config question

[Reuben Farrelly]

I've recently started to explore the more "interesting" features of the 
ME3600X platform and one of the things I have been looking at is 
starting to provision customers using EVC type configuration, so I can 
do vlan tag remapping and other nice things in the coming months.


Previously I've been just using SVI's and trunk ports - which has worked 
reasonably well, but has some limitations in terms of scalability and 
features.


At the moment I'm starting off small and looking to set up just one 
brand new access ethernet service for a customer for now to test out the 
concept and familiarise myself with the configuration before I look to 
deploy this across the board.  [NB: The service was meant to be ordered 
as a trunk but was incorrectly provisioned and I've been told to get it 
working ASAP, so for the meantime I'm stuck with it being an access 
port, but it is almost certain it will become a trunk service in the 
future and I have other trunk ports I can deploy with].


However I'm clearly missing something here, as the switch just won't let 
me apply the config.


The old configuration which works is:

interface GigabitEthernet0/15
 description CUSTOMER - X
 port-type nni
 switchport access vlan 780
 spanning-tree portfast
!
interface Vlan780
 description CUSTOMER - X
 vrf forwarding CUSTOMER-VRF
 bandwidth 3
 ip address XXX.XXX.96.69 255.255.255.252
 no ip proxy-arp
end

This is all good.

Now here is what I was proposing as the equivalent EVC config:

interface GigabitEthernet0/15
 description CUSTOMER - X
 port-type nni
 switchport trunk allowed vlan none
 switchport mode trunk
 service instance 780 ethernet
  encapsulation untagged
  bridge-domain 780
 !
interface Vlan780
 description CUSTOMER - X
 bandwidth 3
 ip address XXX.XXX.96.69 255.255.255.252
 no ip proxy-arp
end

The interface config applies fine, but the SVI refuses to take an IP 
address:


sw1.qld(config-if)# ip address XXX.XXX.96.69 255.255.255.252
%IP address cannot be configured on bridge domain 780 EFP & Switchports 
or EFPs

sw1.qld(config-if)#

Ok, so let's go to the documentation, clearly I must be doing something 
wrong.


http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software/release/12.2_52_ey/configuration/guide/swevc.pdf



This is an example of configuring bridge-domain routing with a single 
tag EFP:

Switch (config)# interface gigabitethernet0/2
Switch (config)# switchport mode trunk
Switch (config)# switchport trunk allowed vlan none
Switch (config-if)# service instance 1 Ethernet
Switch (config-if-srv)# encapsulation dot1q 10
Switch (config-if-srv)# rewrite ingress tag pop 1 symmetric
Switch (config-if-srv)# bridge-domain 100
Switch (config)# interface vlan 100
Switch (config-if)# ip address 20.1.1.1 255.255.255.255

--

Hmm, not that different to what I was trying, but let's try the example 
from the documentation - changing Gig0/2 to Gi0/5 as Gi0/2 is used on my 
switch:


sw1.qld(config)#default interface gig0/5
Interface GigabitEthernet0/5 set to default configuration
sw1.qld(config)#interface gigabitethernet0/5
sw1.qld(config-if)#switchport mode trunk
sw1.qld(config-if)#switchport trunk allowed vlan none
sw1.qld(config-if)#service instance 1 Ethernet
sw1.qld(config-if-srv)#encapsulation dot1q 10
sw1.qld(config-if-srv)# rewrite ingress tag pop 1 symmetric
sw1.qld(config-if-srv)# bridge-domain 100
sw1.qld(config-if-srv)#interface vlan 100
sw1.qld(config-if)#ip address 20.1.1.1 255.255.255.255
%IP address cannot be configured on bridge domain 100 EFP & Switchports 
or EFPs

sw1.qld(config-if)#

Ok now I'm confused.  The documentation example doesn't work either. 
I'm not too sure where to look next.


What exactly am I doing wrong?

I'm running 12.2(52)EY3a on the switches and I cannot upgrade to 
15.1(2)EY as the units will not link up ports with hardcoded speed and 
duplex (CSCtr83418) and also won't switch IPv6 traffic through the 
switch (CSCtr83500) either, even if configured only for IPv4, so we're 
stuck on the old release until some code comes out which doesn't break 
more than it fixes.  Is this doable in 15.1(2)EY though anyway?


Which reminds me, where -is- 15.1(2)EY rebuild which was planned for 
September, then 30th October, and now it's mid November and it's still 
MIA?  IPv6 anyone?


Reuben



___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] does duplex mismatch affect UDP throughput?

[Reuben Farrelly]

On 2/08/2011 8:45 PM, Mark Tinka wrote:

On Sunday, July 31, 2011 02:47:38 PM Gert Doering wrote:


If you order a cross-city ethernet link from a telco,
they usually force duplex/speed settings on their gear
and turn off autonegotiation.


Funny, we tend to do the opposite these days :-).

I can understand closed networks and enterprise/corporate
networks still going the "hard-coding" route, but it'd be
interesting to learn if a vast majority of service providers
are still doing the same these days (yes, it's still common
to find hard-coding in service provider environments as well
these days, but I just wonder whether the number is falling,
rising or stagnant).

I suspect thoughts on this are bound to be academic :-).

Mark.


Even more odd is that while many enterprises still insist on hard 
setting speed and duplex between network devices (which are typically 
manufactured by vendors in single vendor environments with the best hope 
of it working properly anyway) they frequently don't force the speed and 
duplex on the end node server or non-network ports to match the switch 
port end.  These are not so easy to spot if there are mismatches as most 
servers don't seem to make the counters quite so easily visible as they 
are on switches (where -are- those settings in Windows you may ask?) - 
and by definition fixing the speed and duplex on a switch port means you 
never see *any* collisions or broken frames on that specific end of the 
link anyway.


But back to the Telco question.  Based on my experiences here in 
Australia it isn't changing all that much.  I know that Telstra 
(Wholesale and Retail) and I believe Optus Wholesale here in Australia 
still force these settings this as a matter of operational policy.  That 
covers the majority of telco services offered here.  Most of the smaller 
carriers and ISPs are more flexible with this though and will do 
auto/auto if asked (if not by default).


In my experience as a field engineer the number of duplex problems 
caused by telcos' hard setting these parameters versus autonegotiation 
problems is about 100:1.  Not to mention it also breaks MDI-X... grrr.


We had a fight with Telstra Wholesale over this very thing earlier this 
week. As a background - one of our shiny new ME3600's refused to link up 
on the port at all when it was hard set to 100/FULL (to match Telstra's 
ME3400) on the latest code, but it worked fine at 100/HALF when our port 
was configured as auto/auto**.  Telstra flatly refused to set the port 
on their switch to auto/auto to match ours so that it would work, 
telling us it was "management policy" that it was hard set this way and 
that there is no way they would change it for us.  They have insisted on 
this setting on all of our services including both old and brand new 
installations.


[** And yes, it was a crossover cable, and yes after an IOS downgrade it 
linked up again, but that's a separate matter]


Reuben
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 15.0(SE) 3560 was ME3600X Netflow and WCCP?

[Reuben Farrelly]

Yes.

Besides, IPv6 routing works fine and is done in hardware on the same 
config with 12.2(55)SE3 with no other changes ("desktop IPv4 and IPv6 
routing" template on both).


Reuben


On 28/07/2011 7:10 PM, Michele Bergonzoni wrote:

Il 28/07/2011 9.35, Reuben Farrelly ha scritto:

I've had some quite odd problems with IPv6 with

 > 12.2(58)SE1 ... and two exhibited this

problem whereas two others didn't


Maybe trivial, but: did you check the SDM templates?

Regards,
Bergonz


___
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] 15.0(SE) 3560 was ME3600X Netflow and WCCP?

[Reuben Farrelly]

I've had some quite odd problems with IPv6 with 12.2(58)SE1.  Upon 
loading the image, all IPv4 worked OK, but my IPv6 addresses on 
loopbacks were there, but non functional.  Routes for them were 
propagated throughout OSPFv3 but I wasn't able to ping them from 
anything other than the local router itself where the loopback was 
configured.  But yet I was able to successfully ping and trace to other 
IPv6 addresses on VLAN interfaces on the switch itself.  There was also 
some route looping going on which was evident in traceroutes to the 
loopbacks on those devices which were exhibiting the problem, although 
the (show ip) route tables looked fine.


I wondered if this was some sort of mis-programming or bug within the 
forwarding tables or something...


What's really odd is that I upgraded four units, and two exhibited this 
problem whereas two others didn't.  So it wasn't just a one off, and 
didn't come good by reloading a second time.  The configs were all 
similar, ones that worked were a 3750E, 3560G and one that failed was a 
3560-V2 (the other one that failed I can't recall right now).


After spending an hour trying to work out what was going on and if I 
could work around it, I rolled those two offenders back to 12.2(55)SE3 
and it all came good again.


Given the heap of new features in 12.2(58)SE (some very welcome, 
especially the WCCP ACL deny ability fixed finally) I wasn't overly 
surprised to be finding a few glitches though...


Reuben


On 28/07/2011 4:23 PM, Peter Rathlev wrote:

On Thu, 2011-07-28 at 13:56 +1000, Reuben Farrelly wrote:

Doesn't seem like much difference between 12.2(58)SE and 15.0(1)SE in
terms of either features or bug fixes, so if you've taken the (brave)
plunge and are already running 12.2(58)SE it looks like a fairly minor
upgrade.


Is something special implied in the "(brave)" part? Is there some known
problem with 12.2(58) by any chance? We've started upgrading here and
there and have yet to see any problems.

Or is it just because it's so very new? :-)



___
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] 15.0(SE) 3560 was ME3600X Netflow and WCCP?

[Reuben Farrelly]

Yes:

http://www.cisco.com/en/US/products/ps11781/prod_release_notes_list.html

Doesn't seem like much difference between 12.2(58)SE and 15.0(1)SE in 
terms of either features or bug fixes, so if you've taken the (brave) 
plunge and are already running 12.2(58)SE it looks like a fairly minor 
upgrade.


Reuben


On 28/07/2011 1:13 PM, Daniel Hooper wrote:

Hi,

Can anyone find any release note info in regards to 15.0(SE) on 3560's?

Regards,

Daniel

___
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] ME3600X Netflow and WCCP?

[Reuben Farrelly]

What sort of timeframes are we now looking at for the next release of 
code for the ME3600/3800X's?  There was some talk about new software 
supporting VPLS related features coming out in June, and a bunch of 
15.0(SE) releases has just turned up on CCO for the lower end floor 
switches like the 3560/3750s..


Reuben


On 28/07/2011 9:50 AM, Waris Sagheer (waris) wrote:

ME3600X does not support Netflow and WCCP in the current release.
If the configuration guide does not cover the features then it is not be 
supported.
Netflow and WCCP features are not covered in the configuration guide.

-Waris


-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Colby Glass
Sent: Wednesday, July 27, 2011 4:27 PM
To: Sigurbjörn Birkir Lárusson
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ME3600X Netflow and WCCP?

Thanks guys. Before posting, I noticed that it's listed in the unsupported
commands of an older IOS, but not in the newer one. That gave me some hope.
Though, none of the guides I saw listed anything for configuring WCCP or
Netflow. The feature nav listed WCCP Version 2 though. It's not looking
good.

On Wed, Jul 27, 2011 at 5:59 PM, Sigurbjörn Birkir Lárusson<
sigurbjo...@vodafone.is>  wrote:


I wouldn't trust that, you can configure stuff on the ME3600X that doesn't
actually work (or in fact do anything at all) in practice, you can even
configure stuff that is in the manual, and is supposed to work, but still
doesn't work ;)

I turned on flow on a couple of interfaces, turned on top-talkers and got
nothing.  I then setup netcat to listen to a UDP port, configured export
to send it, and according to show ip flow export it's not exporting
anything.

It also doesn't bode well for the support that ip flow-export is in the
list of unsupported commands in the configuration guide, nor does the fact
that there is only one reference to wccp in the configuration guide and
that's under the traffic-classifier for the CPU traffic...

Kind regards,
Sibbi

Þann 27.7.2011 21:31, skrifaði "Jason Lixfeld":


On 2011-07-27, at 4:45 PM, Colby Glass wrote:


All,

Does anyone happen to know if the ME3600 supports Netflow and WCCP? I
have a
customer considering them for the WAN edge and the docs/feature
navigator
are coming up somewhat ambiguous.


I haven't tested it, but...

systems02.151front71(config)#ip flow-?
flow-aggregation  flow-cacheflow-capture  flow-egress
flow-export   flow-top-talkers

systems02.151front71(config)#ip flow-export ?
  destination  Specify the Destination IP address
  source   Specify the interface for source address
  template Specify the template specific configurations
  version  Specify the version number

systems02.151front71(config)#ip flow-export version ?
  1
  5
  9

systems02.151front71(config)#int g0/1
systems02.151front71(config-if)#no switchport
systems02.151front71(config-if)#ip route-cache ?
  cef Enable Cisco Express Forwarding
  flowEnable Flow fast-switching cache
  policy  Enable fast-switching policy cache for outgoing packets
  same-interface  Enable fast-switching on the same interface
  

systems02.151front71(config-if)#ip wccp ?
  <0-254> Dynamically defined service identifier number
  redirect   Set packet redirection options
  web-cache  Standard web caching service

systems02.151front71(config-if)#

This is on 12.2(52)EY1
___
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] Firewalls "as-a-service" in an MPLS infrastructure...

[Reuben Farrelly]

On 11/07/2011 6:00 PM, Nick Hilliard wrote:

On 09/07/2011 17:22, Derick Winkworth wrote:

The ASA I think can support up to 500 contexts now, but with contexts enabled
I'm hearing there is no crypto support.  I'm not sure this is an impediment for
us but I can see it being an issue for folks.


In multiple context mode, there is no support for:

- dynamic routing
- ipsec
- any sort of VPN
- QoS
- phone proxy
- pppoe

Although multiple contexts are something I'd like to use, their limitations
on ASA are so severe that I don't use them.


+1.  IOS based routers such as an ISRG2, while not having anywhere near 
the throughput, have the swiss army knife appeal of being able to do all 
these as well as all the firewall needs that most customers seem to need 
as long as you watch the CPU load.


And the licensing for multiple concepts is most certainly not cheap 
either, so it's not like you can sacrifice some features on account of 
the cost.  AU$5220 for a 5 context license, (yes I know no-one pays 
RRP), or even at 50% off RRP, it still comes in at about $500 per context.


I wonder how an ASR1k stacks up against an ASA with multi context - 
anyone tried firewalling (such as the ZBFW) on an ASR?


Reuben
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 15.0 train on 7206VXR

[Reuben Farrelly]

Common misconception - IOS 15 didn't introduce enforced licensing, but a 
number of new platforms which ship with 15.X *did*.


It's a platform dependent "feature", primarily on the newer ISR G2s and 
880s/890s.  The original ISR's, 870s, 7200 etc have no such enforcement 
under either 12.4 or 15.X.


Reuben



On 21/06/2011 4:45 PM, LM wrote:

Does the 15.x IOS needs the licenses to work under the 7206VXR?
I am a bit confused.
___
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] 12.2SX vlan-mapping

[Reuben Farrelly]

On 5/04/2011 7:33 PM, Daniel Holme wrote:

On 5 April 2011 09:51, Phil Mayers  wrote:

On 04/05/2011 09:23 AM, Daniel Holme wrote:


Hello folks

Does anybody have any experience of poor performance (very low
throughput limitation) when using vlan-mapping in 12.2SX?

  switchport vlan mapping enable
  switchport vlan mapping 70 770
  switchport vlan mapping 71 771


We've used it with no problems on a fairly well-loaded 6704/10gig port,
under 12.2(33)SXI. We had well over 30 vlans mapped.

What does "poor performance" mean?


Approximately 200kbit/s throughput.


Sounds somewhat like the translation is being punted to software/CPU 
rather than done in hardware.  I was seeing similar figures when I was 
working the CPU hard to do a similar setup, until I figured out the 
right way to configure it on the switch...

I'm using 12.2(33)SXI5 (soon to be SXI6) on an ME6524.

Reuben

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] New Joiner - ME3600X and tools

[Reuben Farrelly]

Hi Per

Can you or anyone else who has access to both the ME3600X and ME3800X 
enlighten as to any of the other differences between these two platforms?
I had come to the view that the ME3600X and ME3800X were practically 
identical apart from some QoS buffer differences, licensing and slight 
variation in TCAM space...but seems there may be more differences than 
just those.


Also, if anyone at Cisco is out there listening, can you also poke 
someone to please get the ME3600|ME3800 added to Feature Navigator?  Not 
that it's the answer to all problems and questions, but being able to 
compare images for the two different platforms is somewhat of a start, 
and useful for potentially what features may be available at FCS, rather 
than customers like us having nasty surprises with what does and doesn't 
work after opening the box (such as IPv6).


Thanks,
Reuben


On 29/03/2011 5:48 PM, Per Carlson wrote:

Hi.


The lack of H-VPLS support although clearly listed on the product page is
also kind of a downer.


VPLS is one of the key differentiators between the ME3800X (which have
it) and ME3600X (which don't).


___
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

[Reuben Farrelly]

Yes this switch is fine for running BGP with the caveat that you won't 
be able to take a full BGP table on this hardware.  I believe the 
hardware TCAM is limited to about 250,000 routes.


You will most certainly want to upgrade that IOS though.  It's years out 
of date.  You should find that the most recent IOS for these units - 
which is 12.2(33)SXI5, should work well.


Reuben


On 12/01/2011 10:50 PM, Mohammad Khalil wrote:


Hi all
I have 2 Cisco ME6524 , i want to deploy them as border routers (i.e. BGP 
routers)The specifications are as below
cisco ME-C6524GT-8S (R7000) processor (revision 1.3) with 458752K/65536K bytes 
of memory.Processor board ID CAT1210C00SR7000 CPU at 300Mhz, Implementation 
0x27, Rev 3.3, 256KB L2, 1024KB L3 CacheLast reset from power-onSuperLAT 
software (copyright 1990 by Meridian Technology Corp).X.25 software, Version 
3.0.0.Bridging software.TN3270 Emulation software.5 Virtual Ethernet/IEEE 802.3 
interfaces32 Gigabit Ethernet/IEEE 802.3 interfaces1915K bytes of non-volatile 
configuration memory.
65536K bytes of Flash internal SIMM (Sector size 256K).Configuration register 
is 0x2102
CR3.KJ-AMM-010#show sup-bootflash: -#- ED type --crc--- -seek-- nlen 
-length- -date/time- name1   .. unknown  7A8AED69 184A0A4   
39 25206820 May 28 2008 01:22:40 +03:00 s6523-advipservicesk9-mz.122-18.ZU2.bin
108224348 bytes available (25206948 bytes used)
is the router suitable ? do i have to upgrade IOS for example?
Thanks
Best Regards,Mohammad Khalil
___
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] full routes / backup router

[Reuben Farrelly]

A 2900 would cope fine with this, for sure.

Just for kicks I ran a full BGP feed to an 1841 one day a few years back 
and after the initial onslaught of populating the routing table it coped 
fine with the incremental BGP updates coming in after that.


Not that I would ever recommend it but

Reuben



On 10/12/2010 4:07 AM, Adam Greene wrote:

Thanks Gert, Joseph and Jorge.

We need to pass the full routing table to a customer who is load
balancing between us and another upstream provider.

As far as data throughput goes, yes, the 2911 looks like a good fit. But
I was concerned about whether the CPU would be able to handle the
frequent BGP updates associated with a full routing table. The
routerperformance.pdf unfortunately does not list the process switching
specs on the 2900's.

The 2911 would be a cold spare, to be used only when the 7204VXR dies.

Thanks,
Adam


On 12/9/2010 2:30 AM, Gert Doering wrote:

Hi,

On Wed, Dec 08, 2010 at 06:30:08PM -0500, Adam Greene wrote:

I need a backup router for a 7206VXR/NPE-400/512MB RAM than can handle
full routes from a single eBGP peer. Router provides transit to an
end-user. Remaining configs on router are minimal, max throughput is
about 30-40Mbps.

What good is "full routes from a single peer"? Just point a default
route there...


Would a 2911/512MB RAM be sufficient? Or is the CPU too puny? Maybe we
need a 3825/521MB RAM? Or I guess we could just get a backup
7206VXR/NPE-400/512MB RAM.

As per the routerperformance.pdf, the 2911 is (regarding packet
forwarding)
nearly as fast as the NPE-400, and the 2921 would be somewhat faster - so
if then NPE-400 is sufficient now, the 2921 should do well as backup.

OTOH, why bother with BGP full tables if all you have is a single peer.

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/

___
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] ME Series for a LAN/Server Farm

[Reuben Farrelly]

On 9/12/2010 10:28 AM, Jeremy Bresley wrote:

On 12/8/2010 1:44 PM, Keegan Holley wrote:

I know from previous conversations that the architecture as well as some of
the defaults for the ME series are different than the traditional switching
platforms. I was curious if there were any reasons why I shouldn't use them
in a "vanilla" switching environment such as a LAN or a server farm. I need
to do fiber aggregation and I haven't been able to find any cisco platform
that will allow me to create an all 1G fiber stack with dual power. I was
curious if anyone had experience using these as just normal switching
platforms.


Options for 1G fiber connectivity with dual power:
3750G-12S with an RPS
4900M with 4/8-port modules and TwinX converters
4500 with WS-X4624-SFP-E or WS-X4448-GB-SFP line cards
6500 with WS-X6724-SFP or WS-X6748-SFP line cards


What about the ME6524 with the SFP instead of copper downlink ports?

http://www.cisco.com/en/US/prod/collateral/switches/ps6568/ps6845/ps6846/prod_bulletin0900aecd80406599.html

It has two PSUs (can operate on 1) and is based on the 6500 and runs 
12.2(33)SXI, but smaller form factor and a bit less expensive ?


We bought one recently and are delighted with it, the only slight annoyance is 
the TCAM size which limits the hardware routing to 256k entries...


Reuben
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] SXI4a or SXI5

[Reuben Farrelly]

Where amongst the new-fangled download manager can we find the latest 
ROMMON's for these cards, and in fact those also for the sup720 on the 7600?


I was off looking for ROMMONs for the sup720 last night, and it seems 
that many of the files for the 7600 are sprinkled amongst the 6500 
software section of the site under LAN switches, which given the split 
between the 6500 and 7600 software, seemed to be a rather 
counterintuitive place to be looking for them.


[Maybe I am looking in the wrong place but whatever the case it seemed 
to be less than obvious quite where to look...]


Reuben


On 15/11/2010 9:23 AM, Pete Lumbis wrote:

Only a guess, but I'd probably say they didn't test new code with old
rommon so they can't guarantee something won't go wrong. I've seen
plenty of times where it will work perfectly fine forever, but if they
never tested it they don't want to make people believe it will work as
advertised.

___
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] CCO Login to ftp.cisco.com hosed [was Re: FYI: SXI5 posted]

[Reuben Farrelly]

On 9/11/2010 7:09 PM, Gert Doering wrote:

Hi,

On Tue, Nov 09, 2010 at 12:34:41AM -, Antonio Soares wrote:

Anyone running SXI5 already ?


I tried to download it yesterday, but the download manager thingie
completely FAILed for me - after klicking about 10 times to tell it
what I want (12.2S ->  12.2SX ->  switches ->  core switches ->  6500 ->...)
it offered 12.4...


+1 here.  I've been "Waiting for www.cisco.com" now for oh, 3 or 4 
minutes perhaps?  After a while their front end proxy responds with:


-

Gateway Timeout
The proxy server did not receive a timely response from the upstream server.
Reference #1.50d1a73b.1289300707.148f3cfe

-

 Should I be logging a P1 TAC case to let them know? 

I find myself constantly in amazement that the world's largest and most 
supposedly resourceful networking company can't seem to have a 
functional reliable website.  The mind just boggles, and this sure isn't 
the first time this has happened.


What's more while waiting for the server farm to work out how to serve 
web pages I've discovered that my FTP access to CCO has now also been 
lost so I can't get in that way either anymore.  I can log in with my 
CCO login just fine but can't get into the /cisco directory to get at 
the images.  Has anyone else recently lost their FTP access or was it 
just me?


ftp> cd cisco
550 /cisco: Permission denied
ftp>

That most definitely used to work.

Why oh why do I get the feeling I am being strangled to death every time 
I try to download software from here...


Reuben
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] Cisco ME6524 VLAN Translation on 12.2(33)SXI5

[Reuben Farrelly]

Hi,

Looking at the release notes for 12.2(33)SXI5 I've noticed that "Vlan 
Translation" is listed as a software restriction on the ME6524 platform.


Does anyone know if this is likely to be ever resolved (noting it's listed as a 
'software' restriction and not 'hardware') ?


Short of crossconnecting two access ports on the switch back-to-back, are there 
any other ways of working around this restriction?


I had ideas about using a bridge-group and two subinterfaces on one of our 7200s 
as a temporary workaround but because they are MPLS enabled, IOS on those tells 
me that IRB/bridging is not supported when MPLS is enabled on the chassis.
Another workaround I'm pondering is if there is a way to use MPLS to "transport" 
the traffic at layer 2 and drop it back out of MPLS into another VLAN, but I 
haven't worked out if or how to do that just yet (or if I need to).


Annoyingly enough, Feature Navigator states that this feature is supported on 
the ME6524 hardware and software so it's a little disconcerting to drill down 
deeper into release notes and find out that maybe it's not actually a goer afterall.


Bug toolkit also yields nothing...

Thanks,
Reuben
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] LNS alternative to 7200?

[Reuben Farrelly]

We are doing just this with a couple of 2851's - MPLS/BGP/OSPF/IPv6/NAT for a 
small POP.  The one 2851 I have in mind is maxed out with 1G third party 
approved DRAM and also runs a full BGP table.  Initially after boot it takes a 
little while to munge the full BGP feed (3 or 4 mins from memory) but after that 
it sits at a few percent CPU idle and happily does whatever else I need.  Max it 
gets up to is about 15% CPU during the day.


The GigE ports support >1500 MTU and MPLS works as expected.  I have about 15 
DSL services coming in over L2TP to it at the moment, I'd be happy to go to 
perhaps 50 or so PPP sessions but after the POP grows past that size I figure we 
can financially justify a much bigger device anyway.


Given the 2900 ISRs are now out I wouldn't bother putting in any more 2851s for 
this purpose - just go the newer 2900 ISRs and be done with it.  For much the 
same $$ you get way way more throughput.  I would be surprised if a 2951 ISR 
won't be sufficient for your needs assuming feature parity with the 2851.


The only point of pain I have with this platform is the per-user QoS via RADIUS, 
which is still broken in 12.4T, 15.0M and 15.1(2)T, but supposedly fixed soon 
(CSCti80776).  It has also been broken on the 7200 platform in 15.0M and later 
12.4T, so if that feature is super critical then you may want to choose 
something which can run old code that is not affected by the bug.


These routers were not designed as an aggregation routers obviously and they 
won't scale to anywhere near a 7200 or ASR, but IOS is IOS and everything we 
need on the platform for this environment just pretty much works.


Reuben


On 15/10/2010 3:19 PM, John Elliot wrote:


Hi,

We have a bunch of 7200's currently terminating dsl tails(Also doing
mpls/vrf's etc) - We are rolling out a new site, and have an initial
requirement(6-12months) to only support ~50 DSL tails, and also have a
limited budget - Are there any alternatives to the 7200's that we can use for
the above tasks? (Maybe a 2800 or 2900?)

___
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] Catalyst 2960 lan-base routing [was Re: BFD on SVI 12.2(55)SE]

[Reuben Farrelly]

Also new in 12.2(55)SE is an SDM profile called "lan-base" routing for the 2960 
and 2960-S models.


You can now do basic Layer 3 switching/routing on the 2960s...no routing 
protocols, only static routes, but still a nice new feature nonetheless.


Reuben



On 17/08/2010 8:45 AM, Raymond Lucas wrote:


Available now on ME switches... surely only a matter of time before it
(re-)appears on other platforms...

Unfortunately no documentation to go with it yet though.

http://www.cisco.com/en/US/docs/switches/metro/catalyst3750m/software/release/12.2_55_se/release/notes/OL23055.html#wp241488

Ray

___
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] Unicast Reverse Path Forwarding - Loose Mode

[Reuben Farrelly]

I've been reading up about uRPF on Cisco's website, at:

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ft_urpf.html

I've heard many people suggest that having uRPF filtering on in an ISP 
environment is a good idea (and best practice).


However I'm grappling with the idea in terms of how effective it might 
be, and if it will solve a specific problem that I have observed recently.


We are a multihomed ISP, and have uplinks to two separate carriers 
taking full BGP feeds as well as multiple peering sessions from other 
parties.  This means that there is some asymmetric routing present - a 
situation which is pretty much unavoidable in this situation.


Now going by the document above, deploying loose mode uRPF on our 
edge/outside interfaces would mean that our border router would be able 
to drop traffic from non routable sources from coming into our network.


Two questions:

1. Given the global routing table is increasing and there is not all 
that much unallocated/non-routed IP networks left (and thus fewer 
invalid source addresses to draw from), is uRPF much of an advantage in 
todays ISP/IPv4 networks?


2. We are also seeing some traffic sourced from IPs within a specific 
/24 subnet inside our AS, entering from outside of our AS.  It is being 
sourced from somewhere on the Internet by some host(s) which are sending 
the traffic out with our source address but are not actually originating 
the traffic from within our AS (which I guess is along the lines of a 
DoS but the traffic volumes are relatively low).  I am dropping this on 
our 7200 via ACLs deployed on the outside edges/interfaces of our 
network.  Could loose mode uRPF help solve this problem?


Thanks,
Reuben


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] www.cisco.com Login Woes

[Reuben Farrelly]

On 2/04/2010 1:44 PM, Mark Tinka wrote:

On Thursday 01 April 2010 11:04:42 pm John Kougoulos wrote:


Have you tried clearing the cookies from *cisco* ?
  usually this works for me...


Yep, no joy.

It's erratic - access to documentation works for the most
part, other times (or other parts) it doesn't.

Access to my login profile, IOS files, e.t.c., is just
crappy, often with this:

"Gateway Timeout


I've had a lot of this happening lately too.  Are people having problems 
using Firefox or IE or other browsers?


(I'm asking because I seem to have a lot of problems with Firefox and 
cisco.com, and I haven't been able to work out why, the same pages that 
give a gateway timeout work fine at the same with IE, so maybe it's an 
encoding problem or something...?)


Reuben
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] ME6524 similarity? [was Re: ME3400 switches - internals?]

[Reuben Farrelly]

Hi,

On 30/03/2010 6:49 PM, Per Carlson wrote:

The ME-series do have much more SP oriented features opposed what
"Desktop Switching Business Unit" ships (e.g. Cat 3xxx).

The ME3750 and ME3400(-nonE) are two (in my opinion) failed attempts.
The ME3750 lacks any decent customer ports (all RJ45), and the ME3400
doesn't have the hardware.


How do these compare with the ME6524 series?

I've been looking at the ME6524s as possible candidates for our small 
service provider core - they seem to be essentially a 6500 in a 1RU form 
factor, and look to bring all the cool useful features of the 6500s into 
a nice and reasonably priced unit.


Are the ME6524s of the same architecture or even closely related to the 
ME3400s?  If they are then going by this thread I'll be thinking 
twice... or is the naming similarity merely the only thing they have in 
common?


Reuben
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Apply service policy via Radius?

[Reuben Farrelly]

What version of IOS code are you running?

Just in case this apples to you, note that the feature "Per-user QoS 
policies applied via RADIUS" is broken in all versions of IOS 15.0, and 
as far as I can tell, many versions of 12.4T including 12.4(15)Tx and 
possibly earlier, on multiple platforms.  Apparently the code is 
"broken" on the 7200 and "the feature is not present" on the ISRs.  I 
reported this bug to TAC and tested on both 7200 and ISR (2851) platforms.


12.4M works OK on both platforms so you might want to try out 12.4(25)c 
on either platform, where the code "exists" and "works".


See CSCte95297 for the gory details.

Reuben


m...@adv.gcomm.com.au wrote:

Hi,

Have DSL users terminating on LNS(7204) via Eth, with radius auth -
Trying to apply the following service policy(Configured on LNS) upon
successful auth:

policy-map JF-2MB-ADSL
class class-default
shape average 185

___
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] IP MTU setting + OSPF

[Reuben Farrelly]

And don't forget - just in case this applies to you:

ip mtu 1500

does NOT apply to IPv6, you'll need to -explicitly- set "ipv6 mtu 1500" as 
well :-)


Reuben
(who recently found this out the hard way with IPv6 OSPF)


On 22/12/2009 7:08 PM, Mikael Abrahamsson wrote:

On Mon, 21 Dec 2009, Chris Wopat wrote:


I'm changing MTU on some 7200s with PA-FE's to 1530 with the "mtu
1530" command on the interface. To get OSPF to neighbor with a 2800
(no user settable MTU), I've put "ip mtu 1500" on the 7200. In my
testing this works fine. Does this in any way prevent the 7200 from
generating an OSPF packet that's larger than 1500 and potentially
breaking things down the road? The following links have been helpful
for MTU descriptions but I'm not seeing the answer to this question in
there.


If you set "ip mtu 1500" then indeed it will not send any IP packets
larger than 1500, and since OSPF runs over IP, this is also affected.

But yes, you're doing the right thing (if the "mtu 1530" command is
because you're running MPLS or something else non-IP that needs a higher
MTU).


___
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] QoS on LNS virtual-template

[Reuben Farrelly]

Hi,

What version of code are you running?

I have found 12.4 mainline worked ok, but somewhere along the 12.4T series and 
including 15.0(M) I cannot apply any QoS policies to Virtual-Access interfaces 
- policies just don't apply.  I have a TAC case open for this now...


Reuben


Clue Store wrote:

Hi All,

I went through the archives and couldn't find specifically what I was
looking for and of course, most of the Cisco links are broken now, but I
noticed that QoS is applied to my virtual-template interface in my config,
but when I do a "show policy-map interface virtual-access xx", I get nothing
as if the policy wasn't inhereted. When I look at my policy-maps, I also
noticed that I do not have parent/child policies configured (which I am to
understand how you have to configure QoS like this on this type of
interface). Here's an example of what I have on our LNS boxes

First question, do I need a child/parent policy to attach the service-policy
to the virtual-template?

Second question, do I need to have the "qos pre-classify" command on the
virtual-template??

Third question, does anyone see anything wrong with the way this is
configured??



class-map match-all VOIP
  match access-group name VoicePorts
  match ip rtp 16384 16383
  match ip dscp ef


policy-map DSL
  class VOIP
   priority percent 75
  class class-default
   fair-queue
   random-detect


interface Virtual-Template2
 mtu 1460
 ip unnumbered Loopback2
 service-policy output DSL
 ip route-cache flow
 ip tcp adjust-mss 1420
 ip policy route-map clear-df
 qos pre-classify
 peer default ip address dhcp
 ppp authentication pap
 ppp ipcp mask 255.255.255.0
 ppp ipcp address accept

ip access-list extended VoicePorts
 permit udp host x.x.x.x range 22026 62025 any
 permit udp host x.x.x.x range 22026 62025 any


TIA,
Clue
___
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] how not to write a release note

[Reuben Farrelly]

Well there's always this one, for a laugh:

CSCso05336
Symptoms: A Cisco 1811 router reloads when trying to connect to irc.freenode.net 
during the first 36 hours following a reload.
Conditions: The symptom is observed only in the first 36 hours following a 
reload. Workaround: Do not connect to irc.freenode.net the first 36 hours 
following a reload.


I thought that was a joke, but it's not..

Reuben


On 17/11/2009 10:11 AM, Jared Mauch wrote:

Seems cisco is getting lazy.. SXI3 is out and this has to be
one of the worst release notes ever:

CSCta14457 - A Cisco device may report alignment errors
 "%ALIGN-3-TRACE" error messages accompanied with a traceback may be reported.

Does not say anything about what may trigger it, eg: mtu,
packet fragmentation, etc..

- Jared



___
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] Recommendations for IOS 12.4T for 7206VXR NPE-G2

[Reuben Farrelly]

I'd suggest you have two choices:

1. Jump straight to 15.0 mainline rather than run 12.4T.  You can of course go 
to 12.4T but as 15.0(1) mainline superseeds and includes bug fixes from 
12.4(24)T it will be the new stable train going forward.
You could say that 15.0(1) is not that well tested, well, 12.4(24)T is still a 
bit rough around some edges too


2. Run 12.4(15)T10 which seems to have been the best stable 12.4T release so 
far.

Reuben



luismi wrote:

Any recommendation?
Technologies used: BGP, EIGRP.VRF, RACL, ACL, uRPF, AAA, GRE.
EtherChannel


___
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] Automatically Synchronize IOS Router Configurations?

[Reuben Farrelly]

On 23/04/2009 1:07 PM, Ian Henderson wrote:

Felix Nkansah wrote on 2009-04-23:


Among other things, their requirement is for their HSRP or GLBP routers
to automatically synchronize their running configurations.


You could avoid the problem entirely, but still meet the objective by using VSS?


How about using the "archive" commands in IOS to remotely copy the config off 
the router every time it was saved, something like this:


archive
 log config
 path tftp://192.168.10.10:/configs/router/router-confg
 write-memory

...and then run a kron (yes Kron not Cron) job on the router to periodically 
copy the config from that tftp location into startup?


Then if you wanted to get especially fancy then have an event manager (EEM) 
script on router 2 which upon detecting that the other router was down, would 
send an email alert off, initiate a reload 60 seconds later and come up with the 
config from router 1 which was in startup-config?  I'd be wary of implementing 
that step without a lot of testing, but it might work for you...


Reuben


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/