[j-nsp] Troubleshooting BGP

[Jason Lixfeld]

If I'm reading this correctly, the router is preferring the OSPF route  
over the BGP route, which makes sense because OSPF has a lower  
administrative distance (is that a Juniper term too, or just a Cisco  
term?) than iBGP.  This shouldn't prevent the route from being  
announced to eBGP peers (at least it doesn't in Cisco land, but maybe  
there are differences in how J and C work in this regard which I'm  
missing) should it?

user at router> show route 69.57.14.0 detail

inet.0: 296972 destinations, 664182 routes (296971 active, 0 holddown,  
1 hidden)
69.57.14.0/24 (2 entries, 1 announced)
         *OSPF   Preference: 150
                 Next hop type: Router, Next hop index: 530
                 Next-hop reference count: 1262
                 Next hop: 72.15.49.21 via ge-2/0/1.0, selected
                 State: <Active Int Ext>
                 Local AS: 21949
                 Age: 1:11:22 	Metric: 2020 	Tag: 0
                 Task: OSPFv2
                 Announcement bits (2): 0-KRT 5-Resolve tree 1
                 AS path: I
          BGP    Preference: 170/-791
                 Next hop type: Indirect
                 Next-hop reference count: 1
                 Source: 72.15.48.2
                 Next hop type: Router, Next hop index: 530
                 Next hop: 72.15.49.21 via ge-2/0/1.0, selected
                 Protocol next hop: 206.223.182.67
                 Indirect next hop: 155101d4 1048579
                 State: <Int Ext>
                 Inactive reason: Route Preference
                 Local AS: 21949 Peer AS: 21949
                 Age: 1:11:27 	Metric: 0 	Metric2: 2020
                 Task: BGP_21949.72.15.48.2+179
                 AS path: I (Originator) Cluster list:  66.207.194.20
                 AS path:  Originator ID: 72.15.48.6
                 Communities: 21949:70 21949:790
                 Localpref: 790
                 Router ID: 66.207.194.20

user at router>

On 2009-10-07, at 7:42 PM, Stefan Fouant wrote:

> You may have received the route via your iBGP peer, but is it active?
> Do a 'show route x.x.x.x detail' to see if that particular route is
> active in the routing table and post your results here...
>
>
>
> On 10/7/09, Jason Lixfeld <jason at lixfeld.ca> wrote:
>> I'm pretty new to JunOS and I'm running up against an issue that I'm
>> not sure how to troubleshoot or debug.
>>
>> I have an iBGP prefix that is being learned by my M120/9.1R1.8 box,
>> but it's not being announced to eBGP peers:
>>
>> user at router> show route advertising-protocol bgp 38.104.158.173 |
>> match 69.57
>>
>> user at router>
>>
>> I see the prefix has been received from the iBGP router:
>>
>> user at router> show route receive-protocol bgp 72.15.48.2 extensive
>> 69.57.14.0/24
>>
>> inet.0: 296881 destinations, 664001 routes (296880 active, 0  
>> holddown,
>> 1 hidden)
>>   69.57.14.0/24 (2 entries, 1 announced)
>>      Nexthop: 72.15.48.6
>>      MED: 0
>>      Localpref: 790
>>      AS path: I (Originator) Cluster list:  66.207.194.20
>>      AS path:  Originator ID: 72.15.48.6
>>      Communities: 21949:70 21949:790
>>
>> user at router>
>>
>> Looking at the configuration for this particular eBGP peer, it's
>> configured to announce prefixes tagged with one of the communities
>> attached to this route, 21949:70.  I've also verified that there are
>> other prefixes with the same communities as above being announced to
>> this eBGP peer without incident.
>>
>> user at router> show configuration protocols bgp group paidpeers
>> type external;
>> mtu-discovery;
>> import PP-NA-TOR-FRONT-GENERIC-IN;
>> export PP-GENERIC-OUT;
>> neighbor 38.104.158.173 {
>>     family inet {
>>         unicast;
>>     }
>>     peer-as 174;
>> }
>>
>> user at router> show configuration policy-options policy-statement PP-
>> GENERIC-OUT
>> term transit-routes {
>>     from community TRANSIT;
>>     then reject;
>> }
>> term peering-routes {
>>     from community PEERING;
>>     then reject;
>> }
>> term paidpeering-routes {
>>     from community PAIDPEERING;
>>     then reject;
>> }
>> term local-routes {
>>     from community LOCAL;
>>     then {
>>         community delete all;
>>         accept;
>>     }
>> }
>> term customer-routes {
>>     from community CUSTOMER;
>>     then {
>>         community delete all;
>>         accept;
>>     }
>> }
>> term backbone-static {
>>     from {
>>         protocol static;
>>         route-filter 72.15.48.0/20 exact;
>>     }
>>     then accept;
>> }
>> term default {
>>     then reject;
>> }
>>
>> user at router> show configuration policy-options community LOCAL
>> members 21949:70;
>>
>> Just to be sure there aren't any typos in the community lists, there
>> is only one that has 21949:70 as a member:
>>
>> user at router> show configuration policy-options | match 21949:70
>> community LOCAL members 21949:70;
>>
>> user at router>
>>
>> I'm at a loss to understand why or how this prefix is any different
>> than any of the others that match the same community string.  I've
>> tried to monitor bgp traceoptions flag update and while I see updates
>> coming through, I don't see anything for this specific prefix even if
>> I withdraw it from iBGP (I'd expect to see an update because the
>> prefix is certainly withdrawn from the BGP table on the router as I
>> remove it from BGP on the originating router).
>>
>> Anyone have any ideas on either the issue itself or how I can get  
>> some
>> more debugging/troubleshooting info out of the box?
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
>
> -- 
> Stefan Fouant
>