Does 2x100G mean 100G each way?
At a certain size you don't want 1x100G in case one link breaks, so for a large company they get 2x100G with each fibre going to a separate router. If one router goes down (planned or unplanned) you don't go offline. So now they probably added a second redundant pair.
You can see SIX's gear here:
* https://www.seattleix.net/topology
They have two Arista 7500-series chassis switches, one 8U and the other 12U (amongst other things):
* https://www.arista.com/assets/data/pdf/Datasheets/7500RDataS...
One of the line card options is 7500R-36CQ, which can handle thirty-six 100G ports.
That's not even Arista's highest capacity switch; the 7816R3 can handle 576x400G:
* https://www.arista.com/en/products/platforms
(I'm sure other vendors have similar product offerings.)
On the SIX side the ports are probably already in a redundant chassis but having 2 ports probably still scores you connections to two fully independent chassis in different failure zones.
2x100G to an IX are usually connected as separate ports, each with their own assigned IP ont he IX subnet. BGP multipath can enable load balancing across both ports. Otherwise you might have some peers configured on one port and others on the second. These days I like to have all peers on both ports and use BGP multipath.
If both ports are connected to a single switch on the IX side and the same router on the customer side then LACP can be used to combine them into a single 200G port with one IP. This is a less common configuration unless you are doing more than two ports (4x100G as 2x 2x100G lags for example).
There is another consideration: what happens if there is an icmp or arp flood on the IX? It's not supposed to happen but sometimes it does, even on the most major and well-run exchanges. In that case you might want to have all of your IX ports on one of your routers, keeping the other one "clean", just in case your control plane policing doesn't mitigate it.
Different networks place different priority on IX ports. In most cases it's ok if it's down for a short time (traffic will just shift to paid transit) so redundancy is not essential. In other cases it may be too much traffic to reroute so you care more about IX reliability and redundancy.
Been a lot time since I have done all this stuff though. I sort of miss it sometimes (though not the pager that comes with the territory).
Strictly speaking, IXPs do not work at OSI Layer 3, but usually at Layer 2.
All the Layer 3 routing logic happens in the routers of the members/customers of the IXP. The IXP is just there to provide a neutral interconnect to everyone without any filtering or policy.
The IXP runs router reflectors where people can choose to advertise themselves, and then other folks see who is in the neighbourhood and make their own routing policy choices.
The folks at Network Startup Resource Center (NSRC) have a series of videos on "IXP Design and Implementation":
They're by Philip Smith, who helped set up LINX (London, UK) in the early days:
Confusingly they list each of those as 200G capacity, not sure if that's a typo or it really is 2x 2x100G.
Not really sure why this is a big deal - IX bandwidth is very very cheap. It looks like seattleIX charges $7500 as a one off payment to add a 100gbit link: https://www.seattleix.net/pr20191218).
I would describe it as "capacity", not bandwidth. That fee is just to physically plug into the router. You have to make separate agreements with the other organizations also plugged into that router for peering or paid transit.