[AusNOG] Hatteras redundancy

[Mark ZZZ Smith]

      From: Richard Thornton <richie.thornton at gmail.com>
 To: ausnog at lists.ausnog.net 
 Sent: Friday, 5 June 2015, 15:32
 Subject: [AusNOG] Hatteras redundancy
   
Hi,

Not sure if this is the best mailing list but you have all been very
helpful in the past :)

Apologies if my knowledge is a bit sketchy, I am trying to visualise
how I can have "redundant" hatteras, let me paint a picture:

Rack in SY3
Dual routers and internet connections
Hatteras comes in to an hypervisor appliance over an ethernet VLAN on a switch

Right now I only have one hatteras circuit but that will grow.

So I want to add a second appliance to remove a single point of
failure and also add an extra switch for the same reason.

As you know one of the cool things about hatteras is the fact it looks
like layer 2 LAN (MPLS right), so I would rather not route the
hatteras after it's handed to me, so how do I get all this redundancy
without losing the layer 2.
/ That's why looking like a layer 2 LAN isn't really that "cool", or as simple as it initially appears, because redundancy becomes a problem.
/ If I understand your scenario correctly, your choices are:
(a) Spanning Tree Protocol or a faster variant (RSTP, MSTP) (b) Multi-Chassis LAG(c) Plug your appliances directly into the Hatteras devices, and run VRRP between them(d) Plug your routers directly into the Hatteras devices, and run VRRP/HSRP between them
/ There are a variety of issues with STP. Carriers, or the equipment they use, commonly drop it on "emulated LAN" services because (a) true IEEE 802.1d switches aren't supposed to forward STP BPDUs, (b) a multi-vendor network might have a mix of equipment that may or may not be able to forward them, and (c) STP BPDUs may leak across services, impacting other customers, or possibly, impacting the carrier network itself (if they happen to be running STP internally for some reason, even though they should avoid it). Some of these issues would go away if there was a way to perform STP authentication (similar to how IP routing protocols can support authentication), but it doesn't.
/ Multi-Chassis LAG (MC-LAG) is an alternative that doesn't suffer from as many issues as STP. However, it isn't standardised by the IEEE, and to I think to completely eliminate a single point of failure across the both the pair of links and the pair of equipment at the ends of them, both devices have to support MC-LAG (and run MC-LAG independently of each other - i.e., the far end doesn't realise the local end-is running MC-LAG, and the local end doesn't realise the far end is running MC-LAG). So both the Hatteras devices and the two switches that you have would need to support and have enabled MC-LAG. Even if the Hatterases (Hatteri?") do support MC-LAG, the carrier using them might not have it available as a product option.
/ The third option makes the two appliances look like a single host with two network cards attached to the same network. VRRP is then used to make one of those network cards active for all IP traffic, and if that network card fails, then the other network card (and therefore appliance) takes over within a few seconds. The drawbacks are that you become constrained to having to run everything on the two directly attached appliances, and if you want this fail over to become transparent to the down stream clients, you have to somehow synchronise application and other state (e.g., firewall and TCP connection state) between them.
/ The forth option uses a pair of routers instead of the appliances and running VRRP or HSRP between them. This overcomes the issue of having to run everything on the directly attached appliances, but now you don't have the "simplicity" of the single LAN because you're now doing IP routing, and your throughput may be reduced because layer 3 throughput is more expensive than layer 2 throughput if you're limited to the same amount of $s.
/ It is also common for people to want both redundancy and performance, so that you have active/active rather than active/passive links and attached equipment. The above options don't provide that, or at least don't easily provide it. Doing redundancy and spreading traffic over multiple links/paths is easier to do at the IP layer, because IP protocols have been designed to support and use multiple paths through the network. If your network gets just a bit more complicated than below, a better service to get might be a Layer 3 VPN.
/ Regards,/ Mark.



So right now the hatteras is handed to me by a middle man, I may
remove the middle man and start doing the MPLS.

So like this:

circuit1  switch/router  appliance1    internet router1
            X                    X                  X
circuit2  switch/router  appliance2    internet router2

Thanks for looking.

Cheers
Richard
_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20150606/94448a6a/attachment.html>