Tag - Tcp

BGP Adjacency States

BGP Adjacency States

  1. Idle State
  2. Connect State
  3. Active State
  4. OpenSent State
  5. OpenConfirm State
  6. Established State

1. Idle State:

Idle is the initial state of a BGP connection. The BGP speaker is waiting for a start event, generally either the establishment of a TCP connection or the re-establishment of a previous connection. Once the connection is established, BGP moves to the next state.

Attributes

  • Refuse all incoming BGP connections
  • Start the initialization of event triggers
  • Initiates a TCP connection with its configured BGP peer
  • Listens for a TCP connection from its peer
  • Changes its state to Connect

If an error occurs at any state of the FSM process, the BGP session is terminated immediately and returned to the Idle state. Some of the reasons why a router does not progress from the Idle state are:

  • TCP port 179 is not open
  • A random TCP port over 1023 is not open
  • Peer address configured incorrectly on either router
  • AS number configured incorrectly on either router

2. Connect State:

Connect is the next state of a BGP connection. If the TCP connection completes, BGP will move to the OpenSent stage if the connection does not complete, BGP goes to Active.

Attributes

  • Waits for successful TCP negotiation with peer
  • BGP does not spend much time in this state if the TCP session has been successfully established
  • Sends Open message to peer and changes state to OpenSent

If an error occurs, BGP moves to the Active state. Some reasons for the error are:

  • TCP port 179 is not open
  • A random TCP port over 1023 is not open
  • Peer address configured incorrectly on either router
  • AS number configured incorrectly on either router

3. Active State:

Active indicates that the BGP speaker is continuing to create a peer relationship with the remote router. If this is successful, the BGP state goes to OpenSent. You’ll occasionally see a BGP connection flap between Active and Connect. This indicates an issue with the physical cable itself, or with the configuration.

Attributes

  • If the router was unable to establish a successful TCP session, then it ends up in the Active state
  • BGP FSM tries to restart another TCP session with the peer and, if successful, then it sends an Open message to the peer
  • If it is unsuccessful again, the FSM is reset to the Idle state

Repeated failures may result in a router cycling between the Idle and Active states. Some of the reasons for this include:

  • TCP port 179 is not open
  • A random TCP port over 1023 is not open
  • BGP configuration error
  • Network congestion
  • Flapping network interface

4. OpenSent State:

OpenSent indicates that the BGP speaker has received an Open message from the peer. BGP will determine whether the peer is in the same AS (iBGP) or a different AS (eBGP) in this state.

Attributes

  • BGP FSM listens for an Open message from its peer
  • Once the message has been received, the router checks the validity of the Open message
  • If there is an error it is because one of the fields in the Open message doesn’t match between the peers, e.g., BGP version mismatch, MD5 password 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
  • If there is no error, a Keepalive message is sent, various timers are set and the state is changed to OpenConfirm

5. OpenConfirm State:

In OpenConfirm state, the BGP speaker is waiting for a keepalive message. If one is received, the state moves to Established, and the neighbor relationship is complete. It is in the Established state that update packets are actually exchanged.

Attributes

  • The peer is listening for a Keepalive message from its peer
  • If a Keepalive message is received and no timer has expired before reception of the Keepalive, BGP transitions to the Established state
  • If a timer expires before a Keepalive message is received, or if an error condition occurs, the router transitions back to the Idle state

6. Established State:

In Established state, if one of keepalive message is received, the state moves to Established, and the neighbor relationship is complete. It is in the Established state that update packets are actually exchanged.

Attributes

  • In this state, the peers send update messages to exchange information about each route being advertised to the BGP peer
  • If there is any error in the update message then a Notification message is sent to the peer, and BGP transitions back to the idle state
  • If a timer expires before a Keepalive message is received, or if an error condition occurs, the router transitions back to the Idle state

BGP-Adjacency-States

BOOTP client boot from a DHCP and BOOTPserver

15. Can a BOOTP client boot from a DHCP server?
Only if the DHCP server is specifically written to also handle BOOTP queries.

16. Can a DHCP client boot from a BOOTP server?
Only if the DHCP client were specifically written to make use of the answer from a BOOTP server. It would presumably treat a BOOTP reply as an unending lease on the IP address.

In particular, the TCP/IP stack included with Windows 95 does not have this capability.

17. Is a DHCP server “supposed to” be able to support a BOOTP client?
The RFC on such interoperability (1534) is clear: “In summary, a DHCP server: … MAY support BOOTP clients,” (section 2). The word “MAY” indicates such support, however useful, is left as an option.

A source of confusion on this point is the following statement in section 1.5 of RFC 1541: “DHCP must provide service to existing BOOTP clients.” However, this statement is one in a list of “general design goals for DHCP”, i.e. what the designers of the DHCP protocol set as their own goals. It is not in a list of requirements for DHCP servers.

18. Is a DHCP client “supposed to” be able to use a BOOTP server?
The RFC on such interoperability (1534) is clear: “A DHCP client MAY use a reply from a BOOTP server if the configuration returned from the BOOTP server is acceptable to the DHCP client.” (section 3). The word “MAY” indicates such support, however useful, is left as an option.

19. Can a DHCP client or server make a DNS server update the client’s DNS entry to match the client’s dynamically assigned address?
RFCs 2136 and 2137 indicate a way in which DNS entries can be updated dynamically. Using this requires a DNS server that supports this feature and a DHCP server that makes use of it. The RFCs are very recent (as of 5/97) and implementations are few. In the mean time, there are DNS and DHCP servers that accomplish this through proprietary means.

Back DHCP FAQ

Extended Access Control List

Extended ACL is implemented on the bases of source, Destination and Application. The application are telnet, ICMP, HTTP, SMTP etc it also work on port no of that application. As Remember that the router 1 ip scheme is 200.100.100.0 and Router2 ip scheme is 192.168.10.0

Extended Access Control List

 

 

To allow the traffic of Router 2 on Router 1 for every application

  • Router1(config)# Access-list 100 permit ip 192.168.10.0 0.0.0.255 200.100.100.0 0.0.0.255
  • Router1(config)# access-list 100 deny any any
  • Router1(config)# int s0
  • Router1(config_if)# ip access-group 100 in
  • Router1(config_if)# exit

 To allow all the traffic of Router 2 on Router 1 for 1st 7 computer

  • Router1(config)# Access-list 100 permit ip 192.168.10.0 ¬†0.0.0.255 200.100.100.0 0.0.0.7
  • Router1(config)# access-list 100 deny any any
  • Router1(config)# int s0
  • Router1(config_if)# ip access-group 100 in
  • Router1(config_if)# exit

 To block the traffic for pinging Router 1 from Router 2 computer

  • Router1(config)# Access-list 100 deny tcp 192.168.10.0 ¬†0.0.0.255 200.100.100.0 0.0.0.255 eq ICMP
  • Router1(config)# access-list 100 permit any any
  • Router1(config)# int s0
  • Router1(config_if)# ip access-group 100 in
  • Router1(config_if)# exit

 To allow the computer of Router 2 for just browsing the Web Server of the Router1 and the ip of the web server is 200.100.100.50

  • Router1(config)# Access-list 100 permit tcp
  • 192.168.10.0 0.0.0.0.255

200.100.100.50 0.0.0.0  eq 80 (or http)

  • Router1(config)# access-list 100 deny ip any any
  • Router1(config)# int s0
  • Router1(config_if)# ip access-group 100 in
  • Router1(config_if)# exit

Type of ACL

  1. Standard ACL (1-99)
  2. Extended ACL (100-999

Copyright ©2010 -  2019 Ciscoforall.com | Privacy Policy