In this post we will look at an “Internet-as-a-Service” type solution in an MPLS infrastructure. This is an all Juniper solution as depicted in the diagram, however you could achieve similar functionality with Cisco ASR 1k’s. The firewalls depicted in the middle of the diagram are running virtual-firewalls (i.e., “LSYS” in Juniper parlance, “contexts” in Cisco parlance). You could use ASAs, however ASAs do not support dynamic routing in context mode at this time.
Also, the top MX5s depicted here could be replaced by SRXs running in packet mode and you could achieve the same functionality. That would probably be a much cheaper solution. In fact all the MXs depicted here could be replaced in this fashion. I’m just an MX bigot… I admit.
So from the top of the diagram, lets get to it…
So, in this diagram we have two datacenters each with connectivity to the internet. The internet is terminated into an MX5 inside of a VRF. From there we have a cable, both ends connected to the same MX5. This ethernet link is divided into VLANs. One one end all of the VLANs terminate into the Internet VRF (INET). On the other end of the link the VLANs go into individual VRFs. These VRFs correspond to networks requiring internet access. These could be internal networks such as DMZs, Guest Internet, or some other line-of-business requiring internet service. They could also be external customers you are providing internet service to.
The oRed and oGreen VRFs find their way to a pair of MXs sitting on the outside of virtualized SRXs. They pass down through the LSYS firewall instances and into a second pair of MXs. The iRed and iGreen VRFs are the inside Red and Green networks and of course these go to other PEs as shown.
The oBlue VRF could belong to some line-of-business or customer with their own firewall. Blue traffic does not pass through the SRX. Traffic passes via MPLS from the PE facing their firewall to the top MX5s.
You’ll notice I explicitly identified that the top MX5s have “Q” licenses. This license buys you per-VLAN traffic-shaping. You can traffic-shape each VLAN on each end of the cable to provide tiered service to your client networks. You can shape at different rates in each direction and apply custom QoS policies in each direction on a per-client basis.
You can have the top MX5s peer to themselves itself via iBGP over the looped cables. A default route (or other routes as needed) could be advertised over these sessions from the INET VRF to the oRed, oGreen, and oBlue VRFs. These in turn will be exported via VRF export policy and ultimately propogate down to the client networks through the firewalls. The virtual-firewalls are running iBGP and are configured as route-reflectors.
In the opposite direction the Red and Green customers could originate a “route-of-record” or “anchor route” in the core of their networks. This route is for a network like 10/8 or some /32 address that is configured on multiple core devices pointing to null. It is then redistributed into their routed network. This route tells the SRX that it has reachability to the client network. The SRX detects this route and then conditionally injects registered subnets via iBGP up towards the outside MXs. These are then imported on the top MX5s into the individual client VRFs and then advertised via iBGP up to the INET VRF. Alternately, and even simpler the client network could just use the registered subnets themselves as the “route-of-record.”
The Blue VRF in this case is simpler. Routes propogate from the outside of Blue’s firewall directly to the top MX5s.
Client networks may not have their own registered subnets to advertise out to the internet. Instead you may assign smaller chunks of a registered subnet across multiple client networks. When these routes propogate up into the INET VRF you can create an aggregate or generated route there which you then advertise out to the internet.
Everything in larger green boxes are PE nodes on an MPLS infrastructure. Therefore, its important that you use local-preference to ensure that traffic from each side of the SRX virtual-firewalls prefers the same firewall. For instance if the Red network is to prefer the firewall at Data Center A, then you would export routes from the MXs on each side of the firewall at Data Center A with a higher local-preference than the MXs on each side of the firewall at Data Center B.
Having this solution over an MPLS infrastructure has some benefits. If the internet pipe at either Data Center falls down, traffic will re-route through the MX5 at the opposite data center. However, the client will not lose their sessions. Traffic will find its way back to the preferred firewall from the opposite data center over the MPLS cloud. This may introduce some latency, but it may not matter that much. Especially if losing sessions is more of a problem.
You can, of course, also manually load-balance your traffic between the internet pipes using AS-PATH prepending and local-preference. You would do the prepending on registered subnets you are advertising to the internet. The local-preference you would set on the default-routes you are advertising from the INET VRF to the client VRFs.
You could use the IPS functionality of the SRX itself. Another option for IPS is to not plug both ends of the cable into the top MX5. Instead you could put an IPS in-line there and/or perhaps a tap or switch to replicate traffic to a sniffer or IDS. You could also configure unicast RPF on the VRF subinterfaces of the MX5 and then add a VRF-enabled black-hole route-server to the network somewhere. You also have the ability to apply filters and policing to the subinterfaces as required. Another option is to use an MX platform that supports services hardware (see “Reporting” below) which has stateful-firewall and IDS functionality.
If you are using SRXs in “packet-mode” instead of MXs as described earlier keep in mind that security services will not be available to you. Although, you could probably come up with a solution that involves the “selective packet mode” feature of the SRX and “lt” interfaces to interconnect VRFs with VRs.
Lastly you could use an MX platform supporting a services blade. On larger MX platforms these are MS-DPCs. On some of the MX80-based platforms there will probably be services MICs (talk to your SE). They perform the same function and look the same on the command-line. These devices support JFlow (i.e., Netflow) which requires the JFLOW license. Of course, you also have SNMP and features like SCU/DCU.