[j-nsp] SNMP query delay
Hi all, I have a strange problem when retrieving interface statistics from IF-MIB through SNMP. The router is an mx960. There are several interfaces, for which the time needed to obtain the values is much higher than for others. Compare: x...@test:~$ mailto:os.ar...@test:~$ time snmpget -v1 -c x -t 100 xx.xxx.xxx.xxx ifHCInOctets.108; IF-MIB::ifHCInOctets.108 = Counter64: 0 real0m0.070s x...@test:~$ mailto:os.ar...@test:~$ time snmpget -v1 -c x -t 100 xx.xxx.xxx.xxx ifHCInOctets.116; IF-MIB::ifHCInOctets.116 = Counter64: 0 real0m10.042s All of the problematic interfaces are tunnel interfaces: IF-MIB::ifType.116 = INTEGER: tunnel(131) IF-MIB::ifType.117 = INTEGER: tunnel(131) IF-MIB::ifType.118 = INTEGER: tunnel(131) IF-MIB::ifType.119 = INTEGER: tunnel(131) IF-MIB::ifType.120 = INTEGER: tunnel(131) IF-MIB::ifType.121 = INTEGER: tunnel(131) IF-MIB::ifType.122 = INTEGER: tunnel(131) I don't know for sure which kind of tunnel this is (I'm troubleshooting remotely a problem on customer side, and this is his router), and I'm not even 100% sure that this is related to the root cause. Another common property is that these interfaces report ifMtu = . This delay is quite annoying, because it apparently slows down the SNMP agent as a whole. All queries become sluggish, until the problematic one completes, so my application cannot perform periodic statistic retrieval in time. The problem is quite reproducible and occurs only on these interfaces (so cannot be attributed to router load, etc). Does anybody has any clues? Thanks in advance! Michael ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] static route priority for iBGP distribution
I use communities attached to static routes at local routers in my network to anchor aggregate eBGP-announced routes specific to that locality. It's just a static route with community XXX:XXX and discard specified. They get redistributed through iBGP to the borders of the network, and, if the right community is attached, they get redistributed through eBGP to peers and upstreams. Straight forward enough, right? Well then I guess the answer to my question is pretty simple too. We had a customer bring over an IP range which they want attached directly to an ethernet interface. Since this route has the same netmask as the static route, Juniper just dumps the static route and the border routers no longer have a route to redistribute to eBGP peers. While it's easy to just make the customer's routes use a more specific netmask within the network, it could be error prone. I'm sure there is a better way. So I'm curious what works for others in this scenario to keep announcing (and attaching a community to) a static route, even when a directly connected route with the same netmask exists. Or is there just a more preferred way of anchoring aggregate routes in this type of network configuration with JunOS? Chris ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] JUNOS not compliant with RFC 3392?
All: We are establishing a BGP session between an M120 and a Checkpoint firewall. The Checkpoint does not support 4-byte ASs. It is sending the Notification to the M120 indicating so, but the M120 keeps sending the capability code everytime it trys to reestablish. Doesn't that make JUNOS non-compliant with RFC 3392? A BGP speaker determines that its peer doesn't support capabilities advertisement, if in response to an OPEN message that carries the Capabilities Optional Parameter, the speaker receives a NOTIFICATION message with the Error Subcode set to Unsupported Optional Parameter. In this case the speaker SHOULD attempt to re-establish a BGP connection with the peer without sending to the peer the Capabilities Optional Parameter. # In the meantime, we used the hidden command disable-4byte-as. to establish connectivity. Derick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS not compliant with RFC 3392?
I just re-read this and realized that it says the speaker SHOULD try again without the code. It doesn't say MUST. So technically, its compliant. If Juniper chooses not to follow the recommendation of trying again without the code, then why is the disable-4byte-as command hidden? From: Derick Winkworth dwinkwo...@att.net To: juniper-nsp@puck.nether.net Sent: Monday, March 30, 2009 3:13:35 PM Subject: JUNOS not compliant with RFC 3392? All: We are establishing a BGP session between an M120 and a Checkpoint firewall. The Checkpoint does not support 4-byte ASs. It is sending the Notification to the M120 indicating so, but the M120 keeps sending the capability code everytime it trys to reestablish. Doesn't that make JUNOS non-compliant with RFC 3392? A BGP speaker determines that its peer doesn't support capabilities advertisement, if in response to an OPEN message that carries the Capabilities Optional Parameter, the speaker receives a NOTIFICATION message with the Error Subcode set to Unsupported Optional Parameter. In this case the speaker SHOULD attempt to re-establish a BGP connection with the peer without sending to the peer the Capabilities Optional Parameter. # In the meantime, we used the hidden command disable-4byte-as. to establish connectivity. Derick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
