Monday, May 28, 2012

BGP Study FAQ

After Creating the Knowledge section document i decided to make some kind of FAQ of my theory notes , just to review them when necessary , they are not indeed the most comprehensive one, and neither sum up all the topics necessary but i find it useful to recall some knowledge when the time comes.

Feel Free to correct anything.


#BGP Study FAQ.


#General Knowledge Section.

Q: What is BGP

A: BGP is an Inter­Domain Routing Protocol also Known as an EGP.

Q: Which is the Current Version of BGP

A: BGP Version 4 (BGP­4).

Q: What kind of routing Protocol is BGP

A: BGP is a policy based routing protocol.

Q: How is BGP called when it is running inside an AS.

A: iBGP (Internal BGP).

Q: How is BGP called when it is running between different ASs.

A: eBGP (External BGP).

Q: Which are the three common ways to achieved multihoming with BGP.

A: Default routes from ISP

A: Default route + partial routes from ISP.

A: Full routing table from ISPs.


Q: What does BGP uses as transport protocol

A: BGP Information is carried inside TCP segments using protocol 179.

Q: How often does BGP sends keepalive messages

A: by default every 60 seconds.

#BGP neighbor Establishment and neighbor States.

Q: Which are the Requirements for an eBGP neighbor relationship

A: Different ASs

A: Neighbor Definition (TCP session).

A: IP reachability.

Q: Which are the requirements for an iBGP neighbor relationship.

A: Same AS

A: Neighbor Definition (TCP Session).

A: IP Reachability.

Q: Do iBGP neighbors need to be directly connected 

A: Routers running iBGP does not have to be directly connected as long as they
can reach each  other and establish a TCP Session.

Q: Can BGP use Broadcast.

A: Because TCP cannot use broadcasting. BGP cannot use it either.

Q: Why do iBGP neighbors requires a full mesh relation.

A: Because each iBGP router needs to send routes to all the other iBGP neighbors in the same AS,  and they cannot use broadcast, they must use fully meshed BGP (TCP) Sessions.

Q: Which are the BGP neighbor States
A: IDLE
A: CONNECT
A: ACTIVE
A: OPEN SENT
A: OPEN CONFIRM
A: ESTABLISHED


#Synchronization.

Q: What is BGP Sync

A: The BGP syn rule states that a BGP route should not use, or advertise to an external neighbor, a route learned by iBGP , unless that route is local or is learned from the IGP.

Q: When is necessary to enable sync

A: Syn should be enabled if there are router in the BGP transit path in the AS that are not running
BGP (and therefore do not have full­mesh iBGP within the AS).

#BGP Tables.

Q: Which tables do BGP uses.

A: BGP Table

A: BGP neighbor Table.

Q: Which is process is used to install routes in the routing table by BGP

A: After establishing an adjacency, the neighbors exchange their best BGP routes.And places them in the BGP forwarding Database.

A: The best routes from each network are selected from the BGP forwarding database using the BGP route-­selection process and then are offered to the IP routing table.

#BGP Message Types.

Q: Which are the main BGP message types.
A:Open
A:Keepalive
A:Update
A:Notification

Q: Which are the components of a Open message
A: Version
A: AS
A: Holdtime
A: BGP router ID
A: Optional Parameters.

Q: What does a update message contains

A: An update message has information on one path only.multiple paths require multiple messages.

Q: Which are the fields of an update message.

A: Withdrawn routes

A: Path attributes

A: Network layer reachability Information (NLRI).

Q: When is an Notification message used

A: A BGP router sends a nofitication message when it detects an error condition.

A: The BGP router closes the BGP connection immediately after sending the
Notification message.

#BGP attributes.

Q: How are BGP attributes categorized

A: Well known or optional

A: mandatory or discretionary

A: Transitive or non transitive

A: partial.

Q: What is a well-­known attribute

A: A well­-known attribute is one that all BGP implementations must recognize and
propagate to  BGP neighbors.

Q: Which are the types of well­-known attributes

A: Well-­known mandatory

A: Well­-known discretionary

Q: Which are the Optional attributes

A: Attributes that are not well-­known are called optional.

Q: Which are the types of optional attributes

A: Optional transitive

A: Optional Nontransitive

#AS­Path Attribute.

Q: What is the AS-­Path attribute

A: The AS-­path attribute is the list of AS system numbers that a router has
traversed to reach a destination. With the number of the AS that originated the route at the end of the list.

#The Next-­Hop Attribute

Q: What is the Next­Hop attribute

A: The BGP Next-­Hop attribute is a well-­known mandatory attribute that indicates the next-­hop IP address that is to be used to each a destination.


Q: For eBGP which is the next hop IP address.

A: for eBGP, the next ­hop address is the IP address of the neighbor that sent the update.

Q: how is the next hop behaviour on iBGP

A: For iBGP, the protocol states that the next hop advertised by eBGP should be carried into iBGP.

A: The iBGP neighboring router performs a recursive lookup to find out how to reach the BGP next-­hop address by using its IGP entries in the routing table.

Q: Which is the next hop behaviour on Multi­access networks

A: When running BGP over multiaccess networks suc as Ethernet, a BGP router uses the appropriate address as the next­hop address (by changing the next­hop attribute) to avoid inserting additional hops into the path.

#Origin Attribute.

Q: What is the origin attribute.

A: The Origin is a well-­known mandatory attribute that defines the origin of the path information.

Q: Which are the three values of the Origin attribute:

A: IGP: the route is interior to the originating AS this normally happens when a network command is used to advertise the route via BGP. Its indicated with an i in the bgp table.

A: EGP: the route is learned via EGP. this is indicated with an e in the BGP table.

A: Incomplete: the route`s origin is unknown or is learned via some other means. This usually occurs when a route is redistributed into BGP. An incomplete origin is indicated with a ? in the BGP table.

#Local Preference Attribute

Q: Which are the main characteristics of the Local preference Attribute.

A: Local Preference is a well-­known discretionary attribute that indicates to routers in the AS which path is the preferred to exit the Autonomous System.

A: A path with a higher local preference is preferred.

A: The default value for local preference on a cisco router is 100.

#Community Attribute

Q: What is the community attribute

A: The community attribute is a transitive, optional attribute. The community attribute is a way to  group destinations in a certain community and apply routing decisions according to those communities. The routing decisions are accept, prefer,  redistribute, among others.


#MED Attribute

Q: What kind of attribute is MED.

A: also called the metric, is an optional nontransitive attribute.

Q: What does the MED does

A: The MED indicates to external neighbors the preferred path into an AS.

A: A lower metric value is preferred.

Q: Which is the difference between MED and local preference

A: MED influences inbound traffic to an AS, whereas local preference influences outbound traffic  from an AS.

#Weight Attribute.

Q: What is the Weight attribute

A: The weight attribute is a Cisco ­Defined attribute used for path­ selection proccess. The weight attribute is configured locally and provides local routing policy only; it is not propagated to any  BGP neighbors.

Q: Which are the main characteristics of the Weight attribute.

A: Routes with a higher weight are preferred when multiple routes to the same destination exist.

A: The weight can have a value from 0 to 65535

A: Path that the router originates have a weight of 32768 by default. and other paths have a weight of 0 by default.

#BGP Route-­Selection Decision Process.

Q: On what is the BGP route­Selection Proccess based

A: The decision proccess is based on the attributes.

Q: Which condition makes a route to not be considered

A: A path is not considered if it is interal, sync is on, and the route is not synced, or if the path's next­hop address cannot be reached.

Q: How does BGP chooses the best route on a Cisco router

A: Weight

A: Local Pref

A: Originate (originate by the local router prefer).

A: AS

A: Origin (IGP/EGP/i=incomplete)

A: MED (lowest).

A: Paths (External over internals).

A: Router ID


#Other BGP features

#­Route Reflection.

Q: What is Route ­reflection.

A: Another solution for the explosion of iBGP peering within an AS. an iBGP speaker does not advertise a route that the BGP speaker learned via another iBGP speaker to a third iBGP speaker. You can relax this restriction a bit and provide additional control, which allows a router to advertise, or reflect, iBGP learned routes to other iBGP speakers.

Q: What is a BGP cluster

A: The combination of the RR and the clients is a "cluster".

Q: How does BGP treats more than one RR on a AS.

A: In this situation, an RR treats other RRs just like any other iBGP speaker. Other RRs can belong  to the same cluster (client group) or to other clusters.

Q: Which methods are used by RRs to avoid routing loops

A: originator-­id

A: cluster-­list.

Q: What is a cluster-­list

A: A cluster list is a sequence of clusters IDs, that the route has passed.

Q: What is necessary to configure a cluster with multiple RRs

A: You need to configure all RRs in the same cluster with a 4­byte cluster ID so that an RR can  recognize updates from RRs in the same cluster.

#Confederation.

Q: What does confederation consists of ?

A: Confederation reduces the iBGP mesh inside an AS.

A: The trick is to divide an AS into multiple ASs and assign the whole group to a single confederation. Each AS alone has iBGP fully messhed and has connections to other ASs inside the  confederation.

A: Even though these ASs have eBGP peers to ASs withing the confederation, the ASs exchange  routing as  if they used iBGP.

#Route Flap Dampening

Q: What is Route flap dampening.

A: Route dampening is a mechanism to minimize the instablility that route flapping causes.

Q: How does route flap dampening works

A: You define criteria to identify poorly behaved routes.

A: A route flap gets a penalty of 1000 for each flap.

A: As soon as the cumulative penalty reaches a predefined "supress limit" , supression of the route advertisement occurs.

A: The penalty decays exponentially based on a preconfigured "half­life time".

A: Once the penalty decreases below a predefined "reuse limit" , unsupression of the route advertisement occurs.

#BGP Configuration

# Configuring a Peer Group

Q: What is a peer group

A: Neighbors with the same update policies can be grouped into peer groups.

Q: Which commands are used to define a peer group.

A: Router(configrouter)#neighbor TEST peergroup

Q: Which command is used to assign a neighbor to a peer group

A: Router(configrouter)#neighbor 172.16.1.2 peergroup TEST

Q: Which command is used to reset all BGP connections for all members of a peer­group

A: Router#clear ip bgp peergroup TEST

#Neighbor Configuration.

Q: Which command is used to activate a BGP session

A: Router(configrouter)#neighbor 172.16.1.1 remoteas 65001

#Shutting Down a BGP neighbor

Q: Which command is used to disable (admin shutdown) an existing BGP neighbor or peer  group.

A: Router(configrouter)#neighbor 172.16.1.2 shutdown

Q: Which command is used to enable a previously existing neighbor or peer group that had been  disabled  using the neighbor shutdown command.

A: Router(configrouter)#no neighbor 172.16.1.2 shutdown

#Source IP address Definition

Q: Which command is used to define the update-­source interface

A: Router(configrouter)#neighbor 172.16.1.2 updatesource loopback0

#Neighbor Authentication

Q: Which command is used to enable MD5 authentication on a TCP connection between two BGP peers.

A: Router(configrouter)#neighbor 172.16.1.1 password 0 cisco

#Multihop

Q: Which command is used to configure eBGP multihop

A: Router(config­router)#neighbor 172.16.1.2 ebgpmultihop 2

#Next Hop attribute manipulation

Q: Which command is used to change the next­hop attribute

A: Router(config-­router)#neighbor 172.16.1.1 next-hop-­self

#Network Advertisement

#Defining networks to be advertised

Q: Which are the two options available to advertise networks in BGP

A: Using the network command.

A: Redistribute routes from an IGP into BGP.

Q: Which is the syntax of the network command

A: Router(config)#router bgp 65001
            Router(config­router)#network 172.16.1.0 mask 255.255.255.0

#auto­summary command

Q: What does the auto­summary determines on a BGP configuration.

A: The BGP auto summary router config command determines how BGP handles redistributed routes.

Q: Which command is used to configure auto­summary

A: Router(config-router)#autosummary
    Router(config-router)#no autosummary

#Sync

Q: Which command is used to configure Synchronization.

A: Router(configrouter)#synchronization
           Router(configrouter)#no synchronization

#Resetting BGP sessions.
   ­Hard Reset
   ­Soft Reset
   ­Route Refresh

Q: Which command is used to hard reset a BGP session.

A:R       Router#clear ip bgp *
          Router#clear ip bgp 172.16.1.2

Q: Which command is used to soft reset a BGP session.

A:         Router#clear ip bgp 172.16.1.2 soft out
           Router#clear ip bgp 172.16.1.2 out

Q: Which are the two ways to perform a soft reset for inbound sessions.

A: Using Stored routing update information

A: Dynamically (route refresh).

Q: Which commands are used to reset inbound sessions using stored routing update info

A: Router(configrouter)#neighbor 172.16.1.2 soft-­reconfiguration inbound

A: Router#clear ip bgp 172.16.1.2 soft in

Q: What is needed to configure a route refresh

A: THis new method requeres no preconfig

A: The clear ip bgp neighbor address soft in is the only command required.

Q: Which command is used to determine if a neighbor supports route­refresh

A: To determine whether a BGP router supports this route refresh capability, use the show ip bgp  neighbor command.

A: The following message is displayed in the output when the router supports the route refresh  capability: Received route refresh capability from peer.

#BGP show and debug commands

Q: Which command displays entries in the BGP topology database

A: show ip bgp

Q: Which command displays BGP routes that were not installed in the routing information base  (RIB), and the reason that they were not installed

A: show ip bgp rib­failure

Q: which command displays detailed information about the TCP and BGP connections to  neighbors

A: show ip bgp neighbor

Q: Which command displays the status of all BGP connections.

A: show ip bgp summary

Q: Which debug commands can be used to verify BGP operation

A: debug ip bgp

A: debug ip bgp dampening

A: debug ip bgp events

A: debug ip bgp keepalives

A: debug ip bgp updates.



#Troubleshooting BGP

Q: What does IDLE state indicates

A: The idle state indicates that the router does not know how to reach the IP address in the neighbor
statement.

Q: Which are the main reasons for this

A: It is waiting for a static route to that IP address or network to be configured

A: It is waiting for the local routing protocol (IGP) to learn about this network through an advertisement from another router.

Q: What does the Active state indicates

A: If the router is in the active state, this means that it has found the IP address in the neighbor  statement an has sent out a BGP open packet , but has not received a response.

Q: Which are the common causes for this.

A: One common cause of this is when the neighbor does not have a return route to the source IP  address.

A: another problem associated with the active state is when a BGP router attempts to peer with another BGP router that does not have a neighbor statement peering back at the first router.

Saturday, May 26, 2012

EBGP Neighbor Peering.

Lab Scenario:


Toplogy: 2 3745 With 128mb RAM.
IOS: C3745-ADVENTERPRISEK9-M.

This Basic topology its to cover basic peering between different ASs.

Considerations:

For a eBGP peering to be established there are some things that need to be filled first:

-Different Autonomous Systems (in this case 65501 , 65502).
-Neighbor Must be Reachable , meaning the IP address should be reachable so    BGP can establish a TCP session. ( In this case , network is a direct connection  between the two Routers).


With this Requirements Understood lets begin the Lab.

Initial Config:



R1:


!
hostname R1

!
!
!         
!
interface FastEthernet0/0
 description Connected_to_R2
 ip address 10.1.12.1 255.255.255.0
 duplex auto
 speed auto
!
!
!
!
line con 0
 exec-timeout 0 0
 logging synchronous
line aux 0
line vty 0 4
 login
!
!
end




R2:




hostname R2
!
!
interface FastEthernet0/0
 description Connected_to_R1
 ip address 10.1.12.2 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
!
!
!
line con 0
 exec-timeout 0 0
 logging synchronous
line aux 0
line vty 0 4
 login
!
!
end


1) To establish a BGP peering we need to configure the following paramerters on global and router-config modes:


R1 BGP Config:
R1(config)#router bgp 65501
R1(config-router)#neighbor 10.1.12.2 remote-as 65502

In this case we are Starting BGP process with AS (65501) with the router bgp 65501 command, then we proceed to specified the peering router parameters , the neighbor IP address 10.1.12.2 and the remote AS of the neighbor 65502.

The same must be done on R2.


R2 BGP Config:
R2(config)#router bgp 65502
R2(config-router)#neighbor 10.1.12.1 remote-as 65501

Verification:

After this commands are entered we should see the peering coming up:

*Mar  1 00:08:28.219: %BGP-5-ADJCHANGE: neighbor 10.1.12.2 Up

To verify the state of the neighbor we should use the show ip bgp summary , or the show ip bgp neighbor



R2#show ip bgp summary 
BGP router identifier 10.1.12.2, local AS number 65502
BGP table version is 1, main routing table version 1


Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.12.1       4 65501       4       4        1    0    0 00:01:43        0

Here we can determine the neighbor is in the established state with the blank state output of the state/PfxRcd. We can also see the peering router Ip address (The one used for the peering) the bgp table version, BGP version, the autonomous system of the peering router , message received , message sent  and the Up/down time.

R1#show ip bgp summary 
BGP router identifier 10.1.12.1, local AS number 65501
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.12.2       4 65502       4       4        1    0    0 00:01:10        0


Now the output from the show ip bgp neighbors command:

R1#sh ip bgp neighbors 
BGP neighbor is 10.1.12.2,  remote AS 65502, external link
  BGP version 4, remote router ID 10.1.12.2
  BGP state = Established, up for 00:32:06
  Last read 00:00:06, last write 00:00:06, hold time is 180, keepalive interval is 60 seconds
-output-omitted-

R2#show ip bgp neighbors 
BGP neighbor is 10.1.12.1,  remote AS 65501, external link
  BGP version 4, remote router ID 10.1.12.1
  BGP state = Established, up for 00:32:55
  Last read 00:00:55, last write 00:00:55, hold time is 180, keepalive interval is 60 seconds
-output-omitted-

Here we can see other parameters not shown on the show ip bgp summary command, like the type of link (external link) ,  router ID , neighbor  state , hold time and keep alive interval.


Now lets add some Prefixes to advertise.

Considering that BGP needs to match an entry in the routing table to advertise prefixes , i`ll add one loopback on each router.

R1:
R1(config)#int lo0
R1(config-if)#ip add 1.1.1.1 255.0.0.0

R2:
R2(config)#int l0
R2(config-if)#ip add 2.2.2.2 255.0.0.0

We can see both loopbacks added to the routing table as directly connected.

R1#sh ip route 
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C    1.0.0.0/8 is directly connected, Loopback0


R2#sh ip route 
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C    2.0.0.0/8 is directly connected, Loopback0

To advertise the routes on BGP:

R1:
R1(config)#router bgp 65501
R1(config-router)#network 1.0.0.0


R2(config)#router bgp 65502
R2(config-router)#network 2.0.0.0 mask 255.0.0.0

Here we added the respective loopbacks on each router. We used two different approaches, first the network 1.0.0.0 command without mask ( here BGP matches at the classfull boundary , /8 in this case which is precisely the mask used in the interface and the one listed earlier on the routing table. ) the other approach , the one used on R2 , network 2.0.0.0 mask 255.0.0.0 in this case we specified the mask which is also a /8 prefix ( if we had used another mask that do not match the prefix in the routing table it would not have been advertised).


Now lets verify if networks are being advertised. This is achieved with the show ip bgp , which shows the current BGP table.

R1#show ip bgp 
BGP table version is 3, local router ID is 10.1.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf   Weight   Path
*> 1.0.0.0          0.0.0.0                  0         32768 i
*> 2.0.0.0          10.1.12.2              0                        0      65502 i

R2#show ip bgp 
BGP table version is 3, local router ID is 10.1.12.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric  LocPrf   Weight   Path
*> 1.0.0.0          10.1.12.1                0                        0         65501 i
*> 2.0.0.0          0.0.0.0                  0                       32768 i


First thing to note its the change on the BGP table version, which is 3 in this case. Then we can see the prefixes on both routers , each one has a next-hop of the peering routers (as it should) , also we can learn that the routes are valid and best (which means they are installed in the routing table ) this is shown by the *> at the beginning  of the prefix under the network state, the network belonging to each routers have a next hop of 0.0.0.0 which is the local router. Under PATH we can see the ASs that the Packet traversed to get to this router, in this case is only the AS of the neighboring router.

To verify Installation of the routes in the routing table:

R1#sh ip route | incl B
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
B    2.0.0.0/8 [20/0] via 10.1.12.2, 00:43:52

R2#sh ip route | incl B
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
B    1.0.0.0/8 [20/0] via 10.1.12.1, 00:44:57


Peering established and routes advertised, we are all good to go. This is a pretty simple scenario of a EBGP peering just to remember the basics , next i`ll be posting some related to BGP multihop on eBGP scenarios , IBGP peering , Peer-groups and Peer-templates , authentication and the update-source and neighbor shutdown commands.


PD: Sorry for my bad english, feel free to correct any mistake related to BGP or english grammar :P .











RFC 2468.

Today searching around the internet i stumbled with this RFC (RFC 2468) the one which is kind of a orbituary to Jon Postel (Editor to the RFCs Admin of IANA until his death). Written by V. Cerf .


Network Working Group                                          V. Cerf
Request for Comments: 2468                                         MCI
Category: Informational                                   October 1998


                            

I REMEMBER IANA

October 17, 1998 Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Remembrance A long time ago, in a network, far far away, a great adventure took place! Out of the chaos of new ideas for communication, the experiments, the tentative designs, and crucible of testing, there emerged a cornucopia of networks. Beginning with the ARPANET, an endless stream of networks evolved, and ultimately were interlinked to become the Internet. Someone had to keep track of all the protocols, the identifiers, networks and addresses and ultimately the names of all the things in the networked universe. And someone had to keep track of all the information that erupted with volcanic force from the intensity of the debates and discussions and endless invention that has continued unabated for 30 years. That someone was Jonathan B. Postel, our Internet Assigned Numbers Authority, friend, engineer, confidant, leader, icon, and now, first of the giants to depart from our midst. Jon, our beloved IANA, is gone. Even as I write these words I cannot quite grasp this stark fact. We had almost lost him once before in 1991. Surely we knew he was at risk as are we all. But he had been our rock, the foundation on which our every web search and email was built, always there to mediate the random dispute, to remind us when our documentation did not do justice to its subject, to make difficult decisions with apparent ease, and to consult when careful consideration was needed. We will survive our loss and we will remember. He has left a monumental legacy for all Internauts to Cerf Informational [Page 1]

RFC 2468                    I REMEMBER IANA                 October 1998


   contemplate.  Steadfast service for decades, moving when others
   seemed paralyzed, always finding the right course in a complex
   minefield of technical and sometimes political obstacles.

   Jon and I went to the same high school, Van Nuys High, in the San
   Fernando Valley north of Los Angeles.  But we were in different
   classes and I really didn't know him then.  Our real meeting came at
   UCLA when we became a part of a group of graduate students working
   for Professor Leonard Kleinrock on the ARPANET project.  Steve
   Crocker was another of the Van Nuys crowd who was part of the team
   and led the development of the first host-host protocols for the
   ARPANET.  When Steve invented the idea of the Request for Comments
   series, Jon became the instant editor.  When we needed to keep track
   of all the hosts and protocol identifiers, Jon volunteered to be the
   Numbers Czar and later the IANA once the Internet was in place.

   Jon was a founding member of the Internet Architecture Board and
   served continuously from its founding to the present.  He was the
   FIRST individual member of the Internet Society I know, because he
   and Steve Wolff raced to see who could fill out the application forms
   and make payment first and Jon won.  He served as a trustee of the
   Internet Society.  He was the custodian of the .US domain, a founder
   of the Los Nettos Internet service, and, by the way, managed the
   networking research division of USC Information Sciences Institute.

   Jon loved the outdoors.  I know he used to enjoy backpacking in the
   high Sierras around Yosemite.  Bearded and sandaled, Jon was our
   resident hippie-patriarch at UCLA.  He was a private person but fully
   capable of engaging photon torpedoes and going to battle stations in
   a good engineering argument.  And he could be stubborn beyond all
   expectation.  He could have outwaited the Sphinx in a staring
   contest, I think.

   Jon inspired loyalty and steadfast devotion among his friends and his
   colleagues.  For me, he personified the words "selfless service".
   For nearly 30 years, Jon has served us all, taken little in return,
   indeed sometimes receiving abuse when he should have received our
   deepest appreciation.  It was particularly gratifying at the last
   Internet Society meeting in Geneva to see Jon receive the Silver
   Medal of the International Telecommunications Union.  It is an award
   generally reserved for Heads of State, but I can think of no one more
   deserving of global recognition for his contributions.

   While it seems almost impossible to avoid feeling an enormous sense
   of loss, as if a yawning gap in our networked universe had opened up
   and swallowed our friend, I must tell you that I am comforted as I
   contemplate what Jon has wrought.  He leaves a legacy of edited
   documents that tell our collective Internet story, including not only



Cerf                         Informational                      [Page 2]

RFC 2468                    I REMEMBER IANA                 October 1998


   the technical but also the poetic and whimsical as well.  He
   completed the incorporation of a successor to his service as IANA and
   leaves a lasting legacy of service to the community in that role.
   His memory is rich and vibrant and will not fade from our collective
   consciousness.  "What would Jon have done?", we will think, as we
   wrestle in the days ahead with the problems Jon kept so well tamed
   for so many years.

   There will almost surely be many memorials to Jon's monumental
   service to the Internet Community.  As current chairman of the
   Internet Society, I pledge to establish an award in Jon's name to
   recognize long-standing service to the community, the Jonathan B.
   Postel Service Award, which will be awarded to Jon posthumously as
   its first recipient.

   If Jon were here, I am sure he would urge us not to mourn his passing
   but to celebrate his life and his contributions.  He would remind us
   that there is still much work to be done and that we now have the
   responsibility and the opportunity to do our part.  I doubt that
   anyone could possibly duplicate his record, but it stands as a
   measure of one man's astonishing contribution to a community he knew
   and loved.

Security Considerations

   Security issues are not relevant to this Remembrance.

Author's Address

   Vinton G. Cerf
   MCI

   EMail: vcerf@mci.net

Wednesday, May 16, 2012

BGP Lab Scenarios Conceptualizations.

This are the Lab scenarios that i have formulated i need to know in order to master BGP basics and intermediate. Soon enough i`ll be posting my Notes/FAQ/Labs from my studies.


-Multi-homing with default route from both providers.
-Multi-homing with default routes and partial table from all providers.
-Multi-homing with full routes from All providers.
-Full-mesh iBGP
-Partial-mesh iBGP.
-Route Relfector scenarios.
-Confederation.
-Attributes (AS-PATH,NEXT-HOP,ORIGIN,LOCAL PREFERENCE, ATOMIC     AGGREGATE,AGGREGATOR,COMMUNITY,MULTIEXIT-DISCRIMINATOR [MED] ,  WEIGHT).
-BGP communities.
-Next Hop behaviour.
-Next Hop behaviour on Multiaccess networks.
-Next Hop behaviour on NBMA networks
-Next Hop Self.
-Local Preference.
-MED
-Weight
-Multi Path behaviour.
-Peer Groups.
-Peer Templates.
-Neighbor Shutdown.
-multihop.
-auto-summary behavior
-Neighbor authentication.
-Synchronization.
-Hard reset.
-Soft Reset.
-Route Refresh.
-BGP show and debug commands.
-BGP + route maps(local pref,AS-path,MED,Weight).
-BGP filtering
-BGP filtering with prefix lists.
-BGP filtering with route maps.
-BGP remove-private-as command.
-BGP Backdoor.
-BGP Dampening.

This is not comprehensive enough, there some features that are not on this list, but i plan to update it as soon as i encounter them.


Monday, May 14, 2012

BGP Knowledge Sections.

Aligned to some extent with the CCIE Routing and Switching v4.0 blueprint i managed to make my own knowledge section guide, just to categorize the domains needed to fully learn BGP. This helps me by deviding the knowledge i need to grasp of the protocols and technologies and focus in my weakness or new areas.


-General Concepts 
-BGP neighbor Establishment and neighbor States. 
-Synchronization. 
-BGP Tables. 
-BGP Message Types. 
-BGP attributes.
    -AS-Path Attribute 
    -The Next-Hop Attribute 
    -Origin Attribute. 
    -Local Preference Attribute 
    -Community Attribute. 
    -MED Attribute. 
    -Weight Attribute. 
    -Backdoor.
-BGP Route-Selection Decision Process. 
-Other BGP features.
    -Route Reflection. 
    -Confederation. 
    -Route Flap Dampening.
-BGP Configuration.
   -Peer Groups. 
   -Neighbor Configuration. 
   -Defining Neighbors 
   -Shutting Down a BGP neighbor. 
   -Source IP address Definition. 
   -Neighbor Authentication. 
   -Multihop -Load Balancing. 
   -Next Hop attribute manipulation. 
   -Network Advertisement. 
   -Defining networks to be advertised 
   -auto-summary command. 
   -BGP Filter List 
   -BGP filtering using Prefix Lists 
   -BGP filtering with Route Maps. 
   -Redistribution and Static Routes. 
   -Sync 
   -Resetting BGP sessions. 
     -Hard Reset 
     -Soft Reset 
     -Route Refresh 
  -BGP show and debug commands. 
  -BGP Path Manipulation. 
  -Changing the Weight 
  -Changing Weight using route maps 
  -Setting Local Preference 
  -Changing Local Preference Using Route Maps. 
  -Setting The AS-path. 
  -Setting the MED 
  -Changing the MED with a Route Map.
-Troubleshooting BGP

In the Beginning....

In the Beginning the noob arised... As a lot of blogs out there this one is to sum the Journey/Quest toward the infamous CCIE Routing and Switching. I`m guessing there`s not a lot to say with this kind of blogs, so i`ll stay focused on technical material (notes,labs,write ups, etc). I`m not an expert and neither have 10 years of experience right now i`m a humble Network Engineer at a finance company (for about 2 years) managing some 49 offices with a mix of wan connections (FR,ATM,ADSL,Wireless) in a Hub and spoke fashion , administering also (to less extend) Cisco call manager infraestructure , and until recently Cisco ASA and some other stuffs.