The Border Gateway Protocol and Classless Inter-Domain Routing Allan Halme Seminar on...
-
Upload
gerard-mcbride -
Category
Documents
-
view
219 -
download
0
Transcript of The Border Gateway Protocol and Classless Inter-Domain Routing Allan Halme Seminar on...
The Border Gateway ProtocolThe Border Gateway Protocoland Classless Inter-Domain Routingand Classless Inter-Domain Routing
Allan HalmeAllan Halme
Seminar on Telecommunications TechnologyOctober 5, 1998
BGP.ppt / 5.10.1998 / AH page: 2
Classless Inter-Domain RoutingClassless Inter-Domain Routing
• Running out of class B addresses (half allocated by 1992)
• Routing tables getting too big
• Solution:
• Allocate consecutive class C addresses
• Addresses are contiguous and share the same most significant bits
• Routing protocols and routing tables need only refer to this “supernet” prefix only one entry needed in routing protocols
• Addresses are allocated by geographical region network numbers within a region share the same prefix can be referred to by a single entry in other regions’ routing tables “routing table aggregation”
• Enough addresses to 2000 (1995 estimate)
BGP.ppt / 5.10.1998 / AH page: 3
Regional AllocationRegional Allocation
• Continental division of class C addresses
• Multi-regional
• Europe
• North America
• Central/South America
• Pacific Rim
• Others
• Allocation of addresses is delegated hierarchically to regional authorities
• ie, RIPE (Réseaux IP Européens) -- Europe INRIA -- France
BGP.ppt / 5.10.1998 / AH page: 4
Address AssignmentsAddress Assignments
Organization Assignment
• requires fewer than 256 addresses 1 class C network
• requires fewer than 512 addresses 2 contiguous class C networks
• requires fewer than 1024 addresses 4 contiguous class C networks
• requires fewer than 2048 addresses 8 contiguous class C networks
• requires fewer than 4096 addresses 16 contiguous class C networks
• requires fewer than 8192 addresses 32 contiguous class C networks
• requires fewer than 16384 addresses 64 contiguous class C networks
BGP.ppt / 5.10.1998 / AH page: 5
The Border Gateway ProtocolThe Border Gateway Protocol
• The BGP is an inter-autonomous system routing protocol designed for TCP/IP systems; defined primarily in RFC 1771
• Learns multiple paths via internal and external BGP speakers
• Picks the best path and installs in the IP forwarding table
• Policies applied by influencing the best path selection
• Procedures in BGP
• Neighbor acquisition -- initial connection and initialization
• Neighbor reachability -- keeping track of the peer (keepalive)
• Network reachability -- maintain list of reachable prefixes and routes to them; maintain database by accepting updates from other BGP routers and forwarding updates onward
• The following BGP slides are based on Introduction to the Border Gateway Protocol (BGP) by Paul Ferguson, http://www.academ.com/nanog/feb1997/BGPTutorial/index.htm
BGP.ppt / 5.10.1998 / AH page: 6
BGP Between AS’sBGP Between AS’s
• eBGP between AS’s
• iBGP within single AS
BGP.ppt / 5.10.1998 / AH page: 7
• Defined in RFC 1930 “Guidelines for Creation,Selection, and Registration of an Autonomous System (AS)” as
Autonomous SystemsAutonomous Systems
OSPF network
RIP network
E
A
C D
B
AS X
AS Z AS T
AS Y
AS A
A connected group of one or more IP prefixes run by one or more network
operators which has a single and clearly defined routing policy.
• In practice, this is not totally strict
• ie, the case where an AS is transitioning from RIP to OSPF
BGP.ppt / 5.10.1998 / AH page: 8
Path Vectors and Path AttributesPath Vectors and Path Attributes
• Uses path vectors to indicate routes to destination prefixes
• Destination network is specified by subnet (“supernet”) prefix (à la CIDR)
• Route is sequence of AS’s to be traversed to reach AS that contains destination network
• Path vectors avoids routing loops
• Consumes memory (each destination prefix needs own AS route list), but within reason if CIDR is used
• Attributes describe a particular route
• Path attribute contains:
• Attribute type code (AS path, next hop, etc)
• Transitive / non-transitive (local)
• Mandatory (well-known) / optional
• Partially / fully evaluated by all routers in the AS path
BGP.ppt / 5.10.1998 / AH page: 9
Well-Known Attribute TypesWell-Known Attribute Types
• AS path
• Next hop
• Local preference
• Multi-exit discriminator (MED)
• Others
• Origin
• Communities
• ...
BGP.ppt / 5.10.1998 / AH page: 10
AS PathAS Path
• List of AS numbers to be traversed to reach destination prefix
• Loop detection (potential loop if own AS occurs in imported route)
BGP.ppt / 5.10.1998 / AH page: 11
Next Hop / eBGPNext Hop / eBGP
• IP address of next BGP router on the way to destination
• Usually local net in eBGP
BGP.ppt / 5.10.1998 / AH page: 12
Next Hop / iBGPNext Hop / iBGP
• Next hop of external routes not changed when announced to iBGP neighbors
BGP.ppt / 5.10.1998 / AH page: 13
Local PreferenceLocal Preference
• Local to AS
• Used to influence BGP path selection
• Path with highest local preference wins
BGP.ppt / 5.10.1998 / AH page: 14
Multi-exit Discriminator (MED)Multi-exit Discriminator (MED)
• Non-transitive
• Used to convey the relative preference of entry points
• Influences best path selection
• Comparable if paths are from same AS
• IGP metric can be conveyed as MED
BGP.ppt / 5.10.1998 / AH page: 15
Internal BGP (iBGP)Internal BGP (iBGP)
• Same routing protocol as BGP, different application
• iBGP should be used when AS_PATH information must remain intact between multiple eBGP peers
• All iBGP peers must be fully meshed, logically; an iBGP peer will not advertise a route learned by one iBGP peer to another iBGP peer (readvertisement restriction to prevent looping)
BGP.ppt / 5.10.1998 / AH page: 16
Scaling iBGP (1)Scaling iBGP (1)
• BGP Confederations
• Method to subdivide a single AS into multiple, internal sub-AS’s, yet still advertise a single AS to external peers
• Reduces iBGP mesh
BGP.ppt / 5.10.1998 / AH page: 17
Scaling iBGP (2)Scaling iBGP (2)
• BGP Route Reflectors (RR)
• Another method to reduce iBGP mesh
• iBGP re-advertisement restrictions are relaxed
• Single iBGP peer advertises (reflects) routes to subordinate iBGP peers
• Clients must not peer with RR’s outside of cluster
BGP.ppt / 5.10.1998 / AH page: 18
BGP InitializationBGP Initialization
• Open connection to peer router, TCP port 179
• Each sends OPEN message to other
• Possible errors include
• Version is unsupported send NOTIFICATION indicating supported versions and close TCP peer will probably retry specifying lower version number
• Collision each peer tries to connect to the other, results in 2 TCP connections one gets through first; the latter duplication is detected by noticing that the peer
is already listed in routing table
• Authentication and sanity checks
• Eg, peer is found in list of acceptable potential neighbors
• Peer identifier is a valid address, length field checks out
• Rejection indicated by NOTIFICATION message and closure of TCP
• Connection is accepted by sending KEEPALIVE message
• Routing tables are initialized by UPDATE messages
BGP.ppt / 5.10.1998 / AH page: 19
UpdatingUpdating
• Once initial connection is established, route information is exchanged with UPDATE messages
• Send only as needed
• KEEPALIVE responsible for monitoring neighbor reachability
• All known paths sent, using as many UPDATE messages as needed
• After initial exchange, new UPDATE messages are sent only when path information changes or new path information is received
• Upon receipt of new path information:
• If path is new, add to table
• If destination is unreachable, remove from table
• If path already exists, old path is replaced only if new path is shorter
• If update came from neighbor responsible for routing to path, update
• Forward new information to all other external neighbors
BGP.ppt / 5.10.1998 / AH page: 20
KeepaliveKeepalive
• Neighbor reachability / availability monitoring
• UPDATE messages are triggered only as necessary
• Not sufficient to merely send keepalives to neighbor
• BGP router expects also to receive keepalives from peer
• Hold time (negotiated at initialization) is the maximum delay during which BGP router should expect keepalive from peer
• If nothing heard, peer is assumed to be down NOTIFICATION is sent to peer TCP connection is closed
BGP.ppt / 5.10.1998 / AH page: 21
Error NotificationError Notification
• On receipt of faulty message or other error (ie, non-receipt of keepalive within hold time),
• NOTIFICATION message is sent to peer, and
• TCP connection is closed gracefully
• Errors
• Message Header Error (code 1)
• Unsupported Version Number (code 2, subcode 1)
• Bad Peer AS / Bad BGP Identifier (code 2, subcodes 2 & 3)
• Unsupported Authentication Code / Authentication Failure (code 2, subcodes 4 & 5)
• UPDATE Message Error Unrecognized Well-known Attribute, Attribute Flags Error, etc ...
• Hold Timer Expired (code 4)
• Finite-State Machine Error (code 5) reception of unexpected message, ie UPDATE before OPEN has been accepted