Sorry to hear of the frustrations with support. It might help if you posted your BGP export policy. IIRC, there is a no-readvertise flag available for a static but not aware of any inherent blocking of the advertisement of an fxpo address via BGP, more so if your export permits it.
Here, I add such a policy to effect advertisement of fxp0 direct: << with current bgp export, no fxp0 advrtisement: [edit] regress@eub-a# run show route advertising-protocol bgp 192.168.1.10 table inet.0 << update config; [edit] regress@eub-a# commit commit complete [edit] regress@eub-a# show | compare rollback 1 [edit policy-options policy-statement next-hop-self] term 1 { ... } + term 2 { + from { + protocol direct; + route-filter 192.168.50.0/25 exact; + } + then accept; + } + term 3 { + then next policy; + } [edit policy-options policy-statement next-hop-self] - then next policy; <<< there she goes: [edit] regress@eub-a# run show route advertising-protocol bgp 192.168.1.10 table inet.0 inet.0: 420231 destinations, 421722 routes (7188 active, 0 holddown, 413043 hidden) Prefix Nexthop MED Lclpref AS path * 192.168.50.0/25 Self 100 I HTHs -----Original Message----- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Jo Rhett Sent: Thursday, September 27, 2012 10:50 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] mx-class units now advertisement management interface networks in BGP I don't know when Juniper broke this, but I was chasing down a different problem earlier this week and discovered that our Juniper MX80s are advertising the fxp0 interface's network in BGP announcements. My testing seems to indicate that it still won't accept packets on other interfaces for this network, so the historical nature of fxp0 seems to remain the same. This means it is clearly a bug in the announcements. It was a bit surprising to find such a rookie mistake coming from Juniper, but sadder still is the two days of back and forth I've had to do with Juniper on this topic. They really don't understand BGP at all. Suggestions: 1. Who cares it won't be used by this unit. ---um, yeah, I care about the other units receiving it. 2. Filter it on all recipients. --sure, let's go ask this of all our peers, instead of fixing the source 3. Send me a capture of the announcement from the source --right, because output from another router showing it on the received routes from this unit isn't conclusive. 4. Send me the arp table from the unit --okay, I'm not even going to dignify this with a response. So, not even that long ago, I would have argued that it's worth paying more for Juniper gear just because the technical support response was more coherent and useful when a bug was found. Juniper seems to have eroded that completely away now. After two days on this topic I could have gotten a bug fix out of Cisco. At this point Juniper hasn't even started the grasp the nature of the problem. This really isn't a good sign. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp