[j-nsp] Troubleshooting BGP

[Jason Lixfeld]

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?