Lessons learned:
BGP:
Open standards based
-RFC 4271, BGP 4
Classless path vector routing protocol
-Used multiple attributes fo routing decisions
-Supports VLSM and summarization
-Extensible
--IPv4 Mulitcast, IPv6, MPLS, etc.
BGP on Cisco’s Site:
BGP is an open standards protocol – it’s considered a path
vector protocol. IGP’s are making decision based on one value, the metric to
reach a destination, choosing the lowest path end to end. With BGP was originally
implemented with Policy in mind where the individual attributes are on a per
route based, this will determine how we route to a destination.
BGP supports VLSM and summarization. With the size of the global
table growing constantly it’s important to be able summarize prefix
information.
Many sites offer routers that you can login to and view the global
BGP table called “route-views or route-servers.
Ex: route-server.ip.att.net – they’re basically just routers
online that you can connect to. We can use these to check policies we’re trying
to apply to our outbound advertisements as they pertain to the global internet.
EX: connect to router and login as rviews with a password or
rviews…
rviews@route-server.ip.att.net>
You can login and see on average the size of the global BGP
table.
You can also get a list of Route-servers here: http://www.netdigix.com/servers.html
Example os “s hip bgp sum” off a route-view server:
route-views>sh ip bgp summary
BGP router identifier 128.223.51.103, local AS number 6447
BGP table version is 1192614054, main routing table version
1192614054
521135 network
entries using 68789820 bytes of memory à
this says we currently have 521135 entries
15209495 path entries
using 790893740 bytes of memory à this says’ there are
over 15209495 paths to reach these entries.
2508169/94266 BGP path/bestpath attribute entries using
421372392 bytes of memory
2166488 BGP AS-PATH entries using 86870842 bytes of memory
66927 BGP community entries using 5058824 bytes of memory
396 BGP extended community entries using 12842 bytes of
memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1372998460 total bytes of memory
Dampening enabled. 11709 history paths, 16038 dampened paths
BGP activity 878512/333647 prefixes, 50876541/35465181
paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer
InQ OutQ Up/Down State/PfxRcd
4.69.184.193 4 3356 7842992 73921 1192614065 0 0
4w5d 490479
----------------------------------------------------
BGP is extensible, it can be used for more than just IP unicast
routing.
----------------------------------------------------
BGP ASNs
Autonomous Systems (AS) per RFC 4271 -
-A set of routers under a single technical administration,
using and interior gateway protocol (IGP) and common metrics to determine how
to router packets within the AS, and using and inter-AS routing protocol to
determine how to route packets to other ASes,
-ASNs are allocated by Internet Assigned Numbers Authority
(IANA).
In general a routing policy will apply for the AS as a
whole, where the policy for AS1 is different from AS2, etc.
Note: Routers inside an AS need to reachability first, in
reality BGP is not a routing protocol – it’s an application that manly designed
to do two things.
It’s designed to advertise an IP Prefix and a next-hop value
associated with that prefix.
The design issue - the next hop value that BGP reports must
then be recused through some other IGP routing protocol. BGP will rely on
EIGRP, OSPF etc. BGP is for destinations outside our network that we’re trying
to reach.
The AS numbers themselves are assigned by IANA.
There’s recently been a change in the format that the AS
number use:
Original 2-byte field
-Values 0 – 65535
-Public ASNs 1 – 64511
Private ASNs 64512 – 65535 (1024 addresses) Similar to RFC
1918
Currently 4- byte
field
-RFC 4893 BGP Support for Four-octet AS Number Space
-IOS supports as of 12.4. (24)T
As of today almost all 2 byte field AS’s have been
allocated.
4-Byte BGP ASNs
-
0.0 – 65535.65535 notation
-
0.{0-65535) denote original 2-byte ASNs
Requires backwards compatibility with old code
-4 Byte ASN support negotiated during capability exchange
-old BGP speakers are sent ASdot numbers encoded as ASN “23456”
– from the perspective of the IOS versions that DO NOT support the AS4 numbers,
the will see everyone that has the 4 byte value represented AS number 23456.
This doesn’t mean the information will be lost.
-Real AS-Path encoded with optional transitive attributes
AS4_AGGREGATOR and AS4_PATH –
Establishing BGP
Peerings:
Like IGP, first step in BGP is to find neighbors to exchange
information with
The actual logic BGP for establishing the updates, routing
the traffic etc is the same as we use in our IGP.
For example in EIGRP and OSFP our first step is to figure
out who are our neighbors on our connected links that we want to run our protocols
on.
Once we find the neighbors we go through an adjacency
negotiation where we define attributes, Area #, etc.
Once neighbors come up we exchange information and then we
can do the path selection.
Same type logic in BGP –
First step is how do we establish the peering?
Unlike IGP….
-BGP does not have its own transport – EX: OSPF used IP protocol
# 89, EIGRP # 88. BGP runs on top of TCP. This implies the BGP neighbors would
have to have IGP reachability before they can peer BGP. Since BGP is a Standard
TCP application, the normal Client/Server Roles of TCP are going to apply.
-BGP has different types of neighbors – IBGP – EBGP – Route reflectors,
etc. this will control how updates are process and best path sections.
-BGP neighbors are not discovered – Neighbors are not dynamically
discovered – unlike IGPs that use Multicast. Peerings are based on unicast
neighbor statements under the process.
-BGP neighbors do not have to be connected – Because TCP is
the transport protocol.
BGP Transport:
BGP uses TCP port 179
for transport
-implies the BGP needs IGP First.
BGP Neighbor
statement tell process to….
-listen for remote address via TCP 179
-initiate a session to remote address via TCP 179
-if collision, higher router-id becomes TCP client. Can happen
if client and server try to establish at same time
Normally the client
will initiate the session over port 179.
Handshake Example:
R1 -- > < --R2
1)
R1 Sends TCP Syn packet with a random Source port
and a Destination port of 179 (if R2 is configured to accept the session from
R1)
2)
R2 replies with the second portion of the
handshake – With a TCP ACK and SYN packet (TCP SYN ACK) saying I also want to
start a session.
3)
R2 will send its TCP ACK with the source port of
179 and the destination of a random negotiate value.
4)
Then R1 will reply with a TCP ACK – then the
session is fully open.
Key point – is that
R1 will always be sending traffic toward 179 and R2 will sending traffic from
port 179.
BGP Peering types:
External BGP (EBGP) Peers
-Neighbors outside my Autonomous System
Internal BGP (iBGP) Peers
-Neighbors inside my AS
Update and path selection rules change depending on what
type of peer a route is being sent to/received from.
EBGP Peering Rules:
EBGP packets default to TTL 1
-can be modified if neighbors are multiple hops away.
Ex:
--#neighbor (as # ) ebgp-multihop
(TTL)
--#neighbor (AS #) ttl-secuirty
hops (ttl) - Common today – used to prevent
against remote TCP reset attacks.
Note: these
commands are mutually exclusive - you would use one of the other, not both.
Non multi-hop peers must be directly connected by default.
-can be modified if connected neighbors peer via loopbacks
-# Neighbor disable-connected-check - This disabled the
connected check, normally this would be used based on Loopback addresses.
Note: The default behavior when a router goes to establish
an EBGP peering, if it looks in the routing table for the neighbors destination
address and it doesn’t find a directly connected route. Then the neighbor will
not send the “open” message. It won’t try to establish the 3-way-handshake.
Neighbor disable-connected-check – will disable this
behavior.
Loop prevention via
AS-Path
-Local ASN is “prepended” to outbound updates
-inbound updates containing local ASN are discarded
-Can be modified with # neighbor
allowas-in command.
Every time an update is send out to EBGP peers, we take out local
AS number and add it to the AS path attribute that is inside that actual
update.
The AS will track what AS’s this update when t through from the
originator to our local AS. This can also be seen by using the “route-view”
servers.
Ex:
route-views>sh ip bgp
Network Next Hop Metric LocPrf Weight Path
* 1.0.0.0/24 157.130.10.233 0 701 6453 15169 i
This output basically tells us that this route was originated
by AS 15169 – then through 6453 and then 701. So the local peer that eh AS is received
from is AS 3 701.
The number on the left most portion is the AS that we are learning
the AS from, the number on the right most portion is the prefix that the AS is originated
in.
Key point – whenever
we send an update outbound, we will take our own AS number and out it as the
first number is the AS path.
If for some reason we seen our AS number INBOUND – in the
path – then we will automatically filter that update out. Basic loop prevention
logic.
We can modify this with the # neighbor allowas-in command. In cases where we have the same AS number that
is separated by a different AS number in the middle.
EBGP Peering Rules:
Next-hop processing
-Outbound EBGP updates have local update-source for neighbor
set as next-hop.
-EX: if update source is loopback 0, next-hop is loopback0
Can be modified with route-map action “set ip next-hop” but
typically shouldn’t
-ex 3rd party next hop.
-------------------
When we send updates outbound, whatever the local address is
for that peering, is going to be the next hop value that goes into the next-hop
value of the route. Ex:
R1 and R2
Both routers peer via their loopback interfaces
R1
Loopback IP 1.1.1.1
R2
Loopback IP 2.2.2.2
R12 advertises 10.0.0.0 /24 -- > when this update is
advertised to R2 over the EBGP session, R2 will say the prefix 10.0.0.0 /24 is
reachable via the next-hop of 1.1.1.1
This implies that R2 will need an additional step in the route
recursion to figure out what is the local connected interface that R2 will use in
order to reach the destination 1.1.1.1
If we modify this we can use the route-map option but
typically you would not use this is a normal design.
This is normally called a 3rd part next hop –
this is where the local router is an update but then tell you to use some other
source in the data plane
In order to get there.
Example:
R1 – sends and update to R2 for prefix 10.0.0.0/24 and instead
of using the normal next-hop value – which would be whatever the update source
is from R1 to R2. We can tell R2 to user R3. (3.3.3.3)
This means the control plane for BGP is going to be between
R1 and R2. But then the actual data plane (actual traffic forwarding) would be
through some other device.
One of the flexible feature of BGP is that the control plane
is not actually tied to the data plane.
iBGP peering Rules.
iBGP Peering packets default to TTL 255
-implies neighbors do not have to be connected as long as
IGP reachability exists
Loop prevention via route filtering
- iBGP learned routes cannot be advertised on to another
iBGP neighbor.
-implies need for either….
-Fully meshed iBGP peerings – most efficient for selecting
correct path
-route reflection
-Confederation
--------------------------------------------------
Key note: there is no time to live on internal iBGP packets,
this means the neighbors do not have to be directly connected. As
Long as there’s IGP reachability in the internal network it
will allow us to establish the iBGP peering and ultimately advertise the prefixes.
Based on the next-hop process rules of iBGP, the control plane
message again does not have to follow- the actual data plane forwarding.
The loop prevention for iBGP uses a very simple concept. If
you learn a route form and iBGP neighbor – DON’T advertise it to another iBGP
neighbor.
Next-hop processing:
-outbound iBGP updates to not modify the next-hop attribute
regardless of iBGP type.
--iBGP peer
--Route reflectors client peer
--Route reflectors non-client peer
--confederation EBGP peer
Can be modified with the #next-hop-self or # route-map
Action set ip next-hop
This basically mean the original entry point for the route
is going to be maintained throughout all of the updates in the iBGP network.
Next hop value will always be the value that came from your
EBGP neighbor to begin with. Unless we use the next-hop self-command.
No comments:
Post a Comment