4737849
Description
Flashcards by Jonathan Brisson, updated more than 1 year ago
|
Created by Jonathan Brisson
over 8 years ago
|
|
| Question | Answer |
| BGPv4 message header format. How long is the header and what is the name of his field | 19 octets Marker: This 16-octet field is included for compatibility; it MUST be set to all ones. Length: This 2-octet unsigned integer indicates the total length of the message, including the header in octets. Thus, it allows one to locate the (Marker field of the) next message in the TCP stream. The value of the Length field MUST always be at least 19 and no greater than 4096, and MAY be further constrained, depending on the message type. "padding" of extra data after the message is not allowed. Therefore, the Length field MUST have the smallest value required, given the rest of the message. Type: This 1-octet unsigned integer indicates the type code of the message |
| What is the type code of a BGP message: | RFC 2919 also introduce the type code 5 wich is route refresh |
| After a TCP connection is established, the first message sent by each side is an OPEN message. If the message is acceptable, what type of message is sent back to confirm the OPEN message is received? | If The OPEN message is acceptable, a KEEPALIVE message confirming the OPEN is sent back. Ref: RFC 4271 4.2 |
| Name the field of an OPEN Message: | Ref RFC 4271 4.2 |
| In a BGP OPEN message sent by a 4-byte AS number BGP Speaker. How his AS number is advertise | Ref RFC-6793. The My Autonomus system value is 23456. The real AS number is advertise in the Optional Parameters with the support for 4-octet AS number capability: |
| How is calculated the value of the Hold Time that will be use for a BGP Peering session? | Ref - RFC 4271 4.2 BGP speaker will use the smaller value configured from one of the two BGP peers. The hold time have to be 3 seconds or more ( or 0 ) |
| What Happen if a Peer doesn't support an optionnal parameter? | REF - RFC 4271&5492 If a BGP received an open message listing an unrecognized Optional Parameters, the speaker must terminate the BGP Peering by sending a notification message with the error subcode set to Unsupported Optional Parameter. |
| How does BGP speaker advertise their capability? | They advertise their capability in an optional Parameter called Capability. This allow BGP Speaker that support this optional parameter to establish the peering even if a speaker do not recognize a specific capability |
| Does an unsupported capability can prevent BGP Speaker to establish a peering? | Ref RFC-5492 Yes it can, but it depend on the capability. Ex a BGP speaker may need to terminate peering if it established peering to exchange IPv6 routes and determines that its peer does not support Multiprotocol Extensions for BGP-4 The Error Subcode in the NOTIFICATION message is then set to Unsupported Capability. The message MUST contain the capability or capabilities that cause the speaker to send the message. The decision to send the message and terminate the peering is local to the speaker. If terminated, such peering SHOULD NOT be re-established automatically |
| Name all the BGP Update Message Field. | |
| Name the field in the Path attributes field of an open message: | |
| Name the four flag used in the attribute field. | Bit 0 - Optional bit :It defines whether the attribute is optional (if set to 1) or well-known (if set to 0). Bit 1 - Transitive bit : It defines whether an optional attribute is transitive (if set to 1) or non-transitive (if set to 0). ** For well-known attribute, the transitive bit MUST be set to 1 Bit 2 - Partial bit: It defines whether the information contained in the optional transitive attribute is partial (if set to 1) or complete (if set to 0). ** For well-known attributes and for optional non-transitive attributes, The Partial bit MUST be set to 0 Bit 3 - Extended Length bit: It defines whether the Attribute Length is one octet (if set to 0) or two octets (if set to 1 |
| Name the Attributes type Codes: | |
| Name the Four Path Attributes Categories: | 1- Well-known Mandatory. 2- Well-known Discretionary 3- Optional transitive 4- Optional non-transitive |
| Name the Well-Known Mandatory Attributes | 1- ORIGIN 2- AS_PATH 3- NEXT_HOP Note that for Well-known attributes, the Transitive bit MUST be set to 1 |
| Name Well-Known Discretionary Attributes | 1- LOCAL_PREF 2- ATOMIC_AGGREGATE ** Local_Pref is Required in an update between iBGP Peers Atomic Aggregate SHOULD be included in the update if the aggregate exclued an AS number |
| Name Session Required ( Mandatory ) for each connection: | Ref RFC-4271 8. FSM The state session attribute indicates the current state of the BGP FSM. The ConnectRetryCounter indicates the number of times a BGP peer has tried to establish a peer session. ConnectRetryTime is a mandatory FSM attribute that stores the initial value for the ConnectRetryTimer. The suggested default value for the ConnectRetryTime is 120 seconds. ConnectRetryTime is a mandatory FSM attribute that stores the initial value for the ConnectRetryTimer. The suggested default value for the ConnectRetryTime is 120 seconds. The KeepaliveTime is a mandatory FSM attribute that stores the initial value for the KeepaliveTimer. The suggested default value for the KeepaliveTime |
| Name Optional Session Attributes for a connections: | |
| Which Optional(s) Attribute(s) are part of the Group 1: Automatic Administrative Events (Start/Stop) | 1- AllowAutomaticStart 2- AllowAutomaticStop 3- DampPeerOscillations 4- IdleHoldTime, IdleHoldTimer Ref RFC-4271 8.1. |
| Which Optional(s) Attribute(s) are part of the Group 2 : Unconfigured Peers | 1- AcceptConnectionsUnconfiguredPeers The BGP FSM optionally allows the acceptance of BGP peer connections from neighbors that are not pre-configured. The "AcceptConnectionsUnconfiguredPeers" optional session attribute allows the FSM to support the state transitions that allow the implementation to accept or reject these unconfigured peers. The acceptConnectionsUnconfiguredPeers has security implications. Please refer to the BGP Vulnerabilities document [RFC4272] for details |
| Which Optional(s) Attribute(s) are part of the Group 3 : TCP processing | 1- PassiveTcpEstablishment, 2- TrackTcpState Definition: PassiveTcpEstablishment: This option indicates that the BGP FSM will passively wait for the remote BGP peer to establish the BGP TCP connection. ( True or F 2- TrackTcpState The BGP FSM normally tracks the end result of a TCP connection attempt rather than individual TCP messages. Optionally, the BGP FSM can support additional interaction with the TCP connection negotiation. The interaction with the TCP events may increase the amount of logging the BGP peer connection requires and the number of BGP FSM changes. (True or False) |
| Which Optional(s) Attribute(s) are part of the Group 4: BGP Message Processing | 1- DelayOpen 2- DelayOpenTime 3- DelayOpenTimer 4- SendNOTIFICATIONwithoutOPEN, 5- CollisionDetectEstablishedState |
| Name all the Administrative Events | 1- ManualStart 2- ManualStop 3- AutomaticStart 4- ManualStart_with_ PassiveTcpEstablishment 5- AutomaticStart_with_ PassiveTcpEstablishment 6- AutomaticStart_with_ DampPeerOscillations 7- AutomaticStart_with_ DampPeerOscillations_and_ PassiveTcpEstablishment 8- AutomaticStop 9- ConnectRetryTimer_Expires 10- HoldTimer_Expires 11- KeepaliveTimer_Expires 12- DelayOpenTimer_Expires 13- IdleHoldTimer_Expires 14- TcpConnection_Valid 15- Tcp_CR_Invalid 16- Tcp_CR_Acked 17- TcpConnectionConfirmed 18- TcpConnectionFails 19- BGPOpen 20- BGPOpen with DelayOpenTimer running 21- BGPHeaderErr 22- BGPOpenMsgErr 23- OpenCollisionDump 24- NotifMsgVerErr 25- NotifMsg 26- KeepAliveMsg 27- UpdateMsg 28- UpdateMsgErr |
| Name the FSM ( Finite State Machine ) of BGP | 1- Idle 2- Connect 3- Active 4- OpenSent 5- OpenConfirm 6- Established |
Want to create your own Flashcards for free with GoConqr? Learn more.