Mail server machine (with ftp server too)
external IP: A.B.C.251
internal IP: 192.168.10.30
My default gateway is:
(output of netstat -rn)
default A.B.C.193 UG 1 225
Now, I decided to add an INTERNAL ZONE:
new zone IP: 192.168.10.85
Due to the fact that I could not ping the outside world from the zone, I added a route through our firewall, into the mail server.
So, I did this: route add 0.0.0.0 192.168.10.8 1
So, now the netstat -rn output shows:
default 192.168.10.8 UG 1 225
default A.B.C.193 UG 1 225
The netstat -rn in the zone says:
default 192.168.10.8 UG 1 43
Looks nice ................. BUT ...............
pop3 connections from the outside world into the A.B.C.251 hang, also ftp hangs,
SMTP is very flakey.
Ping works.
This happens because now, on any outbound connection, the machine is using BOTH ROUTES IN ROUND-ROBIN FASHION.
And a lot of internet services have connections with special outbound control ports etc etc, and this flakey routing setup makes them STOP OPERATING PROPERLY.
Which is, needless to say, CRAP.
When I delete the 192.168.10.8 route, all email/ftp services go back to normal, but the internal zone remains incommunicada. Which is also crap.
I tried foxing aroung with ndd , and changing the ip_forwarding in /dev/ip , to no avail.
I was going to get really excited converting our 45 Netra T1's running on 6 networks, over to 3 or 4 Sun X4200's.
Now I have stopped the project, due to the flakey routing issues.
Yeah, the shared routing in zones is a dreadful hack and often doesnt work the way you would expect.
The problem is coming from the fact that you want the global zone and the zone to be on different subnets, but you want the global zone on both.
If the private and external networks are on different physical subnets then you could give the zone its own physicial interface and use exclusive zone ip. I'm pretty sure that would solve the problem.
Alternatively, if you can remove the global zones IP on the internal network, then the problem would be avoided.
Could you move whatever "role" the global zone is performing for the internal subnet onto another zone?
So you have the global zone on the external network and 2 zones on the internal.
the situation is very simple., and believe you me, I tried "every trick in the book", including NAT, ipfilter, portfwd, the works, ndd hacks, everything.
Solaris ZONES POSTULATE # 1 (routing issues)
a. If your "parent machine" otherwise known as "global zone" , is in a different subnet as your zones, then you cannot use that machine for anything else, than running the zones, and only with "outbound connections from the zones". Also, due to the fact that the kernel will use the multiple default routes in a round-robin fashion, you are faced with the inevitable consequence that all your partner's ACL's will need to be updated, so they can "authenticate" you, as coming from 2 IP's (the external IP of the parent box, and your standard default route firewall/router for the internal zones).
b. If you receive any FTP/SMTP/POP3, or other complex connections in the external IP of the parent box, you are basically "pizzing up a rope".
And I gather, all of this could easily be solved if the kernel had a parallel IP stack for each zone, and each zone was allowed to route from china to gabon without affecting the parent machine, or any other zone.
"Recent" versions of nevada, or Update 4 and later of Solaris 10.
is this available in Solaris 10 x86 too ?
Yes. But you must have a GLD3 interface. (Run 'dladm' and verify. If it's 'legacy', then it won't work).
For a normal (shared-ip) zone, you provide an interface and an IP address. For an exlusive zone, you provide an interface and you set the ip-type to 'exclusive'.
FOUND A KLUDGE, thanks to some dude called Mel Jr, and another guy called Beavis (aka klaus) who did all the work and testing, what is needed is a THIRD SUBNET, and then it works:
summary:
1. say your internal net is 192.168.10/24
and you want your zone in say 192.168.10.85
this has to live in a box that has an external IP A.B.C.N with an external route A.B.C.1 (or other)
and she also has an internal IP, say 192.168.10.251
2. go to your firewall (the box that can route from 192.168.10/24 to the outside world), and configure a new subnet
say the default internal IP on that gateway is 192.168.10.1
well, now add a new IP in a new class C, say 192.168.11.1
then configure your route tables so she can talk to the outside world via the 192.168.11 subnet
3. go into your server where the internal zone will live, and do this:
ifconfig bge1 addif 192.168.11.85/24 up
route add default 192.168.11.1
ifconfig bge1 removeif 192.168.11.85
(this above is only used to "create the default route", we then gracefully remove the new subnet from the "global zone")
4. now, go create your zone (or edit the one you got), and do this:
set autoboot=off
add net
set address=192.168.11.85
set physical=bge1
set address=192.168.10.85
set physical=bge1
end
(if you have to edit it, I halted it, then I opened zonecfg , and just add the new one set address=192.168.11.85 , set physical=bge1 , end, verify, commit, and then I booted it, dont forget to set autoboot=off)
5. in /etc/rc2.d/S98xxx (or any other creatively named startup script which cannot be S99xxx anymore due to the hidden micro$oft BOFH spy who killed a zillion solaris bootups upon upgrade)
put this:
ifconfig bge1 addif 192.168.11.85/24 up
route add default 192.168.11.1
ifconfig bge1 removeif 192.168.11.85
zoneadm -z zezone boot
========>>> so, basically what is happening, is, we are creating a new default route, which the global zone cannot use, as she does not have any interface in that subnet, only the new internal zone has one.
Email this Topic
Edit this Topic
