I would like to setup 2 sites with the same subnet and AS number.
I'm wondering if this will not cause a problem when we send a connection attempt to our vendor, meaning we would initiate the connection from one site, and the vendor replying to the other site.
Here is our current setup:
Site A (AS555 - IP:220.127.116.11)<--Vendor
Here is the proposed setup:
Site A (AS555 - IP:18.104.22.168)<--Vendor-->Site B (AS555 - IP:22.214.171.124)
Let's say site A initiates a connection attempt to the vendor, they will receive, process and reply. Since Site A initiated the connection, will the reply always return to Site A or possibly go to Site B??
Note: i want to keep the BGP advertisements with the same weight so that customers connect to the closest site.
Thanks for any help.
Let's assume data center A is connected to the internet (multi-homed) via AS 123 and originates routes for customer A. The idea I am pushing is to use AS 123 at data center A and physically migrate the server from data center B to data center A. As you move servers you would assign them addresses from the space tied to as 123. As subnets moves were completed you would begin advertising the subnets formerly advertised via AS 456 via AS 123.
Do you mean to say you will advertise the same prefix via both the data centres and ther servers will be hidden by seperate NAT address?
Same prefix, no nat. All server have bublic IP's and are reachable on both data centers.
I'm worried that when i send a request from site A and the vendor is closer to site B, then the reply will go to site B and not back to A.
If the inbound traffic is concerned there should not be a problem as it will always go to the nearest server and reply to will be on the same path.
you will definitely have an issue for outbound traffic.
BTW, You cannot have the same prefix at both the data centres if they are interconnected.
am i missing something here?
i knew that i will have a problem with outgoing connections. Just wanted to make sure. They will be connected via VPN but on different subnet.
Does it mean there will be a second server in site B using the same public IP address as a primary server in site A?
I that case, session might start with one server an then some packets might be sent to the second server (imagine routes can change because of a line failure "somewhre", e.g.).
Or will just a packet coming to site B routed through the VPN tunnel to site A to reach the server?
Even in this case, you may get into trouble with out-of-order packets, asymmetric routing, etc.
Yes both servers in both sites will use the same public IP.
But they do not need to contact each other, only customers and vendors.
If a customer initiates the connection, then the server will properly respond.
but i think that the it is a server from one of the sites that sends the request, then it needs to be from a unique IP that is only accessible from a single site.
you might get into troubles (depending on applications used on the servers) with:
1. A customer starts TCP communication with a server in site A.
Something changes on the path between the customer and site A and following packets will be routed to site B.
The server in site B will refuse them (TCP seeeion not established yet) and the session will have to be restarted.
2. A router somewhere in the Internet can provide per-packet load balancing.
Having equal cost routes to site A and B, every second packet might be routed to wrong site constantly.
Generally, I'd be afraid of this design.
Avi, If this is an internet design, you will have to Nat the egress traffic at some spot. The customer firewall as an example will see the traffic as out of state just for starters if the return traffic comes from a diffrent IP. A load balancer is the way to go.
So you think this is not the best solution?
I'm trying to provide site redundancy without having to give our customers multiple IP's.
We do VoIP traffic and some customer are not able to re-route when an IP is down, so for this reason i wanted to have two sites with the same IP. In case one site fails, then customers don't need to do anything.