Hi,
We have an AS Number AS2XXXX and have 2 /24 subnets belongs to this AS
Number. It is using in US and peering with US Service Providers now.
We are going to deploy another site in Asia, can we use the same AS Number
AS2XXXX and have 2 other /24 subnets and peering with other Asia Service
Providers?
Will it affect the routing or BGP Path of our existing subnets in US?
Please advise.
Thanks
Harris 
It will not. There was a thread on this a short while ago, check the archives.
The big question is whether the two sites will be able to talk to each other. There are ways to make that happen, but by default, a router in asXXXX will not accept eBGP announcements which include asXXXX (loop detection).
allowas-in will do the trick
Provided your uplink ISP does not filter out that.
I have 5 discrete networks across Canada using one ASN (will be down to
2 by end of year!). We accept a default (along with full tables) to
route between discrete networks. Not very elegant but gets the job done.
Eric
Why would your upstream filter that out?
I would get a new upstream if they do.
We are doing this now and it is working well
Not to budge in here ... but I have always been curious of this type of
setup, as in all my past BGP deployments its always been that all edges
belong in the same ibgp peering group.
Ryan, does the other edge(s) get confused when they see their same AS number
in the path upon route determination from traffic sourced from another edge?
Or are you doing some sort of BGP Confederation?
I am progressing down the path (no pun intended) of deploying another edge
in another location from which that 'remote' location will have it's own
subnets to announce. But if I have a requirement not necessary having to
announce the other subnets, I don't need to an expensive L2 back-haul
between the two and do what is discussed here, no?
-graham
Not to budge in here ... but I have always been curious of this type of
setup, as in all my past BGP deployments its always been that all edges
belong in the same ibgp peering group.Ryan, does the other edge(s) get confused when they see their same AS number
in the path upon route determination from traffic sourced from another edge?
you just need to defeat loop detection, which you can do on most any
router.
on junos it's nr_loops 2
According to Juniper junos document,
"BGP checks whether the neighboring AS matches the AS of the external
peer to which the router is advertising. If there is a match, the
route advertisement is suppressed. Advertisement suppression is
enabled by default for BGP peers configured in non-VPN routing and
forwarding (VRF) instances, including the master instance."
We may not able to assume all ISP willing to or by-default add
"advertise-peer-as" into configuration if they use a Juniper router.
Also we may not able to assume ISP will not put a policy/route-map to
prevent route been advertised to the same AS.
If there is a need to use single-AS in multiple sites and these sites
need to communicate each other via Internet ISP, statically route
traffic to Internet (or a default route to Internet) would be safer.
If there is a need on this kind of communication, or the communication
been done via a tunnel with both sides using ISP's IP (interface IP)
as tunnel source, then there should have no risk to use single-AS in
multiple sites in terms of connectivity.
I do not think that paragraph means what you think it means.
I've seen my own AS in full tables from upstreams using Juniper routers many times.
I think it's limited to we received from X, we will not send to X. It also probably gets turned off most of the time.
However, that is not to say that some router implementation doesn't have an optimized viewpoint of "hey, this would be a loop, so let's not send the route". Such code goes against the nature of BGP, where it's the receiving AS's job to determine policy, including loops.
Jack
According to the problem I had, the behavior is more like
"when I receive asX from 1st direct link, I will not send to asX on
2nd direct link by default."
For example,
I (say as#65001) advertised "10.1.0.0/16 ^65001$" on 1st link to my
ISP, say as#65000.
and advertise "10.2.0.0/16 ^65001$" to the same ISP on 2nd link.
Then,
I will not receive "10.2.0.0/16 ^65000 65001$" on 1st link,
and will not receive "10.1.0.0/16 ^65000 65001$" on 2nd link.
I believe my ISP did not intentionally filter out my routes,
but it more like default behavior as described in document.
Setting up default-route on both of my border routers addressed the needs.
After we established the leased line between two sites,
we no longer need to send cross site traffic via ISP.
> I do not think that paragraph means what you think it means.
> I've seen my own AS in full tables from upstreams using Juniper routers many times.According to the problem I had, the behavior is more like
"when I receive asX from 1st direct link, I will not send to asX on
2nd direct link by default."For example,
I (say as#65001) advertised "10.1.0.0/16 ^65001$" on 1st link to my
ISP, say as#65000.
and advertise "10.2.0.0/16 ^65001$" to the same ISP on 2nd link.Then,
I will not receive "10.2.0.0/16 ^65000 65001$" on 1st link,
and will not receive "10.1.0.0/16 ^65000 65001$" on 2nd link.I believe my ISP did not intentionally filter out my routes,
but it more like default behavior as described in document.
Setting up default-route on both of my border routers addressed the needs.After we established the leased line between two sites,
we no longer need to send cross site traffic via ISP.
I feel, asking to recieve (and use) default route appears "cleaner" than
hacking routing protocol ways. Unless, one does as you just did. Right?
Cheers,
mh
Yes, asking ISP to send out default-route via BGP sessions
will be better then manually setup one. A default-route from
dynamic routing protocol can disappear properly in case something
wrong over the link, while manual one could possibly create a
black hole.
BTW, this thread was talking about the use of single-AS in different
sites. I think it is no doubt doable.