Re: [j-nsp] SNMP on logical-system fxp0
[AA] if You actually still dealing with such issues in Your customer networks, my condolences. Especially sad is the issue with management PC - do Your customers use commodity Windows PC with freeware Solarwinds version as NMS? Yes, my customers (and companies at all) are not always ideal and I don't want to rely on the contrary assumption :) And it has nothing to do with the freewareness and windowsness. One particular case of a DoS from NMS was Micromuse run on Solaris on SUN hardware, configured by true educated and certified staff. And of course people need PCs to manage networks, and they don't listen, when I say don't use Windows and sometimes even don't forget to purchase a new license for your anvi-virus. This is why I'd prefer to have more tools to be sure. [AA] Not sure if I follow, if BUs are administratively separate, how having a true OOB interface (i.e. CMP in Routing Engine) would make Your life easier? No, I didn't mean true OOB interface. I meant real HW [sub]interface. (The prefix sub is what allows to not buy 1G cards specially for management :) I can protect it with true HW policers and ACLs, apply true CoS, if I need, put it into a VR, use FBF, VLAN rewrite, bundle two ports in a LAG, be sure I'll find in the docs whether something is supported, etc. I even want the management network to be connected to the Internet (OMG), through a firewall, of course. CMP on routing engine would help to do a lot of other things, but it's not for everyday routine management either. Just like nobody uses iLO/IRMC/etc on servers to manage them. So, yes, I am not talking about built from scratch ideal management networks run by ideal people in spherical vacuum. If the national ISP, you've mentioned, is an example of such a paradise (though we both know it's not :), I can only envy them. OK, I think it's enough for this topic. Sorry for kindling the flame. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP on logical-system fxp0
On (2013-04-25 16:51 -0400), Phil Shafer wrote: transfers. So the second network is rs232 _and_ fxp. Brandon Ross wrote: Both. Either defend that statement or admit that it was overly broad. Everyone seems to agree RS232 is granted. But some people feel you also need to build FXP. The added benefit of also building FXP is that you can copy images and that the session isn't terribly slow (9600bps sucks) If you can do this for free, then yes, it's overly broad to say that FXP is useless. But for me it carries non-zero cost, so I'm not going to build two emergence accesses to the device. With CMP/vPro/drac we'd get superior solution, only reason it does not exist in every router already, is because we, the community, think on-band ethernet is the bee's knees for OOB and are not asking for solution in RFQ (so please add in your next RFQ this) For me delivering both FXP and RS232 to pop is non-trivial cost, each RU is MRC in telco colopops. And we can't use ghetto switches, as power must be DC, so CAPEX is non-trivial as well. Multiply that MRC and CAPEX by few hundreds and you start asking, when did I need to upload new image to crashing and burning router? -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] next-hop driving me crazy
This should be simple but I can't get the behavior I want. Blackhole scenario. Customer set community, I want to see that community and set next-hop to an address I have with a discard. I've tried both a discard interface and a basic static route. Those seem ok either way. set routing-options static route 192.0.2.1/32 discard Route comes in and is accepted by policy. With no next-hop 192.0.2.1 action, I see it as a valid route so I know the policy is happening. When I add the next-hop action, the route becomes Next hop type: Unusable with Inactive reason: Unusable path. I don't see anything special about this and what I translated from my cisco versions doesn't look all that different from various black hole presentations I find. Anyone have a magic answer? Thanks, Eric ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] next-hop driving me crazy
Works fine for me in the lab on MX80+JUNOS 12.3 ( I use BGP-LU though, too
busy to change to regular inet unicast:-)
[edit logical-systems MX2-RR]
aarseniev@mx80# run show route logical-system MX2-RR protocol bgp extensive
inet.0: 29 destinations, 30 routes (27 active, 0 holddown, 2 hidden)
198.18.0.6/32 (1 entry, 1 announced)
TSI:
KRT in-kernel 198.18.0.6/32 - {indirect(1048668)}
*BGPPreference: 170/-101
Next hop type: Indirect
Address: 0x26e8010
Next-hop reference count: 6
Source: 198.18.0.11
Next hop type: Discard
Protocol next hop: 192.0.2.1
Push 299904
Indirect next hop: 29941d8 1048668 INH Session ID: 0x280008
State: Active Int Ext
Local AS: 50928 Peer AS: 50928
Age: 5:14 Metric2: 0
Validation State: unverified
Task: BGP_50928.198.18.0.11+179
Announcement bits (2): 3-KRT 5-Resolve tree 2
AS path: 31133 50928 I (Looped: 50928)
Communities: 5:5
Accepted
Route Label: 299904
Localpref: 100
Router ID: 198.18.0.11
Secondary Tables: inet.3
Indirect next hops: 1
Protocol next hop: 192.0.2.1 Metric: 0
Push 299904
Indirect next hop: 29941d8 1048668 INH Session ID:
0x280008
[edit logical-systems MX2-RR]
aarseniev@mx80# show policy-options policy-statement set-nh
term 1 {
from {
protocol bgp;
community 5:5;
}
then {
next-hop 192.0.2.1;
accept;
}
}
[edit logical-systems MX2-RR]
aarseniev@sadok# show routing-options
static {
route 192.0.2.1/32 discard;
}
- Original Message -
From: Eric Krichbaum e...@telic.us
To: juniper-nsp@puck.nether.net
Sent: Friday, April 26, 2013 2:36 PM
Subject: [j-nsp] next-hop driving me crazy
This should be simple but I can't get the behavior I want.
Blackhole scenario. Customer set community, I want to see that community
and set next-hop to an address I have with a discard. I've tried both a
discard interface and a basic static route. Those seem ok either way.
set routing-options static route 192.0.2.1/32 discard
Route comes in and is accepted by policy. With no next-hop 192.0.2.1
action, I see it as a valid route so I know the policy is happening. When
I
add the next-hop action, the route becomes Next hop type: Unusable with
Inactive reason: Unusable path. I don't see anything special about this
and what I translated from my cisco versions doesn't look all that
different
from various black hole presentations I find.
Anyone have a magic answer?
Thanks,
Eric
___
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
Re: [j-nsp] next-hop driving me crazy
Hello,
Use a ttl on the bgp session with the customer -
Rgds,
C.
Le 26/04/2013 16:26, Alex Arseniev a écrit :
Works fine for me in the lab on MX80+JUNOS 12.3 ( I use BGP-LU though,
too busy to change to regular inet unicast:-)
[edit logical-systems MX2-RR]
aarseniev@mx80# run show route logical-system MX2-RR protocol bgp
extensive
inet.0: 29 destinations, 30 routes (27 active, 0 holddown, 2 hidden)
198.18.0.6/32 (1 entry, 1 announced)
TSI:
KRT in-kernel 198.18.0.6/32 - {indirect(1048668)}
*BGPPreference: 170/-101
Next hop type: Indirect
Address: 0x26e8010
Next-hop reference count: 6
Source: 198.18.0.11
Next hop type: Discard
Protocol next hop: 192.0.2.1
Push 299904
Indirect next hop: 29941d8 1048668 INH Session ID:
0x280008
State: Active Int Ext
Local AS: 50928 Peer AS: 50928
Age: 5:14 Metric2: 0
Validation State: unverified
Task: BGP_50928.198.18.0.11+179
Announcement bits (2): 3-KRT 5-Resolve tree 2
AS path: 31133 50928 I (Looped: 50928)
Communities: 5:5
Accepted
Route Label: 299904
Localpref: 100
Router ID: 198.18.0.11
Secondary Tables: inet.3
Indirect next hops: 1
Protocol next hop: 192.0.2.1 Metric: 0
Push 299904
Indirect next hop: 29941d8 1048668 INH Session
ID: 0x280008
[edit logical-systems MX2-RR]
aarseniev@mx80# show policy-options policy-statement set-nh
term 1 {
from {
protocol bgp;
community 5:5;
}
then {
next-hop 192.0.2.1;
accept;
}
}
[edit logical-systems MX2-RR]
aarseniev@sadok# show routing-options
static {
route 192.0.2.1/32 discard;
}
- Original Message - From: Eric Krichbaum e...@telic.us
To: juniper-nsp@puck.nether.net
Sent: Friday, April 26, 2013 2:36 PM
Subject: [j-nsp] next-hop driving me crazy
This should be simple but I can't get the behavior I want.
Blackhole scenario. Customer set community, I want to see that
community
and set next-hop to an address I have with a discard. I've tried both a
discard interface and a basic static route. Those seem ok either way.
set routing-options static route 192.0.2.1/32 discard
Route comes in and is accepted by policy. With no next-hop 192.0.2.1
action, I see it as a valid route so I know the policy is happening.
When I
add the next-hop action, the route becomes Next hop type: Unusable
with
Inactive reason: Unusable path. I don't see anything special about
this
and what I translated from my cisco versions doesn't look all that
different
from various black hole presentations I find.
Anyone have a magic answer?
Thanks,
Eric
___
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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] next-hop driving me crazy
Hi Eric, Works fine here, as you configured it. Can you reply your inbound route-policy and the show route x.x.x.x/32 extensive? Thanks. Tim On 26-04-13 15:36, Eric Krichbaum wrote: This should be simple but I can't get the behavior I want. Blackhole scenario. Customer set community, I want to see that community and set next-hop to an address I have with a discard. I've tried both a discard interface and a basic static route. Those seem ok either way. set routing-options static route 192.0.2.1/32 discard Route comes in and is accepted by policy. With no next-hop 192.0.2.1 action, I see it as a valid route so I know the policy is happening. When I add the next-hop action, the route becomes Next hop type: Unusable with Inactive reason: Unusable path. I don't see anything special about this and what I translated from my cisco versions doesn't look all that different from various black hole presentations I find. Anyone have a magic answer? Thanks, Eric ___ 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
Re: [j-nsp] QFX vs EX4550 as collapsed core
4550 packet buffers are not that big. We are getting tail drops on ports that show 5-6 Gbps utilization (output of monitor interface show command). It's related to (micro)bursts, and there is not much to do about it. Deeper buffers would certainly help. If I remember correctly QFX uses a cut through design, these problems are less relevant. Amos Sent from my iPhone On 26 Apr 2013, at 10:42, Tore Anderson t...@fud.nomailto:t...@fud.no wrote: * Andy Litzinger Hi, we're deploying to a new environment where there will be about 500 virtual servers hosted completely on Cisco UCS. The Core would mostly be hosting uplinks to the UCS Fabric Interconnects (End Host Mode), inter-vlan routing and links to service appliances (FW/LB) and the Internet edge routers. Nearly all of our traffic is North/South from server to LB to internet or server to LB to another server. The core would mostly be routing a few (dozens at most) routes so RIB/FIB size shouldn't be a great concern. Most links will be 10G, but there are a handful of 1G management links. We're considering either the QFX3500 ( x2) or the EX4450 (x2 as a VC) to fill this role (or potentially Cisco Nexus 6001) * are there any L3 benefits of one over the other? I haven't found clear numbers in the datasheets We're using 2-node EX4500 VCs in much the same way as you describe as core switches in a couple of our data centres. We're quite happy with them - they've been trouble free so far (knock on wood). We briefly considered using the QFX3500s instead for a recent deployment but quickly disqualified them when we realised they do not support IPv6 at all. The EXes support IPv6 fairly well, although according to the specs they have an upper limit of 1000 IPv6 neighbour entries, which is disconcertingly small - at least if they're handling server LANs and not just router-to-router links. Due to hosts having both a link-local address in addition to the global one, 1000 entries will only handle 500 hosts. Tore ___ juniper-nsp mailing list juniper-nsp@puck.nether.netmailto: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
Re: [j-nsp] next-hop driving me crazy
Eric. eBGP single hop will not let you change the NH by default. You can
use the following knob to override this behavior:
protocols {
bgp {
log-updown;
group TRIGGER {
accept-remote-nexthop;
This can be applied @ proto group or neighbor. See
http://www.juniper.net/techpubs/software/junos/junos94/swconfig-routing/accept-remote-nexthop.html
for
more info.
Regards.
david
On Fri, Apr 26, 2013 at 10:35 AM, Tim Vollebregt t...@interworx.nl wrote:
Hi Eric,
Works fine here, as you configured it.
Can you reply your inbound route-policy and the show route x.x.x.x/32
extensive?
Thanks.
Tim
On 26-04-13 15:36, Eric Krichbaum wrote:
This should be simple but I can't get the behavior I want.
Blackhole scenario. Customer set community, I want to see that community
and set next-hop to an address I have with a discard. I've tried both a
discard interface and a basic static route. Those seem ok either way.
set routing-options static route 192.0.2.1/32 discard
Route comes in and is accepted by policy. With no next-hop 192.0.2.1
action, I see it as a valid route so I know the policy is happening.
When I
add the next-hop action, the route becomes Next hop type: Unusable with
Inactive reason: Unusable path. I don't see anything special about this
and what I translated from my cisco versions doesn't look all that
different
from various black hole presentations I find.
Anyone have a magic answer?
Thanks,
Eric
__**_
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp
__**_
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] next-hop driving me crazy
Thanks everyone. The policy straight to discard works for me, just annoyed
me. I really didn't want to apply a knob (similar to the disable connected
check on cisco) to do it. Trying to make these policies the same has proven
an interesting exercise and at least now I am aware of the knobs to make it
do the other.
Eric
-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
David Waldman
Sent: Friday, April 26, 2013 10:59 AM
To: Tim Vollebregt
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] next-hop driving me crazy
Eric. eBGP single hop will not let you change the NH by default. You can
use the following knob to override this behavior:
protocols {
bgp {
log-updown;
group TRIGGER {
accept-remote-nexthop;
This can be applied @ proto group or neighbor. See
http://www.juniper.net/techpubs/software/junos/junos94/swconfig-routing/acce
pt-remote-nexthop.html
for
more info.
Regards.
david
On Fri, Apr 26, 2013 at 10:35 AM, Tim Vollebregt t...@interworx.nl wrote:
Hi Eric,
Works fine here, as you configured it.
Can you reply your inbound route-policy and the show route x.x.x.x/32
extensive?
Thanks.
Tim
On 26-04-13 15:36, Eric Krichbaum wrote:
This should be simple but I can't get the behavior I want.
Blackhole scenario. Customer set community, I want to see that
community and set next-hop to an address I have with a discard. I've
tried both a discard interface and a basic static route. Those seem ok
either way.
set routing-options static route 192.0.2.1/32 discard
Route comes in and is accepted by policy. With no next-hop 192.0.2.1
action, I see it as a valid route so I know the policy is happening.
When I
add the next-hop action, the route becomes Next hop type: Unusable
with Inactive reason: Unusable path. I don't see anything special
about this and what I translated from my cisco versions doesn't look
all that different from various black hole presentations I find.
Anyone have a magic answer?
Thanks,
Eric
__**_
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.n
ether.net/mailman/listinfo/juniper-nsp
__**_
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://puck.ne
ther.net/mailman/listinfo/juniper-nsp
___
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
Re: [j-nsp] Fwd: bgp license mx480 MPC-3D-16XGE-SFPP
i have been told its an honor system however someone i know bought the license and it was just a piece of paper saying they could use it On Thu, Apr 25, 2013 at 10:04 PM, OBrien, Will obri...@missouri.edu wrote: My apologies, I didn't pay attention to the blade you referenced. That blade is only good for switching unless you have the appropriate license to enable layer 3 protocols. Here's the document the clarifies what you can do with that card. http://www.juniper.net/techpubs/en_US/junos10.3/topics/task/configuration/chassis-mx-series-ip-ethernet-mode-configuring.html On Apr 25, 2013, at 5:39 PM, OBrien, Will obri...@missouri.edu wrote: No license needed. Just configure under protocols. Will O'Brien On Apr 25, 2013, at 5:17 PM, John pp luklaupda...@gmail.com wrote: hi all i have a new MX480 with MPC-3D-16XGE-SFPP and I am trying to enable BGP but am not sure how? someone said I need a license is this true? you can email me: luklaupdates(AT, AT, FOR SPAM)gmail.comluklaupda...@gmail.com thanks ___ 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] next-hop driving me crazy
Also, you can do then next-hop discard in your policy and you won't need the static route. On Fri, Apr 26, 2013 at 2:04 PM, Richard A Steenbergen r...@e-gerbil.netwrote: On Fri, Apr 26, 2013 at 11:14:39AM -0500, Eric Krichbaum wrote: Thanks everyone. The policy straight to discard works for me, just annoyed me. I really didn't want to apply a knob (similar to the disable connected check on cisco) to do it. Trying to make these policies the same has proven an interesting exercise and at least now I am aware of the knobs to make it do the other. It's technically a violation of the BGP spec to let the user arbitrarily rewrite the next-hop of a eBGP non-multihop route to something other than the directly connected interface, and the correct action when you do it is to reject the route for having an invalid next-hop. Of course, over here in reality land that's complete nonsense. There are perfectly legitimate reasons to do so, like the example you cited, but it took a LONG time to get this past the guys who defend the theory without regard to practice. You used to have to configure ebgp multihop everywhere to get it to relax those rules, which carries its own downsides like lack of fast external failover behavior. The commands like disable-connected-check and accept-remote-nexthop were the compromises between following the spec and satisfying the customer. ;) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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
