[AusNOG] VPLS OSPF question

Tom Berryman tom at connectivityit.com.au
Wed Apr 17 21:32:28 EST 2013


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] On Behalf Of J Williams
Sent: Wednesday, 17 April 2013 5:39 PM
To: Matt Carter
Cc: 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



[cid:image001.jpg at 01CE3BB2.DD006090]<http://www.aptel.com.au/>

    Asian Pacific Telecommunications

[cid:image002.gif at 01CE3BB2.DD006090]

   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>



  [cid:image003.jpg at 01CE3BB2.DD006090] <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



[cid:image001.jpg at 01CE3BB2.DD006090]<http://www.aptel.com.au/>

    Asian Pacific Telecommunications

[cid:image002.gif at 01CE3BB2.DD006090]

   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 visit www.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 visit www.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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20130417/1467f56c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 11835 bytes
Desc: image001.jpg
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20130417/1467f56c/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 2969 bytes
Desc: image002.gif
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20130417/1467f56c/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 81748 bytes
Desc: image003.jpg
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20130417/1467f56c/attachment-0001.jpg>


More information about the AusNOG mailing list