[j-nsp] Alternatives to floating static routes?

Dario dario.donsion at soporte.rediris.es
Wed Oct 4 06:01:52 EDT 2006


Dear all,

Many thanks for your answers :)

Then BGP with private-as is the best solution :) , towards each customer.

	Networks1 -- Customer 1 ------ BGP1 -----|
				|				|------ Juniper
	Networks2 -- Customer 2 ------ BGP2 -----|

We'll announce default route to each customer and they announce their networks and the 
networks of the other customer (with one prepend for example). We need also to decrease 
bgp timers in order to fas re-route.

Each customer needs to configure an static route to the networks of the other, via the link 
between then. An, to provide out access when their link with us fails, they need to configure 
other static route (default) via the link between them, with more metric than BGP (to only 
be active when BGP fails).

Is that correct? Anything wrong? We don't have any test-bed to check this configuration so
we need to be sure before implement it :)

Best regards,

	Dario D.




El Martes, 3 de Octubre de 2006 23:35, leigh porter escribió:
> 
> Indeed, and they may do something horrid that you cannot filter out. BGP is
> great for filtering rubbish out.
> 
> IGP's are just that, Internal - for a good reason ;-)
> 
> --
> Leigh
> 
> 
> 
> 
> On 3/10/06 19:09, "Warren Kumari" <warren at kumari.net> wrote:
> 
> > Running any sort of IGP with a customer (or any external entity) is
> > just asking for trouble...
> > 
> > If Customer has a flapping link or they suddenly start announcing a
> > large number of LSAs, etc. you will feel a large amount of pain...
> > 
> > BGP with private ASes is really easy to configure, provides a clean a
> > clear demarc and allows you to protect your infrastructure from a:
> > maliciousness and b: accidental mis-configurations.... If Customer
> > cannot configure this, you can always email them a template config....
> > 
> > W
> > 
> > On Oct 3, 2006, at 8:58 AM, Wade Sheridan wrote:
> > 
> >> Dario,
> >> 
> >> Couldn't you run an OSPF area which would contain both the
> >> customers routers
> >> and your interface.  That way if the link from Customer 1 and the
> >> switch
> >> goes down, you'd loose your neighbor but you'd keep getting the
> >> routes from
> >> Customer 2 with a slightly higher metric?
> >> 
> >> Thanks,
> >> 
> >> Wade
> >> 
> >> 
> >> On 10/3/06, Dario <dario.donsion at soporte.rediris.es> wrote:
> >>> 
> >>> Hi all,
> >>> 
> >>> We need to develop a solution to provide redundancy for two of our
> >>> clientes, connected to us via our
> >>> Cisco Catalyst 2950.
> >>> 
> >>> This is the topology:
> >>>                                  [FastEth]
> >>>        Router Customer 1       ------------- |
> >>> [GigaEth]
> >>>                                                 |  Cat 2950
> >>> --------------- Juniper M40e
> >>>        Router Customer 2       ------------- |
> >>>                                  [FastEth]
> >>> 
> >>> Right now we have static routes in our Juniper to connect with each
> >>> customer. The customers have the
> >>> posibility to connect their routers. Each one request us to
> >>> reroute its
> >>> networks via the other customer when
> >>> its link fails.
> >>> 
> >>> We first think in floating static routes, two routes for each
> >>> customer,
> >>> the actual one and other via the
> >>> other customer with more metric.
> >>> 
> >>> But it'll no work because if for example the link between the
> >>> Customer 1
> >>> and our CAT 2950 fails, our
> >>> Juniper see the link with the CAT 2950 up (no possibility to
> >>> configure
> >>> keepalives), then the active route
> >>> is the static route without metric, it never changes to the floating
> >>> route.
> >>> 
> >>> BGP (using prepends,...) is a solution but we prefer another one if
> >>> possible. Any ideas?
> >>> 
> >>> Many thanks and best regards,
> >>> 
> >>>        Dario D.
> >>> _______________________________________________
> >>> juniper-nsp mailing list juniper-nsp at puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >>> 
> >> _______________________________________________
> >> juniper-nsp mailing list juniper-nsp at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 



More information about the juniper-nsp mailing list