Hi Mike, On 22/09/2010, at 5:13 AM, TCIS List Acct wrote:
> The J-series specs (which run JunOS) did seem to list a specific # of VRs, > not sure if that is a license limit or just a "capacity" type of rating. > This PDF is quite handy for specs like that: > > http://www.juniper.net/us/en/local/pdf/datasheets/1000265-en.pdf > > For instance, it lists the J-6350 as having 30 VRs. My experience with the JUNOS data sheet numbers is that they are the maximum "supported" from a JTAC perspective, however the box will continue to take configuration until it runs out of memory. I just had a quick look back through the j-nsp archives for an old post of mine, where in JUNOS 8.4 I wrote a script that built 300 VRs (which was an arbitrary number) for a customer trying to do almost exactly what you are doing. There certainly is no licensing on the J-Series (or SRX) for the number of VRs. > It isn't clear from your answer if if I can have 192.168.1.x exist as a > remote network for multiple customers (each with their own VR).. can you > clarify? >From a routing perspective, yes - all VRs are logically separate routing >domains, so you can have overlapping prefixes without any issues. Similarly, >your firewall rules will be applied to zones which contain interfaces, which >are placed in these VRs, so different zones can have overlapping address >objects and your rulesets will all work as expected. Where things become difficult is when you have multiple customers in their own zones/VRs and you want them to egress through a single zone/interface - if anyone out there has a solution (elegant or otherwise) for this scenario, I'd love to hear about it. In the next week or so, I've got some IPSEC work that needs to be done for a customer who would like tunnels split between VRs as well, so I'll come back with my findings there. > Ben Dale wrote: >> Hi Mike, >> In ScreenOS you can achieve all of your requirements using VSYS, however you >> will find this is a fairly expensive road to go down with large numbers of >> clients (VSYS are licensed). >> In JunOS you should be able to meet all of your requirements without any >> licensing issues - VRs are "free" and will do most of the same >> functionality. The only limitation is IPSEC tunnelling from within a VR >> which is currently in a state of flux (currently the interface the IKE >> gateway is bound to has to live in the global routing table), but I imagine >> this will be fixed in time. >> Cheers, >> Ben >> On 21/09/2010, at 5:02 AM, TCIS List Acct wrote: >>> We are looking to provide "virtual firewalling/VPN" services to customers >>> hosted in our VMware and Hyper-V hosting environments (trying to avoid >>> dedicating a physical NIC port for each customer on the host and hanging a >>> firewall appliance off of each). In a nutshell, each customer gets their >>> own VLAN subinterface (which will cascade all the way down into their >>> virtual machine), and we can define unique firewall rules (as well as >>> establish IPSec VPN tunnels) on a per-customer basis. >>> >>> I'm looking at the following platforms: >>> >>> SSG-500 (ScreenOS) >>> Juniper J-series (JunOS) >>> >>> It is not clear if I simply need the VR (virtual router) or VSYS (virtual >>> system) feature(s) to do this -- I need a unique routing table, a unique >>> set of firewall rules/zones, and the ability to define VPN tunnels even if >>> there are overlapping VPN endpoint networks among multiple customers (e.g. >>> both Customer "A" and Customer "B" use 192.168.1.x on their side). >>> >>> Any insight would be much appreciated. >>> >>> --Mike >>> _______________________________________________ >>> juniper-nsp mailing list [email protected] >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>> > > -- > > ----------------------------------------- > Mike Bacher / [email protected] > TCIS - TulsaConnect Internet Services > http://www.tulsaconnect.com > ----------------------------------------- > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
