Please refer to attached diagram.
R2 & R3 connect to R1 via E1. R1 LAN public IP address is connect to Internet router.
Host with private IP at R2&R3 LAN need to access to Internet.
I wolud like to make the R1 as aggregate router, where it route to internet and perform NAT for all the remote router R2/R3 host.
R2/R3 perfrom transparent bridging on interfaces (LAN & E1)
R1 E1 interface configure with IP. IP NAT perform on R1 to NAT private to public for Internet access.
Please advice does this design requirement work ?
To make the deployment at remote site simple. No routing just need L2, no need complex configure for remote site. Centralize at AGG router. Possible of deploy E1 to Ethernet box instead of router at remote site.
But do you realized that L2 broadcast is unnecessarily spread into your slow speed link (E1)?
How complex is routing especially with EIGRP? I mean with L2, you need to worry about your STP.
I knew that, but customer require it to be simple at remote site.
- want to save Public IP address
- cater for Ethernet to E1 convertor to replace router for future deployment.
- do not expect high number of host.
- want to do all the NATting at AGG router (R1), simple for management instead have to do it at every remote router.
Other than L2 boradcast, does this solution work ?
I have seen this in the old days, with 3Com equipments. The first thing that I did when I got some new Cisco gears, I converted all of them to L3 routing domain. I am not going to promise you this will work, but I know L3 routing always work, and scalable.
See my other response - all of these can be easily addressed except for replacing the router. What on earth do you think someone could find that can convert between two dissimilar media like ethernet and serial, that could possibly be cheaper?
I am with the others.Bridging like that is a little silly. It can probably be made to work - Heck I have made much sillier stuff work - that that does mot make it a good idea.
Youe are using E1s. Set them up ap ppp, and use IP Unnumbered No extra usage of address space.
The config of the remote site will probably be simpler. Off the top of my head, with a isco at the remote site, bridging would look something like:
no ip routing
bridge 1 prot ieee
bridge group 1
bridge group 1
ip add 192.168.1.2 (you will need something to manage it).
That would be your top site (R2).
R3 would be similar.
The central router (R1) would be interesting. You *MIGHT* get away with configuring it like a normal router, but you might need to both bridge and route IP - that would be IRB - see http://www.cisco.com/en/US/tech/tk389/tk815/tk855/tsd_technology_support_sub-protocol_home.html
It will be a nightmare at 3am Sunday morning when there is a fault
Wheras doing it properly will be easily supportable
ip add 192.168.1.1 255.255.255.0
IP Unnumbered e0
ip add 126.96.36.199 255.255.255.0
IP unnumbered e0
IP unnumbered e0
You have a choose static routes, or use a routing protocol. Either will work, Either will be simple. Either can be supported easily.
Statics would be simple Each remote site would have:
ip route 0.0.0.0 0.0.0.0 188.8.131.52
And the central site would have
ip route 192.168.1.0 255.255.255.0 192.168.1.1
ip route 192.168.2.0 255.255.255.0 192.168.2.1
etc for each remote site.
NAT to the outside world is easily done on the central router.
Do your customer a favour - do it properly.