On Thu, Dec 12, 2013 at 2:01 PM, Mark Tinka wrote:
> On Thursday, December 12, 2013 12:06:54 PM Nick Hilliard
> wrote:
>
> > No, no and more no. Total layering violation and
> > abandonment of KISS principal. Not clever.
>
> +1.
>
> Don't know why anyone would run their critical
> infrastructur
On Thursday, December 12, 2013 12:06:54 PM Nick Hilliard
wrote:
> No, no and more no. Total layering violation and
> abandonment of KISS principal. Not clever.
+1.
Don't know why anyone would run their critical
infrastructure on a remote cloud :-).
Mark.
signature.asc
Description: This is
On Thu, 12 Dec 2013, Mark Tinka wrote:
CSR1000v is supported on ESXi only today, and to load it up,
you require vSphere client. I'd rather you didn't, but it's
FWIW - not anymore:
http://www.cisco.com/en/US/docs/routers/csr1000/software/configuration/csroverview.html#wp1081607
I happily r
Hi,
On Thu, Dec 12, 2013 at 11:03:04AM +0100, Adam Vitkovsky wrote:
> I rather meant some proven solution like e.g. Amazon uses to provide cloud
> computing services.
Like, "proven until it falls over"? Not like bits and pieces of the Amazon
(or Azure) cloud hasn't fallen apart with cascading f
On 12/12/2013 10:03, Adam Vitkovsky wrote:
> I rather meant some proven solution like e.g. Amazon uses to provide cloud
> computing services.
No, no and more no. Total layering violation and abandonment of KISS
principal. Not clever.
Nick
___
cisco-
>> My imagination sees "outage in the VM management infrastructure which
>> leads to all RRs being down at the same time, and no network left to
>> bring them back"... *shiver*
>
> Agreed - anyone using the "helpful" automagic stuff like vCentre for
> something like an RR is crazy. We've had iss
On 12/12/2013 09:31, Phil Mayers wrote:
> Agreed - anyone using the "helpful" automagic stuff like vCentre for
> something like an RR is crazy. We've had issues with it exploding and the
> VMs being unmanageable.
Agreed. For network-critical stuff, I wouldn't touch that management crap
with a barg
On Thursday, December 12, 2013 11:50:38 AM Nick Hilliard
wrote:
> + the possibility of genuine oob if you have a separate
> oob infrastructure.
That too, yes.
Three links into each server - 2x links into the core
backbone which is what the router OS will see for IS-IS +
iBGP, and 1x Ethernet
On 12/12/2013 09:44, Mark Tinka wrote:
> All I'm getting from doing this on servers and not routers
> is the CPU and RAM advantage.
+ the possibility of genuine oob if you have a separate oob infrastructure.
Nick
___
cisco-nsp mailing list cisco-nsp@
On Thursday, December 12, 2013 11:08:20 AM Gert Doering
wrote:
> (OTOH using the technologies Mark mentioned, having a VM
> layer makes sense - if the "routing engine" is not
> "software run on top of a general purpose OS" but "a
> routing engine VM running on top of a hypervisor"...
> but then
On Thursday, December 12, 2013 11:04:20 AM Adam Vitkovsky
wrote:
> Or even imagine a pool of these geographically
> distributed with multiple links to core at each site.
> VM-overlay on the pool and run RRs on top of that and
> you'll end up with RRs infrastructure that is never down
> and will s
On 12/12/13 09:08, Gert Doering wrote:
My imagination sees "outage in the VM management infrastructure which leads
to all RRs being down at the same time, and no network left to bring them
back"... *shiver*
Agreed - anyone using the "helpful" automagic stuff like vCentre for
something like an
Hi,
On Thu, Dec 12, 2013 at 10:04:20AM +0100, Adam Vitkovsky wrote:
> > I'll let you know how we go; but yes, all that RAM and CPU that will be
> > available in a 1U server vs. a (decent) router like the ASR1001 or Juniper
>
> > RE-1800X4 is too hard to resist.
>
> Or even imagine a pool of th
> I'll let you know how we go; but yes, all that RAM and CPU that will be
> available in a 1U server vs. a (decent) router like the ASR1001 or Juniper
> RE-1800X4 is too hard to resist.
Or even imagine a pool of these geographically distributed with multiple
links to core at each site.
VM-over
On Thursday, December 12, 2013 10:42:01 AM Adam Vitkovsky
wrote:
> Hi Mark,
> Do you plan on running virtual XR, XE or JUNOS or even
> some customized BGP daemon on those?
> I'm very interested on how it will work out for you.
> I'm all pro for virtualizing BGP control plane, makes so
> much sens
On Thursday, December 12, 2013 10:30:06 AM Adam Vitkovsky
wrote:
> And here I would object that with PIC-Core and PIC-Edge
> BGP is as fast as OSPF/ISIS doing IP FRR.
I have seen extraordinary BGP performance in modern code in
IOS and Junos, particularly in NG-MVPN scenarios where BGP
is handl
> We are looking at deploying dedicated route reflectors on 1U Dell or HP
> servers against inside ESXi or Qemu/KVM hypervisors, mostly to benefit
> from the super quick multi- core CPU's and tons of fast RAM that you just
> don't get in routers.
>
> I'll report back how this goes, in a few month
> There's drawbacks to "customer prefixes in BGP" - and one of them is
> "convergence is slower" plus "more potential for loops while
reconverging"...
And here I would object that with PIC-Core and PIC-Edge BGP is as fast as
OSPF/ISIS doing IP FRR.
adam
__
Hi,
On Wed, Dec 11, 2013 at 11:06:22PM +0200, Mark Tinka wrote:
> On Wednesday, December 11, 2013 10:57:48 PM Gert Doering
> wrote:
>
> > Not unusal to see such thing over here. Both Patrick and
> > I run "mostly datacenter style" ISPs today, with not
> > much change happening on the number of
On Wednesday, December 11, 2013 11:02:40 PM Gert Doering
wrote:
> What's the benefit of adding another layer of problems
> between your hardware and your "routing daemon"?
It's not my style - I'm for bare metal + native OS.
The problem is the routers (which I'll use for route
reflectors) are s
On Wednesday, December 11, 2013 10:57:48 PM Gert Doering
wrote:
> Not unusal to see such thing over here. Both Patrick and
> I run "mostly datacenter style" ISPs today, with not
> much change happening on the number of "router" nodes
> deployed.
>
> We grow, but we grow in power consumption, ai
On Wednesday, December 11, 2013 10:38:00 PM Gert Doering
wrote:
> I did see this. But it was missing in the mail where you
> advocated putting BGP RRs into VMs :-)
It's something I'm moving to.
More CPU. More RAM. More scaling over time without thinking
about it (lazines, again).
Done chasin
Hi,
On Wed, Dec 11, 2013 at 10:49:10PM +0200, Mark Tinka wrote:
> We are looking at deploying dedicated route reflectors on 1U
> Dell or HP servers against inside ESXi or Qemu/KVM
> hypervisors, mostly to benefit from the super quick multi-
> core CPU's and tons of fast RAM that you just don't g
On Wednesday, December 11, 2013 10:55:07 PM Gert Doering
wrote:
> I am *very* lazy, and this is why I don't deploy things I
> know I'm not needing.
>
> And if I have 4 routers and know there won't be more, a
> route reflector is a textbook thing that other people
> can befit from, but for me, it
Hi,
On Wed, Dec 11, 2013 at 10:52:54PM +0200, Mark Tinka wrote:
> But, I'm yet to find a network that doesn't have aspirations
> of growing (and many of the ones I've seen actually do).
Not unusal to see such thing over here. Both Patrick and I run
"mostly datacenter style" ISPs today, with no
On Wednesday, December 11, 2013 09:46:19 PM Patrick M.
Hausen wrote:
> Gee - thanks. That was my gut feeling with the „VM“
> recommendations all along.
I guess the concern is less about a VM and more about what
software is running in there.
Running a route reflector in a hypervisor is not a ba
Hi,
On Wed, Dec 11, 2013 at 10:45:21PM +0200, Mark Tinka wrote:
> While I agree that, perhaps, running your service provider
> network route reflectors on BIRD, Quagga and friends is not
> something I'd go for, deploying route reflectors early on
> (especially when you think you don't need them
On Wednesday, December 11, 2013 09:16:41 PM Gert Doering
wrote:
> I'm not particularily advocating "doing it all without
> BGP", but I do object to "it's in the textbook, thus
> everybody needs to do it that way!".
I'm certainly anti "it's in the book, so drink it".
But, I'm yet to find a netwo
On Wednesday, December 11, 2013 09:01:56 PM Nick Hilliard
wrote:
> Mostly no argument there when everything is running
> smoothly, but from a design perspective, it is a lot
> cleaner to handle this stuff in ibgp. You get a bunch
> of advantages, including stuff like continuous edge link
> flaps
On Wednesday, December 11, 2013 08:12:44 PM Gert Doering
wrote:
> I don't think I'd ever recommend that, except to a
> competitor.
>
> Having a few 100 external(!) LSAs in an IGP won't make
> any of them sweat, not even a stone-age cisco IOS 11.0
> OSPF implementation on a 2500.
>
> OTOH, intr
Hi,
On Wed, Dec 11, 2013 at 08:36:04PM +, Nick Hilliard wrote:
> On 11/12/2013 19:16, Gert Doering wrote:
> > I'm not particularily advocating "doing it all without BGP", but I do
> > object to "it's in the textbook, thus everybody needs to do it that way!".
>
> note the first sentence of my
On 11/12/2013 19:16, Gert Doering wrote:
> I'm not particularily advocating "doing it all without BGP", but I do
> object to "it's in the textbook, thus everybody needs to do it that way!".
note the first sentence of my last email:
> I'll be the first to admit that not all this stuff is relevant
Hi, all,
Am 11.12.2013 um 20:16 schrieb Gert Doering :
> Of course, if your network spans multiple 100s of routers, and 10.000s
> of customer connections, there is no alternative - but for a network with
> single-digit routers, and below 100 LSAs, "operational simplicity" wins,
> and I am fully co
Hi,
On Wed, Dec 11, 2013 at 07:01:56PM +, Nick Hilliard wrote:
> > Having a few 100 external(!) LSAs in an IGP won't make any of them sweat,
> > not even a stone-age cisco IOS 11.0 OSPF implementation on a 2500.
>
> Mostly no argument there when everything is running smoothly, but from a
> de
On 11/12/2013 18:12, Gert Doering wrote:
> I don't think I'd ever recommend that, except to a competitor.
I'll be the first to admit that not all this stuff is relevant to all
networks. E.g. for INEX transit ASN / as2128, I use full mesh between the
various bgp boxes and no communities because th
Hi,
On Tue, Dec 10, 2013 at 09:43:28AM +, Nick Hilliard wrote:
> On 10/12/2013 09:31, Patrick M. Hausen wrote:
> > How can I connect them to the iBGP without them carrying full tables?
> > Route-maps for the neighbor definitions? Is that really all it takes?
> >
> > And OTOH again - why would
So I spoke to Philip and he is happy to share his slides
with the public.
His FTP site is here:
http://thyme.apnic.net/ftp/isp-workshops
The slides you are interested in for IS-IS are under:
- Routing Presentations
For BGP, that would be under:
- BGP Presentations
Go
On Tuesday, December 10, 2013 09:13:14 PM Nick Hilliard
wrote:
> they would probably be very good for the job on a small
> network, yes.
The 3825 should be good. With 1GB RAM, it could skate by
with two full tables and decent CPU utilization. I'm not
sure it will handle more than that.
If you
On Tuesday, December 10, 2013 09:27:26 PM Patrick M. Hausen
wrote:
> - when all old systems and OSPF are retired, add
> route-reflector and iBGP (with a conveniently larger
> administrative distance than IS-IS by default) - narrow
> IS-IS to just the backbone links one external link at a
> time w
On Tuesday, December 10, 2013 07:25:27 PM Steve Housego
wrote:
> Are there any good resources that detail best current
> practice for route reflector design?
>
> Google doesn't bring up much real-world experience, i.e.
> detailing caveats, redundancy options etc..
I only teach the slides; Phili
Hi,
Am 10.12.2013 um 20:13 schrieb Nick Hilliard :
> On 10/12/2013 18:28, Patrick M. Hausen wrote:
>> Can an IOS router serve as a route reflector? Once I have the C6500 in
>> production I have two spare 3825 that feature 1 GB of RAM each and
>> should thus have suficcient resources, specifically
On 10/12/2013 18:28, Patrick M. Hausen wrote:
> Can an IOS router serve as a route reflector? Once I have the C6500 in
> production I have two spare 3825 that feature 1 GB of RAM each and
> should thus have suficcient resources, specifically when they are not
> busy routing traffic, anymore.
they
Am 10.12.2013 um 18:45 schrieb Patrick M. Hausen :
> I see. I’m starting with 4 routers and I simply do not have the hardware
> at hand *now* to implement something that critical to my network.
> Of course a VM will do, but I do not have free virtual ressources with
> sufficient redundancy, either.
t] On Behalf Of Justin
M. Streiner
Sent: 10 December 2013 12:44
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] C6500 IPv6 redistribute with route-map?
On 10/Dec/2013 at 09:22:01 AM, Patrick M. Hausen wrote:
> I do have the knowledge and capacity to implement iBGP as my IGP
> *now*, except fo
Hi, all,
Am 10.12.2013 um 13:43 schrieb Justin M. Streiner :
> On 10/Dec/2013 at 09:22:01 AM, Patrick M. Hausen wrote:
>> I do have the knowledge and capacity to implement iBGP as my IGP
>> *now*, except for the route reflectors suggested. Would you recommend
>> that approach? I.e. going without
On 10/Dec/2013 at 09:22:01 AM, Patrick M. Hausen wrote:
I do have the knowledge and capacity to implement iBGP as my IGP
*now*, except for the route reflectors suggested. Would you recommend
that approach? I.e. going without the route reflectors and the
communities first? It~Rs only 4-5 machines
On Tuesday, December 10, 2013 04:27:48 PM Nick Hilliard
wrote:
> It would be less work overall to install the RRs first.
> It's not that difficult either. Just remember to use
> next-hop self for all ibgp sessions. Otherwise see Phil
> Smith's BGP 101 presentation that Mark mentioned.
What Ni
On 10/12/2013 14:22, Patrick M. Hausen wrote:
> I do have the knowledge and capacity to implement iBGP as my IGP *now*,
> except for the route reflectors suggested. Would you recommend that
> approach? I.e. going without the route reflectors and the communities
> first? It’s only 4-5 machines in t
Hi, all,
Am 10.12.2013 um 14:10 schrieb Mark Tinka :
> On Tuesday, December 10, 2013 11:31:55 AM Patrick M. Hausen
> wrote:
>> And OTOH again - why would I not want to carry < 100 LSAs
>> in my IGP?
>
> Because you should always assume you will grow. Having to
> re-design the network in the fut
On Tuesday, December 10, 2013 11:41:10 AM Patrick M. Hausen
wrote:
> Most ISPs I know who run OSPF configure it the way I
> described with very narrow „network“ statements and
> explicit redistribution. Essentially my subscriber lines
> are from the IGP’s point of view not part of my AS and
> eve
On Tuesday, December 10, 2013 11:31:55 AM Patrick M. Hausen
wrote:
> I must admit, the thought never occured to me up until
> now. That’s what I thought IGPs were for. Use BGP to
> talk to your upstream, use a suitable link state IGP for
> your own network.
>
> Any hints/documents/links for star
Hi, Nick,
Am 10.12.2013 um 10:43 schrieb Nick Hilliard :
> On 10/12/2013 09:31, Patrick M. Hausen wrote:
>> How can I connect them to the iBGP without them carrying full tables?
>> Route-maps for the neighbor definitions? Is that really all it takes?
>>
>> And OTOH again - why would I not want to
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 interna
On 10/12/2013 09:31, Patrick M. Hausen wrote:
> How can I connect them to the iBGP without them carrying full tables?
> Route-maps for the neighbor definitions? Is that really all it takes?
>
> And OTOH again - why would I not want to carry < 100 LSAs in my IGP?
if it's 100 LSAs, there's not goin
Hi!
Am 10.12.2013 um 10:14 schrieb Mark Tinka :
> "passive-interface" in IS-IS basically means:
>
> - If an interface is defined as passive.
> - Advertise whatever IP address is on it.
> - But don't run IS-IS on it.
Yep. That sums it up quite nicely, which is why I’m citing it
Hi,
looks like I opened quite a can of worms, here … :-)
Thanks to everybody for the valuable input.
Am 10.12.2013 um 10:19 schrieb Nick Hilliard :
> On 10/12/2013 08:42, Patrick M. Hausen wrote:
>> I’ve been doing OSPF for quite some years and IMHO this is a perfectly valid
>> and
>> sane way t
On 10/12/2013 08:42, Patrick M. Hausen wrote:
> I’ve been doing OSPF for quite some years and IMHO this is a perfectly valid
> and
> sane way to run an ISP with subscriber lines. And I know more than one
> competitor
> (friendly competition ;-) doing exactly the same.
Why don't you use ibgp for
On Tuesday, December 10, 2013 10:42:34 AM Patrick M. Hausen
wrote:
> This enables OSPF on the link to my other router *only*.
> OSPF does not by default redistribute connected or
> static routes. The 0.0.0.0 looks insane but keep in mind
> that it’s an inverted (wildcard) mask so essentially it
>
Morning,
Am 09.12.2013 um 16:26 schrieb Mark Tinka :
> On Monday, December 09, 2013 03:05:17 PM Patrick M. Hausen
> wrote:
>
>> Just to make sure i would not accidentally inject
>> anything not belonging to my AS into my IGP.
>
> Why would you, if you're running IS-IS only on your internal
> l
On 09.12.2013 17:55, Patrick M. Hausen wrote:
> Didn’t IOS 15 introduce a completely new and rather burdensome licensing
> mechanism?
> http://etherealmind.com/ios-15-licensing-how-we-work/
Well thing is, that they did have plans and even implement this on their
low-end hardware like ISR routers
Hi,
On Mon, Dec 09, 2013 at 05:26:31PM +0200, Mark Tinka wrote:
> That said, I always teach that loop avoidance in IGP's is
> possible due to a consistent view of the IGP state by all
> routers participating in the IGP. Filtering, of any kind,
> breaks that, and that is why the IGP's aren't con
On Monday, December 09, 2013 05:42:04 PM Phil Mayers wrote:
> We use BGP for this ;o)
>
> exaBGP seems like a good fit for "monitor port 53 and
> advertise a route", though we rolled our own locally.
This is internal to our backbone, and not spread across
different networks per se. So an IGP wo
On 09/12/13 15:30, Mark Tinka wrote:
2. Anycast DNS, because IS-IS in Quagga is unusable.
We use BGP for this ;o)
exaBGP seems like a good fit for "monitor port 53 and advertise a
route", though we rolled our own locally.
___
cisco-nsp mai
On Monday, December 09, 2013 04:15:47 PM Nick Hilliard
wrote:
> On 09/12/2013 13:43, Lukas Tribus wrote:
> > Perhaps, the network is redistributed by another
> > mechanism and you are looking at the problem from the
> > wrong angle. For that matter: passive-interface in
> > ISIS has a different be
On Monday, December 09, 2013 03:55:07 PM Patrick M. Hausen
wrote:
> But I do want to redistribute all connected subnets into
> IS-IS. I just want to prevent addresses that do not
> belong to me from entering the IGP.
So don't run IS-IS on them, or passive-interface.
Just use BGP next-hop-self,
On Monday, December 09, 2013 03:43:08 PM Lukas Tribus wrote:
> Personally I exclusively use prefix-lists in route-maps
> related to routing protocols; I hate representing
> prefixes in ACL's. I understand that this doesn't fix
> the problem, but it may be something to look into to
> simplify the c
On Monday, December 09, 2013 03:05:17 PM Patrick M. Hausen
wrote:
> Just to make sure i would not accidentally inject
> anything not belonging to my AS into my IGP.
Why would you, if you're running IS-IS only on your internal
links?
> I do not intend to discuss the respective merits of OSPF
>
On 09/12/13 14:47, Phil Mayers wrote:
On 09/12/13 13:55, Patrick M. Hausen wrote:
Didn’t IOS 15 introduce a completely new and rather burdensome
licensing mechanism?
No.
(damn it sorry, ctrl+enter)
That should have been "No, not on 6500", but Gert has already replied in
sufficient detail
On 09/12/13 13:55, Patrick M. Hausen wrote:
Didn’t IOS 15 introduce a completely new and rather burdensome licensing
mechanism?
No.
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at h
On 09/12/2013 13:43, Lukas Tribus wrote:
> Perhaps, the network is redistributed by another mechanism and you are
> looking at
> the problem from the wrong angle. For that matter: passive-interface in ISIS
> has
> a different behavior than in OSPF.
support for ipv6 advertise passive-only was add
Hi,
On Mon, Dec 09, 2013 at 02:55:07PM +0100, Patrick M. Hausen wrote:
> Didn?t IOS 15 introduce a completely new and rather burdensome licensing
> mechanism?
> http://etherealmind.com/ios-15-licensing-how-we-work/
>
> If that article get?s it correctly, I?d rather avoid 15 as long as possible.
Hi, Lukas,
Am 09.12.2013 um 14:43 schrieb Lukas Tribus :
> Well, why don't you try to remove the redistribution completely:
> > no redistribute connected route-map redistribute
But I do want to redistribute all connected subnets into IS-IS. I just want
to prevent addresses that do not belong to
Hi!
> I first suspected my lack experience with v6 access-lists and tried various
> permutations of source/destination. Then prefix- instead of access-lists -
> to no avail.
Personally I exclusively use prefix-lists in route-maps related to routing
protocols; I hate representing prefixes in ACL'
Hi, all,
I’m in search of a little help with the setup of our new core routers. I’ve been
running AS16188 and an internal v4 network for quite some years, so most
tasks introducing v6 should be a piece of cake - or so I thought ;-)
I’ve run a setup like this since I do not remember when:
> route
74 matches
Mail list logo
