Date: Thu, 5 Apr 2007 15:51:08 -0700 From: Tony Lum Subject: RE: SIX connection details Hi Troy, It is better to turn the Q & A to into FAQ. Please have a look to see if this answers all the questions properly. FAQ Q - Will Cipherkey charge for SIX access, and if so, using what methodology? A ~V Cipherkey will not charge traffic for the peering ISPs. We are using Netflow to log each ISPs traffic to/from SIX. Q - What is the transport between Seattle and Vancouver? Who provides it? A ~V It is a dedicated, transparent Bell fibre Cipherkey contracted to link between Vancouver 6509 and Seattle 6509. 1 more fibre path is planned to redundant this link. Q - No current extensions have GE peers. Why is this different? Will the GE uplink be permitted to be saturated? A - Peers are connected to Vancouver switch via GE because there are other services provided to them on that same link. This also necessitates the requirement for VLAN trunking and VLAN based ACLs rather than simple port restrictions. This is a managed switch, excess usage will be immediately apparent, and the GE uplink is also used for other purposes, so peers overusing the SIX peering may be subject to rate-limiting to prevent saturation. Q - What else (services, traffic, etc) runs on these devices? A - Layer 3 usage of the Vancouver 6500 is for one of the peers' iBGP sessions. Otherwise the switch will be used solely to provide Layer 2 interconnect for Vancouver peers, including Cipherkey. The Seattle 6500 is a Layer 2 device, primarily intended to extend the Vancouver switch. Q - How is Phoenix reached? A ~V It is trunked from the ISP to the Seattle 6509 directly on a 100m/s fast Ethernet port. Q - Can you throw together a diagram just to make sure less-technical people can see the basic idea? A - OK, diagram attached. Q - Operating with no MAC restrictions is a non-starter for me, though the static MAC ACL is good to see. We'd restrict MACs to # of attached peers. A - No MAC restrictions on what? We will not permit traffic to flow through the VLAN that is not associated with the registered MAC address of a member device. Naturally, each peer gets one and one only MAC entry in the SIX VACL. Yes, other ports might not have MAC restrictions, but even if they are accidentally placed in the SIX VLAN, no traffic will be accepted from them. In an exceedingly paranoid setup, we could create VLAN ACLs to account for each and every Extension Peer to each and every SIX peer who is connected to an Extension Peer, but this would be cumbersome and interfere with the freedom of peers to connect. Tony