[AusNOG] VPLS OSPF question
Matt Perkins
matt at spectrum.com.au
Wed Apr 17 21:56:27 EST 2013
EIGRP just went open BTW pity it's only 10 years to late. Im with Skeeve
here and would stay with one of the myriad that have have been open for
some time.
Matt.
On 17/04/13 9:37 PM, Skeeve Stevens wrote:
> I never recommend EIGRP on the basis I recommend everyone to always
> avoid any vendor specific protocols if it can helped.
>
> When there are protocols in abundance, why do it to yourself?
>
>
>
>
> ...Skeeve
>
> *Skeeve Stevens - *eintellego Networks Pty Ltd
> skeeve at eintellegonetworks.com <mailto:skeeve at eintellegonetworks.com> ;
> www.eintellegonetworks.com <http://www.eintellegonetworks.com/>
>
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>
> facebook.com/eintellegonetworks
> <http://facebook.com/eintellegonetworks> ; linkedin.com/in/skeeve
> <http://linkedin.com/in/skeeve>
>
> twitter.com/networkceoau <http://twitter.com/networkceoau> ; blog:
> www.network-ceo.net <http://www.network-ceo.net/>
>
>
> The Experts Who The Experts Call
>
> Juniper - Cisco - Cloud
>
>
> On Wed, Apr 17, 2013 at 9:32 PM, Tom Berryman
> <tom at connectivityit.com.au <mailto:tom at connectivityit.com.au>> wrote:
>
> Any reason EIGRP doesn't get a look in here? (I will presume
> naively that it's a full Cisco operation- or some brave other
> vendor implements it).
>
> I'd suggest it has an advantage in the simplicity and support stakes.
>
> Tom.
>
> *From:*ausnog-bounces at lists.ausnog.net
> <mailto:ausnog-bounces at lists.ausnog.net>
> [mailto:ausnog-bounces at lists.ausnog.net
> <mailto:ausnog-bounces at lists.ausnog.net>] *On Behalf Of *J Williams
> *Sent:* Wednesday, 17 April 2013 5:39 PM
> *To:* Matt Carter
> *Cc:* ausnog at lists.ausnog.net <mailto:ausnog at lists.ausnog.net>
> *Subject:* Re: [AusNOG] VPLS OSPF question
>
> RSVP could create significant administrative overhead. Are you
> using auto tunnel or automesh, or some scripting?
>
> BBA with PPPoE, nice for hub-and-spoke topology and very ISP-ish. ^_^
>
> Discussed this briefly with my colleague, and come up with following:
>
> BGP with dual RR. Can use BFD where needed for need fast convergence.
>
> If this is an all Cisco shop, then DMVPN.
>
> IS-IS is nice as doesn't rely on IP, but not supported on many low
> end routers.
>
> OSPF is ok, but consider the CPU requirements, especially if using
> IPv6 as well.
>
> Cheers,
>
> Jules
>
> On Wed, Apr 17, 2013 at 10:45 AM, Matt Carter <mattc at mansol.net.au
> <mailto:mattc at mansol.net.au>> wrote:
>
> What about MPLS-TE ?
>
>
> ...Consider BGP has no understanding of interface bandwidth,
> in reality it barely knows anything about where traffic should
> go and hides non-best-path information, passing only along the
> "best route" where advertising a second path forces a
> withdrawl of the first. This is a inherent problem if you want
> flexibility & scale, using an underlying IGP (ISIS/OSPF) and
> something like RSVP allows a full end to end path to be built
> with consideration for the bandwidth & available paths end to
> end, every router has a copy of the TE traffic engineering
> database. (no loops possible.) ...... BGP MEDs on scale don't
> really help much for the pain they impose (anyone?) and you
> tend to find a closest-exit regime anyway.
>
> In short, BGPs ability to manipulate traffic in an MPLS
> environment is limited, it may be great for exchanging edge
> information using multiprotocol extensions offered by BGP, but
> for the core transport you really want to leverage off the TE
> capabilities provided by ISIS or OSPF.
>
> At the very least this lets you adjust your network and
> service offering based on things like throughput and delay,
> bandwidth and paths available in the underlying core network,
> which you simply can't get by doing a simple "virtual-mesh"
> topology using l2 switching vlans / QinQs etc creating
> shortcuts everywhere to make routers appear to be 1 hop from
> each other. There's no/little feedback or dynamic capability
> from the underlying network architecture in that model without
> relying on STP or multiple shortcut vlans, messy messy messy.
>
> My 2c.
>
> *From:*ausnog-bounces at lists.ausnog.net
> <mailto:ausnog-bounces at lists.ausnog.net>
> [mailto:ausnog-bounces at lists.ausnog.net
> <mailto:ausnog-bounces at lists.ausnog.net>] *On Behalf Of *Johann Lo
> *Sent:* Wednesday, 17 April 2013 10:09 AM
> *To:* Tom Storey
>
>
> *Cc:* ausnog at lists.ausnog.net <mailto:ausnog at lists.ausnog.net>
> *Subject:* Re: [AusNOG] VPLS OSPF question
>
> True. I guess I misunderstood your question.
>
> But I'd just K.I.S.S. and split the VPLS into VLANs (one for
> each state etc.) and then run each as an OSPF area. I'd assume
> with a VPLS cloud that size you'd have Q-in-Q.
>
> The real impetus with deploying BGP would be if you want to
> run MPLS and VRFs internally but even then you could get away
> with VLANs and VRF-lite and leak routes via real devices e.g.
> inter VRF aggregation firewalls.
>
> There's also operational overhead, good luck getting any
> decent troubleshooting out of the lower levels before it
> escalates to senior. Ditto with implementations.
>
> I've had a very bad experience with an extremely complex, BGP
> as internal topology network with 27 VRFs and multiple points
> of redistribution, any routing change turned into a CCIE lab.
>
> *From:*Tom Storey [mailto:tom at snnap.net]
> *Sent:* Wednesday, 17 April 2013 9:51 AM
> *To:* Johann Lo
> *Cc:* Mitchell Warden; ausnog at lists.ausnog.net
> <mailto:ausnog at lists.ausnog.net>
> *Subject:* Re: [AusNOG] VPLS OSPF question
>
> Im aware iBGP generally requires an IGP as well, to distribute
> loopback information at a minimum, and that is is generally
> slower to propagate updates than the likes of an IGP - thats
> all 101 stuff.
>
> What I dont get is why this would make BGP any less useful
> internally. I mean, if I had to peer 200 sites across a VPLS
> I'd probably do it with some form of BGP rather than an IGP.
>
> On 17 April 2013 00:05, Johann Lo <Johann.Lo at aptel.com.au
> <mailto:Johann.Lo at aptel.com.au>> wrote:
>
> No, not really.... Why do you think most people run their iBGP
> on top of something else?
>
> Also BGP convergence time is inferior to OSPF/EIGRP/ISIS
>
> *From:*ausnog-bounces at lists.ausnog.net
> <mailto:ausnog-bounces at lists.ausnog.net>
> [mailto:ausnog-bounces at lists.ausnog.net
> <mailto:ausnog-bounces at lists.ausnog.net>] *On Behalf Of *Tom
> Storey
> *Sent:* Wednesday, 17 April 2013 4:40 AM
> *To:* Mitchell Warden
>
>
> *Cc:* ausnog at lists.ausnog.net <mailto:ausnog at lists.ausnog.net>
> *Subject:* Re: [AusNOG] VPLS OSPF question
>
> Whats wrong with using BGP internally. Isnt that what iBGP is for?
>
> On 16 April 2013 10:34, Mitchell Warden <wardenm at wardenm.net
> <mailto:wardenm at wardenm.net>> wrote:
>
> Hi Brad,
>
> Some ideas below. There are a lot of considerations...
>
> OSPF
> - Will run fine on a VPLS service. I've done this with up to
> 30 or so sites in the past and it works well.
> - 200 is a lot of sites - I would try to break it down to
> multiple smaller domains.
> - 50 routers in an area isn't a big deal. It will depend on
> the CPU and the number of updates, but even 200 is unlikely to
> be a problem.
> - 200 neighbour adjacencies however might be a big deal
> (they're all on the same broadcast domain). I think 200 is too
> many.
>
> BGP
> - All of the routers could be in the same subnet so they would
> be able to reach each other directly without an IGP, if you
> build neighbors with interface addresses instead of loopbacks.
> - You would need to use route reflectors to avoid having to
> mesh all 200 routers.
> - I can't think of any reason BGP would reduce available
> bandwidth.
> - BGP isn't really designed to be used internally, and I would
> try to avoid using it that way.
> - BGP is probably better than OSPF if you can't reduce the
> size of the domain. It will be more scalable and probably more
> reliable.
>
> Cheers.
> Mitchell
>
> *Johann Lo*
>
> *Senior IP Network Engineer*
>
> <http://www.aptel.com.au/>
>
>
>
> * Asian Pacific Telecommunications*
>
>
>
> Level 14, 1 Queens Road, Melbourne, Victoria, 3004
>
> *p:* 03 9863 9863 *f:* 03 9863 7701
>
> *e:* Johann.Lo at aptel.com.au <mailto:Johann.Lo at aptel.com.au>
> *w:* www.aptel.com.au <http://www.aptel.com.au>
>
> <http://www.aptel.com.au>
>
>
> ------------------------------------------------------------------------
>
> *Notices*- (1) If it appears that this email has been sent to
> you in error, please delete it (including any attachments)
> immediately and let the sender know by reply email. This email
> may contain confidential information and may be privileged.
> You may be acting unlawfully if you use, disclose, keep or
> rely upon that information. (2) This email and any attachment
> may not be free of viruses or defects. The sender is not
> liable for anything whatsoever including damage, loss and
> liability that you experience because you have received this
> email and notes that you should ensure that your IT system is
> properly safeguarded. (3) If this email is not sent in direct
> connection with the company's business, the company does not
> endorse the content.
>
> *Johann Lo*
>
> *Senior IP Network Engineer*
>
> <http://www.aptel.com.au/>
>
>
>
> * Asian Pacific Telecommunications*
>
>
>
> Level 14, 1 Queens Road, Melbourne, Victoria, 3004
>
> *p:* 03 9863 9863 *f:* 03 9863 7701
>
> *e:* Johann.Lo at aptel.com.au <mailto:Johann.Lo at aptel.com.au>
> *w:* www.aptel.com.au <http://www.aptel.com.au>
>
>
>
> ----- Original Message -----
> From: Brad McGinn
> [mailto:the_xorach at yahoo.com <mailto:the_xorach at yahoo.com>]
> To: ausnog at lists.ausnog.net <mailto:ausnog at lists.ausnog.net>
> [mailto:ausnog at lists.ausnog.net <mailto:ausnog at lists.ausnog.net>]
> Sent: Tue, 16 Apr 2013 17:14:02
> +1000
> Subject: [AusNOG] VPLS OSPF question
>
>
> > Hi AusNog list,
>
> Long time listener, first or second time caller.
>
> I
> > know this list is pretty specific to Service Providers so
> I'm hoping any of
> > you who not only know carrier networks, but also have an
> insight into
> > enterprise networks maybe able to help me to get a view (or
> even help
> > understanding) of the pros and cons of running OSPF or
> BGP across a VPLS
> > network.
>
> I respectfully ask your advice.
>
> I am an enterprise
> > network engineer, not a service provider however I hope you
> don't hold that
> > against me. We run OSPF in our Data Centre and BGP into a
> MPLS network
> > that all of our sites connect into.
>
> My fairly basic understanding of VPLS
> > is kind of like EoMPLS or even one big broadcast
> domain. I assume any
> > IGP could potentially work across it but some factors must
> be taken into
> > consideration: eg flapping sites, latency, reference
> bandwidth, DR/BDR
> > placement, multicast transmission and so on.
>
> So, with that in mind, I'm
> > wondering the following:
> - would it be wise to run an IGP across a
> > VPLS backbone with over 200 sites? or would BGP be better?
> or even something
> > else?
> - if an IGP is the go, would one use OSPF?
> - if OSPF, do
> > you think it would be wiser to run a separate OSPF process
> for the VPLS
> > connected sites and a separate OSPF process for the DC? and
> then
> > redistribute or just summarise right there? (so as to
> protect the DC from
> > OSPF recalculations when sites go up and down)
> - if BGP would be the
> > go I'm wondering how one might go about it.. I know that
> all iBGP
> > neighbours must have a route to the peering IP of all other
> iBGP routers so
> > I would assume an IGP must be run anyway???
> - cisco say that
> > anything more than 50 routers on an area is a bad idea, so
> if I have over
> > 200 sites potentially on the VPLS, will OSPF cut it?
>
> I guess i'm just
> > trying to get my head around the different technology. I'd
> love to keep
> > the stability that BGP brings, but also would like to
> be able to make use
> > of the bandwidth that VPLS gives.
>
> Any hints or tips will be gratefully
> > received and thank you for any help. If you would like to
> keep from
> > cluttering up subscriber's inboxes, please reply offlist.
>
> Again, thanks
> > for any help.
>
> Regards,
>
> Brad David
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net <mailto:AusNOG at lists.ausnog.net>
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
> ***********************************
>
> This email has been scanned by Asian Pacific Telecommunications Hosted Security.
>
> Powered by TrendMicro.
>
> For more information please visitwww.aptel.com.au <http://www.aptel.com.au>
>
> ***********************************
>
> ***********************************
>
> This email has been scanned by Asian Pacific Telecommunications Hosted Security.
>
> Powered by TrendMicro.
>
> For more information please visitwww.aptel.com.au <http://www.aptel.com.au>
>
> ***********************************
>
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net <mailto:AusNOG at lists.ausnog.net>
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net <mailto:AusNOG at lists.ausnog.net>
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
>
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20130417/be991e1d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 11835 bytes
Desc: not available
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20130417/be991e1d/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2969 bytes
Desc: not available
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20130417/be991e1d/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 81748 bytes
Desc: not available
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20130417/be991e1d/attachment-0001.jpe>
More information about the AusNOG
mailing list