[j-nsp] mx-class units now advertisement management interface networks in BGP

[Harry Reynolds]

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 at eub-a# run show route advertising-protocol bgp 192.168.1.10 table inet.0 

<< update config;

[edit]
regress at eub-a# commit 
commit complete


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