greetings list,
hoping someone can hook me up on the right way to do this.
Ok. The way I read this is that you're redundant as far as one of your
upstream links going down - it'd not cause complete meltdown as that
router that had that link would still be announcing that space to the
other router (over EBGP) and then to the net.
What you're worrying then is what happens if actual router is down, right?
But that begs the question of how you're getting the routes that router is
announcing in the first place. Is it coming from some other "edge" router
(that is also talking over local net to your 2nd core router)?
If so each of your routers has complete local routes table through IBGP
and you are not announcing it all because you're using static "network"
statements in BGP config. In that case my suggestion would be to drop EBGP
connection between routers and have each router announce entire ip space
but put up 'as-path prepend' statements with the other adding the other
router's ASN for routes that you want to be considered as being primary
from that other router. Now exact configuration suggestion would depend on
what hardware the routers are, i.e. is it cisco, etc.
P.S. I've never been in situation of having to merge two ASN's or in situation
you describe, so possibly people who have would have better suggestions.
Note - I got confused by the subject and everything myself. The routes you
have locally would not be from IBGP but just directly through IGP (i.e.
OSPF or EIGRP etc). I don't think you can really do IBGP if routers are
not configured with the same ASN.
Well, you sort of can with confederations (internally) but the external view is still the single advertised ASN.
Note - I got confused by the subject and everything myself. The routes you
have locally would not be from IBGP but just directly through IGP (i.e.
OSPF or EIGRP etc). I don't think you can really do IBGP if routers are
not configured with the same ASN.>
> Ok. The way I read this is that you're redundant as far as one of your
> upstream links going down - it'd not cause complete meltdown as that
> router that had that link would still be announcing that space to the
> other router (over EBGP) and then to the net.
>
> What you're worrying then is what happens if actual router is down, right?
> But that begs the question of how you're getting the routes that router is
> announcing in the first place. Is it coming from some other "edge" router
> (that is also talking over local net to your 2nd core router)?
>
> If so each of your routers has complete local routes table through IBGP
> and you are not announcing it all because you're using static "network"
> statements in BGP config. In that case my suggestion would be to drop EBGP
> connection between routers and have each router announce entire ip space
> but put up 'as-path prepend' statements with the other adding the other
> router's ASN for routes that you want to be considered as being primary
> from that other router. Now exact configuration suggestion would depend on
> what hardware the routers are, i.e. is it cisco, etc.
>
> P.S. I've never been in situation of having to merge two ASN's or in situation
> you describe, so possibly people who have would have better suggestions.
>
> >
> > greetings list,
> >
> > hoping someone can hook me up on the right way to do this.
> >
> > ---
> >
> > we have two ASN's we control.
> >
> > we have two border/edge routers (1 in each ASN) that talks to a
> > different backbone provider.
> >
> > the two border routers peer with eachother over eBGP and also are in
> > the same OSPF process. (we are working to merge them into the same
> > BGP ASN)
> >
> > my question is this:
> >
> > how do we achieve router redundancy between these two routers?
> >
> > currently if we lose a transit link, the traffic will flow fine out
> > the other pipe.
> >
> > but we don't have BGP network statements in router 2 that exist in
> > router 1 and we don't have BGP network statements in router 1 that
> > exist in router 2.
> >
> > so the routes injected into BGP from router 1 will get withdrawn right
> > if router 1 dies?
> >
> > is it a problem to announce the same networks from two different eBGP
> > peers to two different upstreams?
> >
> > ------
> >
> > if you are still reading, thanks!
> >
> > to clearify some more-
> >
> > current setup:
> >
> > current setup:
> >
> > ASN 1 (we're not Genu!ty- just using for an example)
> >
> >
> >
> > ASN 1 injects all of its own space and announces this space to
> > Above.net and ASN 2
> >
> > ASN 2 injects all of its own space and announces this space to Savvis
> > and ASN 1.
> >
> > so stuff out on the net looks like:
> >
> > 1 6461 etc etc
> >
> > and
> >
> > 1 2 6347
> >
> > -------
> >
> > 2 6347 etc etc
> >
> > and
> >
> > 2 1 6461 etc etc
> >
> > -------
> >
> > so, you see we are prepending on of our AS's on the way out.
> >
> > the problem is tho, we only have 1 router in each respective Autonmous
> > System injecting address space. if we lose that router, we lose
> > announcing that ASN's space.
> >
> > is it totally going to cause probs to have routes originating from two
> > different AS's? routing loops would be a real drag.
> >
> > what about having an iBGP router in AS 1 inject the same space as the
> > border router in AS 1? this other router also peers with AS 2....
> >
> > thanks a lot!
> > jg
Vinny Abello
Network Engineer
Server Management
vinny@tellurian.com
(973)300-9211 x 125
(973)940-6125 (Direct)
PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A
Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com (888)TELLURIAN
There are 10 kinds of people in the world. Those who understand binary and those that don't.
Hi
Your problem may be is similar when one ISP buy to another ISP, sometimes
is easy to modify the IGP like in this case (OSPF) because it is something
inside of your company and you have the control over all the devices but
you still have the problem outside of the company; client, others ISP, etc
Check the feature of BGP "Local-AS" for routers Cisco if yours routers
aren't Cisco, check for someone similar with your vendor. May be you need
to do something else.
This is the url where explain how it works.
http://www.cisco.com/en/US/tech/tk365/tk80/technologies_configuration_example09186a00800949cd.shtml
I hope it help you
-Hans
greetings,
from what you are saying, it appears you just got two routers
in the equation..
i say it's just easier for you to merge both routers into single
asn and run an igp in between. announce your aggregate(s) at both
routers afterwards, now that they are in same asn. so no inconsistant-AS
issue there
if your transit provider is not being cooperative fast enough,
temporarily use 'neighbor a.b.c.d local-as oldasn'. then you can get rid
of that once they update their end.
as far as announcing same space between two diff. asn's causing problems..
yes and no.
as long as your FIB entries for the most specific are pointing to working
path on both routers, you won't run into technical problem. but this is
inconsistant-AS issue which is often perceived as 'not cool.' IMHO, its
ad-hoc solution
-J
You could always run HSRP or something similar between the two routers. That
would give you physical redundancy on your end.
Setup the same single ASN on each router.
In a simple form, you could create the same access-list on each of your routers
containing all the blocks you want to advertise. And then setup a route-map on
each router that would weigh the routes heavier from one router and lighter than
the other.
This way you could take a full BGP table from each provider and have physical
failover on your end. Service disruption ~should~ be minimal if any.
If you require more granularity with your advertisements, you would always
create multiple acls to advertise from.
If you want some config parts hit me up off list.
hth
[Fri, Feb 20, 2004 at 02:41:46PM -0800]
isaac@ravengate.net Inscribed these words...
He might try:
http://www.cisco.com/en/US/tech/tk365/tk80/technologies_configuration_example09186a0080093f2c.shtml
This one shows how to setup HSRP on the inside for the automatic failover
that he's looking for.
Curtis