Routing

last person joined: 3 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.  Problems peering between two iBGP peers

    Posted 01-30-2017 13:22

    I have two edge routers. They have a direct link that is p2p with ospf and then I run iBGP over that link. It's basically simple and straight out of the Juniper handbook   They both take full tables from their respective ISP's that are terminated in them  One router (R2) shows what I expect to be a normal full routing table AND shows the installed routes from it's peer. For example:

     

     

    inet.0: 627531 destinations, 1244831 routes (627530 active, 0 holddown, 1 hidden)
    + = Active Route, - = Last Active, * = Both
    
    1.0.4.0/24         *[BGP/170] 6d 02:15:23, localpref 100, from 172.17.3.1
                          AS path: 4323 3356 174 4826 38803 56203 I, validation-state: unverified
                        > to 10.0.0.1 via ge-0/1/9.0
                        [BGP/170] 00:52:05, MED 0, localpref 100, from 68.86.80.92
                          AS path: 26264 26264 26264 26264 7922 174 4826 38803 56203 I, validation-state: unverified
                        > to 50.233.71.125 via ge-0/0/1.0

     

    However, even though the iBGP configuration between the peers is in the "Established" state, I get totally different behaviour between the two.  Like I shared above, R2 gets it's ISP full tables (the one padded with 26264) and the tabled from R1.  On R2 I see the advertisement correctly:

     

    gsadmin@SSC-ERTR02> show route receive-protocol bgp 172.17.3.1        
    
    inet.0: 627576 destinations, 1244909 routes (627575 active, 0 holddown, 1 hidden)
      Prefix                  Nexthop              MED     Lclpref    AS path
    * 1.0.4.0/24              172.17.3.1                   100        4323 3356 174 4826 38803 56203 I
    * 1.0.5.0/24              172.17.3.1                   100        4323 3356 174 4826 38803 56203 I
    * 1.0.6.0/24              172.17.3.1                   100        4323 3356 174 4826 38803 56203 56203 56203 I
    * 1.0.64.0/18             172.17.3.1                   100        4323 2516 7670 18144 I
    * 1.0.128.0/17            172.17.3.1                   100        4323 3356 3491 3491 38040 9737 I
    * 1.0.128.0/18            172.17.3.1                   100        4323 3356 3491 3491 38040 9737 I
    * 1.0.128.0/19            172.17.3.1                   100        4323 3356 3491 3491 38040 9737 I
    * 1.0.128.0/24            172.17.3.1                   100        4323 3356 3491 3491 38040 23969 I
    * 1.0.129.0/24            172.17.3.1                   100        4323 3356 4651 23969 I
    * 1.0.131.0/24            172.17.3.1                   100        4323 3356 3491 3491 38040 23969 I
    * 1.0.132.0/22            172.17.3.1                   100        4323 3356 3491 3491 38040 23969 I

    and on R2 I am advertising correctly:

     

    gsadmin@SSC-ERTR02> show route advertising-protocol bgp 172.17.3.1
    
    inet.0: 627566 destinations, 1244882 routes (627565 active, 0 holddown, 1 hidden)
      Prefix                  Nexthop              MED     Lclpref    AS path
    * 1.11.0.0/21             Self                 0       100        26264 26264 26264 26264 7922 1239 9318 38091 18313 I
    * 1.11.8.0/21             Self                 0       100        26264 26264 26264 26264 7922 1239 9318 38091 18313 I
    * 1.11.16.0/21            Self                 0       100        26264 26264 26264 26264 7922 1239 9318 38091 18313 I
    * 1.11.24.0/21            Self                 0       100        26264 26264 26264 26264 7922 1239 9318 38091 18313 I
    * 1.11.32.0/21            Self                 0       100        26264 26264 26264 26264 7922 1239 9318 38091 18313 I
    * 1.11.40.0/21            Self                 0       100        26264 26264 26264 26264 7922 1239 3786 9457 38091 18313 I
    * 1.11.48.0/21            Self                 0       100        26264 26264 26264 26264 7922 1239 9318 38091 18313 I
    * 1.11.56.0/21            Self                 0       100        26264 26264 26264 26264 7922 1239 9318 38091 18313 I
    * 1.11.64.0/21            Self                 0       100        26264 26264 26264 26264 7922 1239 9318 38091 I
    * 1.11.72.0/21            Self                 0       100        26264 26264 26264 26264 7922 1239 9318 38091 I
    ~etc~

    However here is where the issue takes place.  On R1 the advertising is correct but it's acting like its not receiving anything from R2:

    gsadmin@SSC-ERTR01> show route receive-protocol bgp 172.17.3.2 
    
    inet.0: 620593 destinations, 620593 routes (620593 active, 0 holddown, 0 hidden)
    
    gsadmin@SSC-ERTR01> 

    and R1's BGP session is suspiciously absent of prefixes:

     

    gsweetadmin@SSC-ERTR01> show bgp neighbor 172.17.3.2 
    Peer: 172.17.3.2+53020 AS 26264 Local: 172.17.3.1+179 AS 26264
      Description: Local iBGP peering for DIA circuits
      Type: Internal    State: Established    Flags: <Sync>
      Last State: OpenConfirm   Last Event: RecvKeepAlive
      Last Error: Hold Timer Expired Error
      Export: [ next-hop-self ] 
      Options: <Preference LocalAddress Refresh>
      Local Address: 172.17.3.1 Holdtime: 90 Preference: 170
      Number of flaps: 1
      Last flap event: HoldTime
      Error: 'Hold Timer Expired Error' Sent: 1 Recv: 0
      Peer ID: 198.97.232.3    Local ID: 198.97.232.2      Active Holdtime: 90
      Keepalive Interval: 30         Group index: 0    Peer index: 0   
      BFD: disabled, down
      NLRI for restart configured on peer: inet-unicast
      NLRI advertised by peer: inet-unicast
      NLRI for this session: inet-unicast
      Peer supports Refresh capability (2)
      Stale routes from peer are kept for: 300
      Peer does not support Restarter functionality
      NLRI that restart is negotiated for: inet-unicast
      NLRI of received end-of-rib markers: inet-unicast
      NLRI of all end-of-rib markers sent: inet-unicast
      Peer supports 4 byte AS extension (peer-as 26264)
      Peer does not support Addpath
      Table inet.0 Bit: 10000
        RIB State: BGP restart is complete
        Send state: in sync
        Active prefixes:              0
        Received prefixes:            0
        Accepted prefixes:            0
        Suppressed due to damping:    0
        Advertised prefixes:          620594
      Last traffic (seconds): Received 2    Sent 3    Checked 19  
      Input messages:  Total 140170 Updates 8800    Refreshes 0     Octets 3457531
      Output messages: Total 12948952       Updates 12818134        Refreshes 0     Octets 1427317246
      Output Queue[0]: 0

    Note that accepted and received prefixes are 0.

     

    Configuration options for R1:

     

    > show configuration policy-options 
    policy-statement BGP-Prefixes {
        from protocol bgp;
        then accept;
    }
    policy-statement BGP-TimeWarner-IN {
        term Default {
            then accept;
        }
        term otherwise {
            then reject;
        }
    }
    policy-statement BGP-TimeWarner-OUT {
        term Default {
            from {
                protocol direct;
                route-filter 198.97.232.0/24 exact;
            }
            then accept;
        }
        term otherwise {
            then reject;
        }
    }
    policy-statement next-hop-self {
        then {
            next-hop self;
        }
    }
    
    > show configuration protocols 
    bgp {
        group TimeWarner_Peer {
            type external;
            local-address 66.193.43.186;
            log-updown;
            import BGP-TimeWarner-IN;
            export BGP-TimeWarner-OUT;
            peer-as 4323;
            neighbor 66.193.43.185;
        }
        group local-peers {
            type internal;
            description "Local iBGP peering for DIA circuits";
            local-address 172.17.3.1;
            export next-hop-self;
            neighbor 172.17.3.2;
        }
    }
    ospf {
        area 0.0.0.0 {
            interface lo0.0 {
                passive;
            }
            interface ge-0/1/9.0;
        }
    }

    Configuration for R2:

    > show configuration policy-options 
    policy-statement BGP-Comcast-IN {
        term reject-routes {
            from {
                route-filter 0.0.0.0/0 exact;
            }
            then reject;
        }
        term Default {
            then {
                as-path-prepend "26264 26264 26264 26264";
                accept;
            }
        }
        term otherwise {
            then reject;
        }
    }
    policy-statement BGP-Comcast-OUT {
        term Default {
            from {
                protocol direct;
                route-filter 198.97.232.0/24 exact;
            }
            then accept;
        }
        term otherwise {
            then reject;
        }
    }
    policy-statement BGP-Prefixes {
        from protocol bgp;
        then accept;
    }
    policy-statement next-hop-self {
        then {
            next-hop self;
        }
    }
    
    
    > show configuration protocols 
    bgp {
        group Comcast_Peer {
            type external;
            local-address 50.233.71.126;
            log-updown;
            import BGP-Comcast-IN;
            export BGP-Comcast-OUT;
            peer-as 7922;
            neighbor 50.233.71.125;
            neighbor 68.86.80.92 {
                multihop;
            }
        }
        group local-peers {
            type internal;
            description "Local iBGP peering for DIA circuits";
            local-address 172.17.3.2;
            export next-hop-self;
            neighbor 172.17.3.1;
        }
    }
    ospf {
        area 0.0.0.0 {
            interface lo0.0 {
                passive;
            }
            interface ge-0/1/9.0;
        }
    }

    Thoughts? Opinions? Corrections?



  • 2.  RE: Problems peering between two iBGP peers

    Posted 01-30-2017 14:02

    Hi, I understand that it is IBGP and you are traying to advertise Full table between them rigth?  Have you try to configure that peer as a cluster on R2?    Also declare as NHS on R2.  

     

    Regards.

     

    EC.



  • 3.  RE: Problems peering between two iBGP peers

    Posted 01-30-2017 14:20

    Hi,  once I have that problem... I was having problem to advertise full table to a IBGP, I place it as a cluster and it work fine. Maybe it will work for u.  

     

    EC



  • 4.  RE: Problems peering between two iBGP peers
    Best Answer

    Posted 01-30-2017 15:05

    Hello,

     

    Seems you are forcing an AS Path loop. The issue is that you are adding as-path-prepends with your own ASN 26264 to the prefixes received on R2 from Comcast. Then you advertise this prefixes to R1, who is also on ASN 26264, R1 detects this routes with a looped AS path, and discards them. You could see the hidden routes if you configure "keep all" under protocols bgp (I don't recommend doing this on your production network.

     

    To correct this, use another BGP attribute instead of as-path-prepends, like local-preference, which would be more suitable. For example, configuration on R2 would be:

     

    > show configuration policy-options 
    policy-statement BGP-Comcast-IN {
        term reject-routes {
            from {
                route-filter 0.0.0.0/0 exact;
            }
            then reject;
        }
        term Default {
            then {
                local-preference 90;
                accept;
            }
        }
        term otherwise {
            then reject;
        }
    }

     I hope this helps. Any further doubts are welcome.



  • 5.  RE: Problems peering between two iBGP peers

    Posted 02-01-2017 10:41

    DOH! I didn't really think of that.  I removed the AS padding and played with some of the other options and it plunked right into inet.0.  So, there ya go. Thanks for pointing that out.