Routing
Highlighted
Routing

Problems peering between two iBGP peers

[ Edited ]
‎01-30-2017 01:22 PM

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?

4 REPLIES 4
Highlighted
Routing

Re: Problems peering between two iBGP peers

‎01-30-2017 02:02 PM

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.

Highlighted
Routing

Re: Problems peering between two iBGP peers

‎01-30-2017 02:20 PM

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

Highlighted
Routing
Solution
Accepted by topic author gsweet@sav
‎02-01-2017 10:39 AM

Re: Problems peering between two iBGP peers

‎01-30-2017 03:05 PM

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.

Regards.
Highlighted
Routing

Re: Problems peering between two iBGP peers

‎02-01-2017 10:40 AM

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.

Feedback