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: [email protected]
[mailto:[email protected]] On Behalf Of Jo Rhett
Sent: Thursday, September 27, 2012 10:50 AM
To: [email protected]
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 [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
