Routing

last person joined: 2 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  Curious behaviour of BGP State Machine

    Posted 08-01-2017 02:42

    Hi all,

    a friend of mine made the following trivial configuration:

     

    root@P1-1> show configuration routing-options

    router-id 192.168.1.11;

    autonomous-system 1234;

     

    root@P1-1> show configuration protocols bgp                                

    local-address 192.168.1.11;

    export NHS;

    group eBGP {

        type external;

        neighbor 1.2.3.4 {

            peer-as 2345;

        }

    }

    group iBGP {

        type internal;

        neighbor 2.2.2.2;

        neighbor 3.3.3.3;

    }

     

    All neighbor's IP address are completely invented, therefore not reachable (neither by a default-route nor by a supernet). I was expecting all sessions in the idle state, but curiously only the eBGP session is in the idle state, the iBGP sessions are in the active state. 

     

    root@P1-1> show bgp summary                                                

    Groups: 2 Peers: 3 Down peers: 3

    Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending

    inet.0                 0          0          0          0          0          0

    Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...

    1.2.3.4                2345          0          0       0       0     2:17:17 Idle 

    2.2.2.2                1234          0          0       0       0        5:25 Active

    3.3.3.3                1234          0          0       0       0        5:25 Active

     

    The same identical test made with a Cisco router gave all sessions in the idle state, as expected. 

    Does anybody have an idea of this strange Junos Behaviour ?

    Thanks a lot in advance.

    Tiziano

     



  • 2.  RE: Curious behaviour of BGP State Machine

    Posted 08-01-2017 21:57

    Show the interface configuration on all the devices that connect and the BGP configuration on all the other devices. IDLE - it cannot establish the TCP connection. ACTIVE - still trying to complete the the TCP connection

    >show system connections | match 179

    Also turn on trace options. BTW, why not use realistic IP address in a subnet range not on the internal network? Also why not use one of the internal AS numbers 64512 - 65534?



  • 3.  RE: Curious behaviour of BGP State Machine
    Best Answer

     
    Posted 08-02-2017 07:24

    Hi,

     

    By default eBGP [type external] has a ttl of 1, so the local-address [192.168.1.1] has to be present on a physical interface and if not present its stuck in idle state.

    Same applies when local-address is not configured at all on the device for iBGP, gets stuck in idle, but when lo0 is configured with 192.168.1.1, state changes to active - initiating TCP connection to peer.

     

    Tests reproduced below:

    ashvino@R1> show configuration protocols bgp
    local-address 192.168.1.1;
    group eBGP {
        type external;
        neighbor 1.2.3.4 {
            peer-as 2345;
        }
    }
    group iBGP {
        type internal;
        neighbor 2.2.2.2;
        neighbor 3.3.3.3;
    }

    ashvino@R1> show bgp summary Groups: 2 Peers: 3 Down peers: 3 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 0 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 1.2.3.4 2345 0 0 0 0 5 Idle 2.2.2.2 1234 0 0 0 0 5 Idle 3.3.3.3 1234 0 0 0 0 5 Idle

    Configure lo0.0 with 192.168.1.1, iBGP states move to active:

     

    ashvino@R1# set interfaces lo0 unit 0 family inet address 192.168.1.1/32
    
    [edit]
    ashvino@R1# commit and-quit
    commit complete
    Exiting configuration mode
    
    ashvino@R1> show bgp summary
    Groups: 2 Peers: 3 Down peers: 3
    Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
    inet.0
                           0          0          0          0          0          0
    Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
    1.2.3.4                2345          0          0       0       0        2:20 Idle
    2.2.2.2                1234          0          0       0       0        2:20 Active
    3.3.3.3                1234          0          0       0       0        2:20 Active
    
    ashvino@R1> show bgp neighbor 1.2.3.4
    Peer: 1.2.3.4 AS 2345          Local: 192.168.1.1 AS 1234
      Type: External    State: Idle           Flags: <PeerInterfaceError>
      Last State: NoState       Last Event: NoEvent
      Last Error: None
      Options: <Preference LocalAddress PeerAS Refresh>
      Local Address: 192.168.1.1 Holdtime: 90 Preference: 170
      Number of flaps: 0

     

    2 ways eBGP can move to active state:

    1. Multihop [Remove ttl restriction]

    ashvino@R1# set protocols bgp group eBGP multihop
    
    [edit]
    ashvino@R1# commit and-quit
    commit complete
    Exiting configuration mode
    
    ashvino@R1> show bgp summary
    Groups: 2 Peers: 3 Down peers: 3
    Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
    inet.0
                           0          0          0          0          0          0
    Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
    1.2.3.4                2345          0          0       0       0           2 Active
    2.2.2.2                1234          0          0       0       0        4:51 Active
    3.3.3.3                1234          0          0       0       0        4:51 Active

     

    2. Having a physical interface with eBGP peer address in same subnet [note "Local" changes for eBGP neighbor]:

    ashvino@R1# delete protocols bgp group eBGP multihop
    
    [edit]
    ashvino@R1# set interfaces ge-0/0/1 unit 0 family inet address 1.2.3.5/30
    
    [edit]
    ashvino@R1# commit and-quit
    commit complete
    Exiting configuration mode
    
    ashvino@R1> show bgp summary
    Groups: 2 Peers: 3 Down peers: 3
    Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
    inet.0
                           0          0          0          0          0          0
    Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
    1.2.3.4                2345          0          0       0       0           2 Active
    2.2.2.2                1234          0          0       0       0        7:20 Active
    3.3.3.3                1234          0          0       0       0        7:20 Active
    
    ashvino@R1> show bgp neighbor 1.2.3.4
    Peer: 1.2.3.4 AS 2345          Local: 1.2.3.5 AS 1234
      Type: External    State: Active         Flags: <>
      Last State: Idle          Last Event: Start
      Last Error: None
      Options: <Preference LocalAddress PeerAS Refresh>
      Local Address: 192.168.1.1 Holdtime: 90 Preference: 170
      Number of flaps: 0

    Removing address on lo0.0 -> iBGP: idle, eBGP: Active [due to physical interface 1.2.3.5]:

     

    ashvino@R1# delete interfaces lo0 unit 0
    
    [edit]
    ashvino@R1# commit and-quit
    commit complete
    Exiting configuration mode
    
    ashvino@R1> show bgp summary
    Groups: 2 Peers: 3 Down peers: 3
    Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
    inet.0
                           0          0          0          0          0          0
    Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
    1.2.3.4                2345          0          0       0       0        2:22 Active
    2.2.2.2                1234          0          0       0       0       19:17 Idle
    3.3.3.3                1234          0          0       0       0       19:17 Idle
    
    ashvino@R1> show bgp neighbor 1.2.3.4
    Peer: 1.2.3.4 AS 2345          Local: 1.2.3.5 AS 1234
      Type: External    State: Active         Flags: <>
      Last State: Idle          Last Event: Start
      Last Error: None
      Options: <Preference LocalAddress PeerAS Refresh>
      Local Address: 192.168.1.1 Holdtime: 90 Preference: 170
      Number of flaps: 0

    Add multihop to eBGP again brings eBGP to idle:

     

    ashvino@R1# set protocols bgp group eBGP multihop
    
    [edit]
    ashvino@R1# commit and-quit
    commit complete
    Exiting configuration mode
    
    ashvino@R1> show bgp summary
    Groups: 2 Peers: 3 Down peers: 3
    Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
    inet.0
                           0          0          0          0          0          0
    Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
    1.2.3.4                2345          0          0       0       0           3 Idle
    2.2.2.2                1234          0          0       0       0       21:04 Idle
    3.3.3.3                1234          0          0       0       0       21:04 Idle
    
    ashvino@R1> show bgp neighbor 1.2.3.4
    Peer: 1.2.3.4 AS 2345          Local: 192.168.1.1 AS 1234
      Type: External    State: Idle           Flags: <PeerInterfaceError>
      Last State: NoState       Last Event: NoEvent
      Last Error: None
      Options: <Multihop Preference LocalAddress PeerAS Refresh>
      Local Address: 192.168.1.1 Holdtime: 90 Preference: 170
      Number of flaps: 0

    So, it seems that as long as a usable local-address is available, BGP will transition to connect, then active.

     

    As per Juniper documentation, state may go back to idle in case of other events, such as stop event.  This seems to imply that unless a stop event, it will stay in Active state.

     

    Cheers,

    Ashvin



  • 4.  RE: Curious behaviour of BGP State Machine

    Posted 08-03-2017 02:50

    Thanks a lot Ashwin, great explanation.