Consolidate the connectivity into one single MPLS IPVPN service provider
1. HQ, Customer_A and Customer_B don't wish to change their LAN IP (172.16.x.x)
2. Customer_A and Customer_B access to HQ for applications offered
1. The MPLS backbone already has the 172.16.x.x network
1. From the scenario above, I believe we'll require to do NAT in order to avoid conflict of IP range. But if I use NAT, all the 172.16.x.x range will be converted to a whole new range. For example now Customer_A is accessing to a FTP server (172.16.1.10) located at HQ. Now customer_A need to access to the FTP server at HQ with the new converted range of IP aint it? Is there anyway that Customer_A still can directly access to 172.16.1.x range after we implemented NAT?
2. Since they're consolidating more and more branch into the MPLS network, will that be any problem if there's another Customer (Customer_C) that came in which their LAN clash with one of the existing customer? Scenario like Customer_A (172.16.2.x) and Customer_C (172.16.2.x) accessing to headquarter at once, since their LAN is of the same segment, even though after NAT, will the traffic know how to reach back to Customer_A and Customer_C properly?
3. I thought of doing GRE tunnelling, any suggestion?
It has bugging me for quite a few days and I can't find the right and best approach to tackle it, my technical team keep on telling me there won't be any problem but i just can't get some satisfy answers from them to convince me.
Really appreciate if you guys could tell me whether it can be done and what is the best approach? Thanks a million.
The LAN IP get natted once exit the router, the natted range is 192.168.x.x
so if they still want to maintain the IP address, and I do all the necessary NAT, can the C1 directly access to HQ segment (10.1.100.1)? What i worry is, the C1 LAN (10.1.1.1) has been natted once the traffic exit from the C1 router. The same goes to the HQ and C2. Can they still able to access directly into the LAN (10.1.x.x)?
Or the access way need to change to the natted IP range which is 192.168.x.x?
I'm quite confused and hope what i trying to explain understood by u guys.
This changes the network part of the address alone. Using this method, the branch will be seen as 192.168.x.x to the rest of the network. Hence, the branch will not have any problem communicating with the HQ. However, you will still have problems communicating with the other branch which has the same LAN IP. The problem here will be that the hosts on the LAN will think that they are on the same LAN with the other branch, which is not so.
The fact that the MPLS core network uses the same address does not matter. The core addresses are hidden from the VPNs
After I use the static NAT (NAT Pool) all the range already natted to 192.168.x.x range, last time when Branch1 access to Branch2's FTP, they use the 10.1.2.20, can they remain the same way they access the FTP server after NAT implemented?
Actually the Branches and the HQ are connect in a Hub-and-Spoke design, whereby only branches access to HQ, there is no inter-branch communication...what I concern is, even though there's no inter-branch traffic, but if two branches of the same LAN, even though after NAT implemented, does the HQ know how to get back to the right branch since their LAN ip is of the same range...
For example..Branch_A and Branch_B is at address of 10.1.10.x, after NAT Branch_A is 192.168.2.x while Branch_B is 192.168.3.x...do u guys foresee any problem?
What I want to achieve is, the implementation is totally transparent to the user, if Branch_A (10.1.10.x) can access to HQ (10.1.1.x) for services, after the NAT implemented, I want them to be able to access the services at HQ with the same IP range (10.1.1.x) as well, without the need to change their access IP to the new natted range...
I hope i get my question right...I'm really confuse about how an ISP should do when they migrate existing customer's network....sigh
The purpose of NAT is to make it look to the outside world that the IP address has changed. Therefore, if you NAT to the 192.168.x.x addresses, you do not need to change address of the branches. Also, they can still access the resources at the HQ the same way they were accessing it before. What to note is that the HQ beleives the branch has a LAN address of 192.168.x.x. Hence, it should have the right routes for 192.168.x.x. Also, for the HQ to access resources at the branch, it will need to use the 192.168.x.x also.
The branch PCs see their LAN as 10.1.x.x and they are accssing resources at 10.1.x.x
The HQ has her resources at 10.1.x.x and sees connection coming from 192.168.x.x.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...