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
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 months, as
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
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 sense.
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.
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 these
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 RR
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 scale
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 more along
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
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: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
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 issues with it
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
___
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
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
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, Dec 12, 2013 at 2:01 PM, Mark Tinka mark.ti...@seacom.mu 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
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 I not
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
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
design
Hi, all,
Am 11.12.2013 um 20:16 schrieb Gert Doering g...@greenie.muc.de:
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
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 to all
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 last
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, introducing
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 not
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 network that
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: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 bad
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 not
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's
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 get
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 chasing
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, air
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
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 router
Morning,
Am 09.12.2013 um 16:26 schrieb Mark Tinka mark.ti...@seacom.mu:
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
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
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 this
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 n...@foobar.org:
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
Hi!
Am 10.12.2013 um 10:14 schrieb Mark Tinka mark.ti...@seacom.mu:
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
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 going 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
Hi, Nick,
Am 10.12.2013 um 10:43 schrieb Nick Hilliard n...@foobar.org:
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
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 starters?
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
every
Hi, all,
Am 10.12.2013 um 14:10 schrieb Mark Tinka mark.ti...@seacom.mu:
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
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
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 Nick
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
Hi, all,
Am 10.12.2013 um 13:43 schrieb Justin M. Streiner strei...@cluebyfour.org:
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?
] 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 for the route
Am 10.12.2013 um 18:45 schrieb Patrick M. Hausen hau...@punkt.de:
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
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
Hi,
Am 10.12.2013 um 20:13 schrieb Nick Hilliard n...@foobar.org:
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,
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; Philip
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 while
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
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
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:
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's.
Hi, Lukas,
Am 09.12.2013 um 14:43 schrieb Lukas Tribus luky...@hotmail.com:
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
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.
15S
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 added
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
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 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
vs.
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
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 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 behavior
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
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 works
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
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
74 matches
Mail list logo
