[j-nsp] Troubleshooting BGP

[Stefan Fouant]

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