[c-nsp] Connecting isolated L3 islands without GRE tunnels

Pavel Dimow paveldimow at gmail.com
Sat Jul 13 04:38:04 EDT 2013


No no no I can't advertise my prefixes to the provider they are not all
from public address space. Never the less customer is now willing to spend
a little more money and to by ASA :) Thank you for your help

On Thursday, July 11, 2013, Pshem Kowalczyk wrote:

> Hi,
>
> I'm also slightly confused by the requirements here. If all the sites
> are publicly addressed, with internet access, why don't you just plain
> route the traffic across the internet? Each site has a default route
> from your provider and advertises its internal ranges to the provider.
> All the other sites can see that as well, so a local 3560 either sends
> it to the provider (for all remote sites, the provider does the
> routing towards the end site) using default route, or keeps it
> internal based on its local routing table. If you use the same AS in
> all the 'islands' then 'allowas-in 1' on the BGP session with the
> provider should do it.
>
> kind regards
> Pshem
>
> On 12 July 2013 07:49, Pavel Dimow <paveldimow at gmail.com <javascript:;>>
> wrote:
> > Hi Phil,
> >
> > the main problem is that I have 3560 at branch offices which I can not
> > change. The 3560 have a very poor GRE tunnel performance (when it acts as
> > endpoint). I have multiple branch offices (each with 3560) and one
> central
> > office. I am wondering if there is any mechanism that I can use on 3560
> to
> > tunnel traffic from branch office to central location? Keep in mind that
> it
> > is very expensive to have L2 or L3 VPN. I need to exchange routes between
> > central and branch offices and my solution would be some BGP and few
> static
> > routes for my super nets.
> > My best guess is that I will need to change 3560 but I want to be sure
> that
> > there is nothing else I can do with those boxes..
> >
> >
> > On Thu, Jul 11, 2013 at 11:15 AM, Phil Mayers <p.mayers at imperial.ac.uk<javascript:;>
> >wrote:
> >
> >> On 10/07/13 21:18, Pavel Dimow wrote:
> >>
> >>> Hi,
> >>>
> >>> I have a a few branch offices and I want to connect them with central
> >>> site.
> >>> Now I have a few problems. First at every branch I have the same
> provider
> >>> but it is very expensive to use any kind of their L2 or L3 MPLS
> services
> >>> hence I have only internet access. Also, at every branch we have cisco
> >>> 3560
> >>> with very bad GRE tunnel performance (about 2Mbps).
> >>> Now my only solution is to like this:
> >>> Setup EBGP with ISP (require only default route)  and setup IBGP with
> >>> route
> >>> reflector at my central location. With this I should be able to have
> only
> >>> default route from my ISP and all routes from my network (central and
> >>> branch offices) and use only a single link from ISP without the need
> for
> >>> GRE tunnel.
> >>> Any ideas if I am missing something? Any advices for better solution?
> >>>
> >>
> >> I don't understand your solution. Without some kind of tunnel or
> >> encapsulation, your routing table is irrelevant - once the traffic
> reaches
> >> your ISP, it obeys their routing table, and will either be forwarded
> >> correctly (in which case you don't need the iBGP) or incorrectly (in
> which
> >> case iBGP does nothing)
> >>
> >> Can you describe in more detail what you mean by "isolated L3 islands"?
> >>
> >> I suspect you're going to need an additional or different box at each
> site
> >> to encapsulate the traffic.
> >>
> >> ______________________________**_________________
> >> cisco-nsp mailing list  cisco-nsp at puck.nether.net <javascript:;>
> >> https://puck.nether.net/**mailman/listinfo/cisco-nsp<
> https://puck.nether.net/mailman/listinfo/cisco-nsp>
> >> archive at http://puck.nether.net/**pipermail/cisco-nsp/<
> http://puck.nether.net/pipermail/cisco-nsp/>
> >>
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net <javascript:;>
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>


More information about the cisco-nsp mailing list