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
int e1
bridge group 1
int s1
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
R2:
Int e0
ip add 192.168.1.1 255.255.255.0
no sh
int s1
IP Unnumbered e0
R1:
Int e0
ip add 202.188.1.2 255.255.255.0
int s1
IP unnumbered e0
int s2
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 202.188.1.2
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.
