Re: [c-nsp] OT: Enterprise (Not ISP) Maintenance Windows
[yeah, OT and should be on NANOG or similar, but this will more likely get you real answers, sadly.] On Fri, Sep 26, 2014 at 02:42:56PM -0700, Scott Voll wrote: > For those of you working in an enterprise, company, agency, etc. Do you > have a standard (network) maintenance windows? > > If so, when? How often? Can you schedule anything in it, or if it will > cause an outage does it need to go through 3+ layers of meetings and buy > off to get it approved before you can schedule it? > > I'm just trying to understand what the norm is, "in the real world". The norm is what works for your business, period. "ISP maintenance windows" are the same: hint, if they aren't doing it in their usage trough, someone has elevatated process/tradition over sanity. I've wotked with emnterprises that have ranged from ad-hoc, scheduled based on weekly meetings, rigid twice weekly, etc. In general, work will pile up so I lean to no less than once a week. More important bits IMO are: - don't paint yourself into the corner that eliminates automated processes. - be clear about what can/can't be done in your windows; do you need 'non-disruptive' versus 'disruptive' windows to cover code upgrades? - have clear actions/test/rollback - where not automatically generated, use a peer review process Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG ___ 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] Loopback IP set to .255 - 6500 responds to ICMP echo-request from wrong interface
On Sat, Dec 31, 2011 at 09:33:19PM -0800, Eric Rosenberry wrote: > I am scratching my head here wondering if I have run into a Cisco bug, or > somehow intended weird behavior... Bug. I encountered less of them with foo.0/32 than foo.255/32, but an uphill battle to them to DTRT. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG ___ 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] Current BGP BCP for anchoring and announcing local prefixes
On Mon, Mar 15, 2010 at 01:08:03PM -0400, Jason Lixfeld wrote: > I've been in the habit of using communities to anchor and announce > prefixes into BGP for years and I think my ways are somewhat dated. > I'm looking for a bit of a refresh. Wondering if anyone here has > any thoughts ;) [snip] Nothing above hinges on network or aggregate-address statements. For covering prefixes redist static through a route-map, apply your communities and job done. You should also only carry your links, loopbacks, and eddges in your IGP - yarger prefixes should just be in your iBGP mesh. The real decision in where you anchor the larger prefixes, and that depends on you external connecttivity layout, prefix-stability goals, etc. Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE ___ 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] Which IP's belong to AS1234?
On Fri, Sep 25, 2009 at 06:12:22PM +1000, Andy Saykao wrote: > Thanks for the reply guys. > > What I'm trying to achieve is to monitor the bandwidth utilization on > our Internet link. So for example we want to know how much bandwidth is > being utilized by our customers so we can say "ah huh out of our 100M > internet link, 90M of traffic is from youtube.com, so let's ask Google > if they want to peer with us". Ah, who is using/announcince rather than any sense of "ownership". You want to look at the various *flow tools and platforms. Since this is a cisco list and you presumable have cisco kit, look into netflow. For education, check into sflow, jflow, etc. For any useful data, you'd need to have a BGP table containing all the prefixes you care about. Be aware that configuration for destination AS (as opposed to immediate neighbor AS) will still require post- processing to be aggregated in any meaningful manner. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE ___ 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] OSPF to ISIS migartion
On Wed, Sep 23, 2009 at 05:49:32AM -0400, William F. Maton Sotomayor wrote: > On Wed, 23 Sep 2009, jack daniels wrote: > > >Hi all , > >I have got a project for an ISP ( also LDP configured ) runnning OSPF to > >migrate to IS-IS. > >I was planning to runnn dual IGP , as ospf with AD 110 and ISIS with AD 115 > >, OSPF will always be preffered. > >I was planning the challenges for migration, below are the ones which I > >could think of , please give your inputs on WHAT CONSIDERATIONS TO KEEP IN > >MIND BEFORE MIGRATION. > >Also request you to share some docs for migration of OSPF to ISIS< If you are worried about memory, you should re-examine what is in your IGP. See also the isis design guide, section 4 "Migration". -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE ___ 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] eBGP --> OSPF --> eBGP vs eBGP --> iBGP --> eBGP
On Mon, Apr 27, 2009 at 02:05:17PM -0400, Adam Greene wrote: > Hi, > > We run BGP to our upstream providers and OSPF on our local backbone. > > We have a customer who will be multihomed and needs us to advertise his IP > blocks to us via BGP. > > My question is how best to propagate his AS-PATH prepending to > my upstream providers. Is it possible to inject this information > into OSPF and then into the eBGP to my upstreams? Possible yes, but full of fail. > Or should I plan on establishing iBGP sessions between the backbone > router that will be servicing the customer and the routers facing > my upstream providers? I assume the latter Yes. For maximal win along the axes (scalable,flexible,maintainable), your OSPF should only carry only loopbacks and network edges (just enough to enable next-hop processing of BGP) and your iBGP should carry all the prefixes. Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE ___ 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 across continents
On Tue, Apr 07, 2009 at 03:22:04PM +0100, Alasdair McWilliam wrote: [snip] > Is there any way around this or is the only option to request a second ASN? Among the "give you enough rope" options, "neighbor allowas-in"; use with caution. There are many other options, including to build tunnels between the sites and treat them as a logical single entity. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE ___ 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] 3/11 (invalid or corrupt AS path)
On Mon, Feb 16, 2009 at 06:14:08PM +0100, Grzegorz Janoszka wrote: > Ozar wrote: > >I am starting to see random BGP neighbor messages from multiple neighbors > >on > >different boxes. > > > >%BGP-3-NOTIFICATION: received from neighbor X.X.X.X 3/11 (invalid or > >corrupt > >AS path) 516 bytes [snip] > No, it is not software error, it is extremly long as-path: The message itself, correct. The flapping sessions observed on some code, the long path is indeed triggering some bug. It is immaterial if it is the revival of an ld bug or a new one, there are folks flapping over this (and related) paths. Providers without some level of sanity filters (really need many-multiples the current diameter of the net?) should be shamed into limiting their customer's prepends. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE ___ 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] Per packet load balancing with low latency applications
On Thu, Jan 15, 2009 at 12:25:18PM +, William wrote: > Hello list, > > I've been looking at using per packet load balancing with a couple of > serial links to use with a low latency market data application, in all > the cisco docs they seem to mention how VoIP/Video applications may > chuck their dummy out with packets arriving out of sequence. My > question is what would cause the packets to arrive out of sequence? > And has anyone been in my position before? what was the outcome? If these are wide-area links, latecy can vary due to grooming or other re-provisioning. If they are protected links, expect at some point during their life to switch ntependently and wind up with differing latencies. > Per packet is going to be used because there will only be one machine > on each end of the link talking to each other. Look at link-layer aggregation methods (mlpp for ptp, LAG for ether, etc) or getting a bigger pipe instead. Simple is good. > Any more information/real life experiences on the matter are welcome. In my experience, per-packet always kills goodput. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE ___ 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 route flap damping
On Tue, Oct 07, 2008 at 12:58:59PM +0200, Pelle wrote: > Hi. > > I don't have an answer to your question, but a thought about dampening. > > > In theory, it's supposed to work, but thought it might be better to > > ask for advice and things to watch out for before deploying in the > > real world. > > BGP dampening is no longer regarded as "a good thing", but something > to turn off. In fact the Cisco BCP is to disable dampening. ...precisely because the implementation dampens *all* paths for a prefix, not just the flapping path. Given an implementation which dampens just the flapping path[s] for a prefix, then the originally- intended result would occur and only penalize the misbehaving paths. The other concerns pale in comparison, and would easily be mitigated in the case of corrected implementations. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE ___ 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] OT: network inventory
On Tue, Aug 19, 2008 at 09:04:29AM -0400, Adam Greene wrote: > Besides documenting config changes, can rancid perform a tftp backup of > router / switch startup configs, or integrate with some other software to > pull down the config file if a change is detected? Lots of folks trigger rancid runs on snmp traps or syslog events. Best IMO is to front-end your changes thru rancid & have that wrapper log/trigger runs/etc to your heart's content. Only the long list of 'round tuits' is to recreate all the good ol rtrmon suite actions as rancid wrappers. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE ___ 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.2SXH 'archive' / Configuration Management
On Sun, Jun 08, 2008 at 04:38:23PM +0100, Simon Lockhart wrote: > On Sun Jun 08, 2008 at 04:14:33PM +0100, Alex Howells wrote: > > That template makes fairly extensive use of the 'archive' command but > > some older IOS doesn't include that functionality; I've also seen/heard > > RANCID being deployed and would like something which "Just works". > > RANCID "just works". Won't catch *every* change, as it's a polling based > system, but I've never had a problem with it. For those who wish to trigger a RANCID run for every change, SEC-based syslog triggers are easy (provided your syslog & rancid hosts can talk!) and I know some folks trigger based on snmp traps (again, assuming the traphost and rancid host can talk). A visit to [EMAIL PROTECTED] might be in order to go further down that route. :-) Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE ___ 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] Route Optimization/Control Options?
On Tue, May 13, 2008 at 04:16:16PM -0400, David Prall wrote: [snip] > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Shaun R. > > Sent: Tuesday, May 13, 2008 3:51 PM > > To: cisco-nsp@puck.nether.net > > Subject: [c-nsp] Route Optimization/Control Options? > > > > Looking for recommendations on route optimization > > software/appliances that > > are out there. Currently i have two upstream connections and > > i'm just using > > a a basic bgp setup to route traffic out. I would like > > somthing that does > > realtime monitoring and manipulates traffic based on network > > performance > > down each provider. Anybody recommend anything thats a decient price. Recall that only your outbound traffic is under your control. The only control regarding inbound traffic is the presence or abscence of your prefixes. Prepends won't override a remote autonomous system's decisions at their cost, performance, or other metrics. Your directly-neighboring providers may support ccommunities to influence the traffic on their network & their borders, but expect your guarenteed influence to flow only as far as your dollars. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE ___ 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] VLSM <-> Cisco ACL <-> Extended ACL format table?
On Sun, Dec 23, 2007 at 03:55:34PM +0200, Hank Nussbacher wrote: > At 08:15 AM 23-12-07 -0500, Eric Van Tol wrote: > > Thanks. I might HTML later this week unless someone else has it online > someplace. An old one of mine is up at http://www.gweep.net/~crimson/networks/netblocks.html ...or you can just use aggis. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE ___ 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] per-packet load sharing.
On Sun, Dec 09, 2007 at 05:39:07PM -0800, virendra rode // wrote: [snip] > In order to distribute traffic (load-sharing) across two links I'm > looking at enabling equal cost traffic (per-packet load sharing) going > out both serial links as their data processing is overloading one link. > The equal cost routes with CEF default load sharing is not distributing > the load over the 2 links as expected. MLPPP is not an option for > budget reasons hence I'm looking at doing per-packet. [snip] > Any recommendation and /or feedback will be appreciated. ECMP in routing protocols good, per-packet bad. If you care at all about TCP performance or have jitter-sensitive traffic then don't do it. Your best bet is to suss out how much BGP you can eat on the platform, get that data and (backfill with 0/0 if you are on a limited platform), then slice and dice your load at that level. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE ___ 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] Network Topology Mapping
>From joe and stephen's nanog tutorial (http://www.nanog.org/mtg-0210/abley.html): ftp://ftp.isc.org/isc/toolmakers/mktop.tar.gz ftp://ftp.isc.org/isc/toolmakers/top2dot.tar.gz I'm a big fan of forcing provisioning/operational acceptance through the same system that creates/is part of your monitoring, management, documentation, etc. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] MTU settings/GRE tunnel
On Thu, Sep 20, 2007 at 03:51:00PM +0800, Nick Kraal wrote: [snip] You didn't indicate what types of devices, and specifically the media. A very good design rule for generally reducing any encapsulation problems is to be sure that your WAN links are running significantly higher MTU than your (LAN, client, source/sink, etc) links; a good argument for applying jumbos on GE used as backbone/WAN/metro... CHeers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE ___ 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/
