Misplaced Pages

Seattle Internet Exchange

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.

The Seattle Internet Exchange (SIX) is an Internet exchange point in Seattle , USA. Its switch fabric is centered at the Westin Building and extended to KOMO Plaza, Sabey Intergate, and other locations. The SIX is one of the most successful examples of neutral and independent peering points, created as a free exchange point originally sponsored only by donations. The SIX is the most frequently cited model upon which other neutral Internet exchanges are based, and its financial and governance models are often cited as inspiration for other exchanges. It continues to run without any recurring charges to the participants and current major funding comes from one-time 10, 100, and 400 Gbit/s port fees, as well as from voluntary contributions from stakeholders. The SIX is a 501(c)(6) tax-exempt non-profit corporation.

#901098

48-586: As of April 21, 2024, there are 370 networks (443 routers) connected to the SIX advertising at least 195,000 (140,000 IPv4, 55,000 IPv6) unique Border Gateway Protocol (BGP) routes. There are two route servers running the Bird Internet routing daemon (BIRD). The core of the SIX consists of Arista Networks switches, with a 7808R3, 7512R, and 7508R at the Westin Building, a 7504R3 at KOMO Plaza, and

96-447: A TCP session on port 179. A BGP speaker sends 19-byte keep-alive messages every 30 seconds (protocol default value, tunable) to maintain the connection. Among routing protocols, BGP is unique in using TCP as its transport protocol. When BGP runs between two peers in the same autonomous system (AS), it is referred to as Internal BGP ( iBGP or Interior Border Gateway Protocol ). When it runs between different autonomous systems, it

144-463: A VPN tunnel, allowing two remote sites to exchange routing information in a secure and isolated manner. The main difference between iBGP and eBGP peering is in the way routes that were received from one peer are typically propagated by default to other peers: These route-propagation rules effectively require that all iBGP peers inside an AS are interconnected in a full mesh with iBGP sessions. How routes are propagated can be controlled in detail via

192-402: A 7504R at Sabey Intergate. Participants may connect to the SIX core using a 1 Gbit/s, 10 Gbit/s, 40 Gbit/s, 100 Gbit/s, or 400 Gbit/s Ethernet connection (fiber) or to one of several extensions. Extensions are sponsored by colocation facilities or transport providers . Both IPv4 and IPv6 peering is available and encouraged at the SIX, with availability dependent on

240-519: A MED with the highest possible value. The current standard specifies that missing MEDs are treated as the lowest possible value. Since the current rule may cause different behavior than the vendor interpretations, BGP implementations that used the nonstandard default value have a configuration feature that allows the old or standard rule to be selected. The local preference, weight, and other criteria can be manipulated by local configuration and software capabilities. Such manipulation, although commonly used,

288-481: A hierarchical name. For example, the administrator of AS 64500 may create an AS-SET called "AS64500:AS-UPSTREAMS", to avoid conflict with other similarly named AS-SETs. AS-SETs are often used to simplify management of published routing policies. A routing policy is published in the IRR using "import" and "export" (or the newer "mp-import" and "mp-export") attributes, which each contain the source or destination AS number and

336-509: A local preference value from local policy rules and then compares the local preference of all routes from the neighbor. BGP communities are attribute tags that can be applied to incoming or outgoing prefixes to achieve some common goal. While it is common to say that BGP allows an administrator to set policies on how prefixes are handled by ISPs, this is generally not possible, strictly speaking. For instance, BGP natively has no concept to allow one AS to tell another AS to restrict advertisement of

384-470: A maximum of 65,536 assignments. Since then, the IANA has begun to also assign 32-bit AS numbers to regional Internet registries (RIRs). These numbers are written preferably as simple integers, in a notation referred to as "asplain", ranging from 0 to 4,294,967,295 ( hexadecimal 0xFFFF FFFF). Or, alternatively, in the form called "asdot+" which looks like x.y , where x and y are 16-bit numbers. Numbers of

432-472: A number of decision factors, more than the ones that are used by any other common routing process, for selecting NLRI to go into the Loc-RIB. The first decision point for evaluating NLRI is that its next-hop attribute must be reachable (or resolvable). Another way of saying the next-hop must be reachable is that there must be an active route, already in the main routing table of the router, to the prefix in which

480-492: A peer to every other router. This causes scaling problems, since the number of required connections grows quadratically with the number of routers involved. To alleviate the problem, BGP implements two options: route reflectors (RFC 4456) and BGP confederations (RFC 5065). The following discussion of basic update processing assumes a full iBGP mesh. A given BGP router may accept network-layer reachability information (NLRI) updates from multiple neighbors and advertise NLRI to

528-430: A prefix to only North American peering customers. Instead, an ISP generally publishes a list of well-known or proprietary communities with a description for each one, which essentially becomes an agreement of how prefixes are to be treated. Examples of common communities include: An ISP might state that any routes received from customers with following examples: The customer simply adjusts their configuration to include

SECTION 10

#1732791521902

576-591: A single and clearly defined routing policy. In March 1996, the newer definition came into use because multiple organizations can run BGP using private AS numbers to an ISP that connects all those organizations to the Internet. Even though there may be multiple autonomous systems supported by the ISP, the Internet only sees the routing policy of the ISP. That ISP must have an officially registered ASN. Until 2007, AS numbers were defined as 16-bit integers, which allowed for

624-523: A state variable that tracks which of these six states the session is in. The BGP defines the messages that each peer should exchange in order to change the session from one state to another. The first state is the Idle state. In the Idle state, BGP initializes all resources, refuses all inbound BGP connection attempts and initiates a TCP connection to the peer. The second state is Connect. In the Connect state,

672-452: A type field. The extended format consists of one or two octets for the type field followed by seven or six octets for the respective community attribute content. The definition of this Extended Community Attribute is documented in RFC 4360. The IANA administers the registry for BGP Extended Communities Types. The Extended Communities Attribute itself is a transitive optional BGP attribute. A bit in

720-506: Is a standardized exterior gateway protocol designed to exchange routing and reachability information among autonomous systems (AS) on the Internet . BGP is classified as a path-vector routing protocol , and it makes routing decisions based on paths, network policies, or rule-sets configured by a network administrator . BGP used for routing within an autonomous system is called Interior Border Gateway Protocol ( iBGP ). In contrast,

768-498: Is also included in other sets in ARIN (AS-INCAPSULA) and APNIC (AS-IMCL). Another AS-SET sources can be RADB, LEVEL3 ( tier 1 network now called Lumen Technologies ) and also ARIN has ARIN-NONAUTH source of AS-SETs. AS-SETs are created by network operators in an Internet Routing Registry (IRR), like other route objects, and can be included in other AS-SETs and even form cycles. AS-SET names usually start with "AS-", but can also have

816-504: Is an error it is because one of the fields in the OPEN or UPDATE message does not match between the peers, e.g., BGP version mismatch, the peering router expects a different My AS, etc. The router then sends a Notification message to the peer indicating why the error occurred. Example of NOTIFICATION Message KeepAlive messages are sent periodically, to verify that remote peer is still alive. keepalives should be sent at intervals of one third

864-408: Is called External BGP ( eBGP or Exterior Border Gateway Protocol ). Routers on the boundary of one AS exchanging information with another AS are called border or edge routers or simply eBGP peers and are typically connected directly, while iBGP peers can be interconnected through other intermediate routers. Other deployment topologies are also possible, such as running eBGP peering inside

912-477: Is outside the scope of the standard. For example, the community attribute (see below) is not directly used by the BGP selection process. The BGP neighbor process can have a rule to set local preference or another factor based on a manually programmed rule to set the attribute if the community value matches some pattern-matching criterion. If the route was learned from an external peer the per-neighbor BGP process computes

960-576: Is to advertise the value, typically based on delay, of multiple ASs that have a presence at an IXP , that they impose to send traffic to some destination. Some routers (like Juniper) will use the Metric from OSPF to set MED. Examples of MED used with BGP when exported to BGP on Juniper SRX note: "Marker" and "Length" is omitted from the examples. Example of Open Message Only changes are sent, after initial exchange, only difference (add/change/removed) are sent. Example of UPDATE Message If there

1008-404: Is used as a generalized signaling protocol to carry information about routes that may not be part of the global Internet, such as VPNs. In order to make decisions in its operations with peers, a BGP peer uses a simple finite state machine (FSM) that consists of six states: Idle; Connect; Active; OpenSent; OpenConfirm; and Established. For each peer-to-peer session, a BGP implementation maintains

SECTION 20

#1732791521902

1056-668: The Adj-RIB-In , Adj-RIB-Out and the Loc-RIB together in the same data structure, with additional information attached to the RIB entries. The additional information tells the BGP process such things as whether individual entries belong in the Adj-RIBs for specific neighbors, whether the peer-neighbor route selection process made received policies eligible for the Loc-RIB , and whether Loc-RIB entries are eligible to be submitted to

1104-442: The holdtime . Example of KEEPALIVE Message Defined in RFC 7313 . Allows for soft updating of Adj-RIB-in , without resetting connection. Example of ROUTE-REFRESH Message BGP is "the most scalable of all routing protocols." Autonomous system (Internet) This is an accepted version of this page An autonomous system ( AS ) is a collection of connected Internet Protocol (IP) routing prefixes under

1152-491: The Internet Assigned Numbers Authority (IANA). The IANA also maintains a registry of ASNs which are reserved for private use (and should therefore not be announced to the global Internet). Originally, the definition required control by a single entity, typically an Internet service provider (ISP) or a very large organization with independent connections to multiple networks, that adhered to

1200-414: The route-maps mechanism. This mechanism consists of a set of rules. Each rule describes, for routes matching some given criteria, what action should be taken. The action could be to drop the route, or it could be to modify some attributes of the route before inserting it in the routing table. During the peering handshake, when OPEN messages are exchanged, BGP speakers can negotiate optional capabilities of

1248-517: The "Opaque Extended Community", the "Route Target Community", and the "Route Origin Community". A number of BGP QoS drafts also use this Extended Community Attribute structure for inter-domain QoS signalling. With the introduction of 32-bit AS numbers, some issues were immediately obvious with the community attribute that only defines a 16-bit ASN field, which prevents the matching between this field and

1296-464: The Adj-RIB-In, any routes that are withdrawn by the neighbor. Whenever a conceptual Adj-RIB-In changes, the main BGP process decides if any of the neighbor's new routes are preferred to routes already in the Loc-RIB. If so, it replaces them. If a given route is withdrawn by a neighbor, and there is no other route to that destination, the route is removed from the Loc-RIB and no longer sent by BGP to

1344-433: The BGP route to the destination will not be put into the routing table. Once the interface goes down, and there are no more preferred routes, the Loc-RIB route would be installed in the main routing table. BGP carries the information with which rules inside BGP-speaking routers can make policy decisions. Some of the information carried that is explicitly intended to be used in policy decisions are: The BGP standard specifies

1392-433: The ISP assigns to advertised routes instead of using MED (the effect is similar). The community attribute is transitive, but communities applied by the customer very rarely propagated outside the next-hop AS. Not all ISPs give out their communities to the public. The BGP Extended Community Attribute was added in 2006, in order to extend the range of such attributes and to provide a community attribute structuring by means of

1440-506: The Internet application of the protocol is called Exterior Border Gateway Protocol ( EBGP ). The genesis of BGP was in 1989 when Kirk Lougheed , Len Bosack and Yakov Rekhter were sharing a meal at an IETF conference. They famously sketched the outline of their new routing protocol on the back of some napkins, hence often referenced to as the “Two Napkin Protocol”. It was first described in 1989 in RFC 1105, and has been in use on

1488-515: The Internet since 1994. IPv6 BGP was first defined in RFC   1654 in 1994, and it was improved to RFC  2283 in 1998. The current version of BGP is version 4 (BGP4), which was first published as RFC  1654 in 1994, subsequently updated by RFC  1771 in 1995 and RFC  4271 in 2006. RFC 4271 corrected errors, clarified ambiguities and updated the specification with common industry practices. The major enhancement of BGP4

Seattle Internet Exchange - Misplaced Pages Continue

1536-544: The OpenConfirm state. Keepalive messages are exchanged and, upon successful receipt, the router is placed into the Established state. In the Established state, the router can send and receive: Keepalive; Update; and Notification messages to and from its peer. In the simplest arrangement, all routers within a single AS and participating in BGP routing must be configured in a full mesh: each router must be configured as

1584-787: The block assigned by IANA. Entities wishing to receive an ASN must complete the application process of their RIR, LIR or upstream service provider and be approved before being assigned an ASN. Current IANA ASN assignments to RIRs can be found on the IANA website. RIRs, as part of NRO , can revoke AS numbers as part of their Internet governance abilities. There are other sources for more specific data: A complete table of available 16-bit and 32-bit ASN: Autonomous systems (AS) can be grouped into four categories, depending on their connectivity and operating policy. Autonomous systems can be included in one or more AS-SETs, for example AS-SET of RIPE NCC "AS-12655" has AS1, AS2 and AS3 as its members, but AS1

1632-583: The control of one or more network operators on behalf of a single administrative entity or domain, that presents a common and clearly defined routing policy to the Internet. Each AS is assigned an autonomous system number ( ASN ), for use in Border Gateway Protocol (BGP) routing. Autonomous System Numbers are assigned to Local Internet Registries (LIRs) and end-user organizations by their respective Regional Internet Registries (RIRs), which in turn receive blocks of ASNs for reassignment from

1680-407: The correct community or communities for each route, and the ISP is responsible for controlling who the prefix is advertised to. The end user has no technical ability to enforce correct actions being taken by the ISP, though problems in this area are generally rare and accidental. It is a common tactic for end customers to use BGP communities (usually ASN:70,80,90,100) to control the local preference

1728-419: The form 0.y are exactly the old 16-bit AS numbers. The special 16-bit ASN 23456 ("AS_TRANS") was assigned by IANA as a placeholder for 32-bit ASN values for the case when 32-bit-ASN capable routers ("new BGP speakers") send BGP messages to routers with older BGP software ("old BGP speakers") which do not understand the new 32-bit ASNs. The first and last ASNs of the original 16-bit integers (0 and 65,535) and

1776-485: The last ASN of the 32-bit numbers (4,294,967,295) are reserved and should not be used by operators; AS0 is used by all five RIRs to invalidate unallocated space. ASNs 64,496 to 64,511 of the original 16-bit range and 65,536 to 65,551 of the 32-bit range are reserved for use in documentation. ASNs 64,512 to 65,534 of the original 16-bit AS range, and 4,200,000,000 to 4,294,967,294 of the 32-bit range are reserved for Private Use. The number of unique autonomous networks in

1824-400: The local router's routing table management process. BGP submits the routes that it considers best to the main routing table process. Depending on the implementation of that process, the BGP route is not necessarily selected. For example, a directly connected prefix, learned from the router's own hardware, is usually most preferred. As long as that directly connected route's interface is active,

1872-449: The main routing table manager. If the router does not have a route to that destination from any non-BGP source, the withdrawn route will be removed from the main routing table. As long as there is tiebreaker the route selection process moves to the next step. By default Internal IGP is not added. Can be set to add IGP metric. Before the most recent edition of the BGP standard, if an update had no MED value, several implementations created

1920-452: The next-hop address is reachable. Next, for each neighbor, the BGP process applies various standard and implementation-dependent criteria to decide which routes conceptually should go into the Adj-RIB-In. The neighbor could send several possible routes to a destination, but the first level of preference is at the neighbor level. Only one route to each destination will be installed in the conceptual Adj-RIB-In. This process will also delete, from

1968-502: The peer. Jumbo frame peering at 9000-byte maximum transmission unit (MTU) is available. The following is a list of SIX extensions: Border Gateway Protocol Early research and development: Merging the networks and creating the Internet: Commercialization, privatization, broader access leads to the modern Internet: Examples of Internet services: Border Gateway Protocol ( BGP )

Seattle Internet Exchange - Misplaced Pages Continue

2016-449: The real ASN value. Since RFC 7153, extended communities are compatible with 32-bit ASNs. RFC 8092 and RFC 8195 introduce a Large Community attribute of 12 bytes, divided in three field of 4 bytes each (AS:function:parameter). MEDs, defined in the main BGP standard, were originally intended to show to another neighbor AS the advertising AS's preference as to which of several links are preferred for inbound traffic. Another application of MEDs

2064-640: The router waits for the TCP connection to complete and transitions to the OpenSent state if successful. If unsuccessful, it starts the ConnectRetry timer and transitions to the Active state upon expiration. In the Active state, the router resets the ConnectRetry timer to zero and returns to the Connect state. In the OpenSent state, the router sends an Open message and waits for one in return in order to transition to

2112-439: The routing system of the Internet exceeded 5,000 in 1999, 30,000 in late 2008, 35,000 in mid-2010, 42,000 in late 2012, 54,000 in mid-2016 and 60,000 in early 2018. The number of allocated ASNs exceeded 100,000 as of March 2021. AS numbers are assigned in blocks by Internet Assigned Numbers Authority (IANA) to regional Internet registries (RIRs). The appropriate RIR then assigns ASNs to entities within its designated area from

2160-401: The same, or a different set, of neighbors. The BGP process maintains several routing information bases : The physical storage and structure of these conceptual tables are decided by the implementer of the BGP code. Their structure is not visible to other BGP routers, although they usually can be interrogated with management commands on the local router. It is quite common, for example, to store

2208-548: The session, including multiprotocol extensions and various recovery modes. If the multiprotocol extensions to BGP are negotiated at the time of creation, the BGP speaker can prefix the Network Layer Reachability Information (NLRI) it advertises with an address family prefix. These families include the IPv4 (default), IPv6, IPv4/IPv6 Virtual Private Networks and multicast BGP. Increasingly, BGP

2256-402: The type field within the attribute decides whether the encoded extended community is of a transitive or non-transitive nature. The IANA registry therefore provides different number ranges for the attribute types. Due to the extended attribute range, its usage can be manifold. RFC 4360 exemplarily defines the "Two-Octet AS Specific Extended Community", the "IPv4 Address Specific Extended Community",

2304-539: Was the support for Classless Inter-Domain Routing (CIDR) and use of route aggregation to decrease the size of routing tables . RFC  4271 allows BGP4 to carry a wide range of IPv4 and IPv6 "address families". It is also called the Multiprotocol Extensions which is Multiprotocol BGP (MP-BGP). BGP neighbors, called peers, are established by manual configuration among routers to create

#901098