Re: [j-nsp] MX304 Port Layout

[Tarko Tikan via juniper-nsp]

hey,

While I'm not sure operators want that, they will take a look if the 
lower price does not impact performance.


Previously mentioned centralized boxes are actually becoming more and 
more common now (in addition to non-redundant pizzabox formfactor that 
has been available for ages) that single NPU can do 2+ Tbps. For BCM J2 
see ACX7509, Nokia IXR-R6d or certain Cisco NCS models. All pretty good 
fits for SP aggregation networks.


Single NPU doesn't mean non-redundant - those devices run two (or 4 in 
ACX case) BCM NPUs and switch "linecards" over to backup NPU when 
required. All without true fabric and distributed NPUs to keep the cost 
down.


IMHO these are very compelling options for SP market, you get selection 
of linecards for different applications/architectures yet the overall 
size of the device (and power consumption) is small. I've been trying to 
explain to one of the major vendors that they should build similar 
device with their own silicon so you get similar benefits while keeping 
the rich featureset that comes with vendor silicon compared to BCM.


--
tarko

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Looking for Hints: Best Practices to PUSH prefix-list on MX platform with 16.x and UP

[Tarko Tikan via juniper-nsp]

hey,

Or just use "load replace https://nms/irr.junos; && commit with new file 
having:


groups {
  replace: IRR {
 ...
   }
}

--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QSA modules and DDM/DOM readings

[Tarko Tikan]

hey,

I tried QSAs from two different vendors but to no avail. I wonder if 
anyone has succeded in getting DDM/DOM readings on a QSA adapter. Is it 
the QFX5100-48T's fault or is it the QSA+SFP Modules that are at fault?


Works fine on MX10k3 with 19.4R3-S1.3

tarko@x> show interfaces terse xe-0/0/3*
Interface   Admin Link ProtoLocal Remote
xe-0/0/3:0  upup
xe-0/0/3:0.0upup   inet x/31
   inet6x/64
x/64
   multiservice
xe-0/0/3:1  down  down
xe-0/0/3:2  down  down
xe-0/0/3:3  down  down

tarko@x> show chassis hardware | match OPCPCH16140148
Xcvr 3   A01  A   NON-JNPR OPCPCH16140148SFP+-10G-ZR

tarko@x> show interfaces diagnostics optics xe-0/0/3:0
Physical interface: xe-0/0/3:0
Laser bias current:  70.504 mA
Laser output power:  1.5650 mW / 1.95 dBm
Module temperature:  28 degrees C / 82 
degrees F

Module voltage:  3.3020 V
Laser receiver power  :  0.1870 mW / -7.28 dBm


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Netflow config for MX204

[Tarko Tikan]

hey,


To be honest, we are on the old method and don't notice any badness. One
of those "If it ain't broke" times :-).


If you have your tables sized correctly then why would you notice 
anything? They are the same tables after all.


I was just pointing out that if someone is distributing a template for 
new users, perhaps include the newer automatic sizing (which was not 
available at first so it's reasonable to use it if you started before it 
become available).


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Netflow config for MX204

[Tarko Tikan]

hey,


Does one need to reboot the box if you switch to "flex-flow-sizing"? The
documentation seems to say so if you're going from the old format to the
new one.


AFAIR no. You can verify via "show jnh 0 inline-services 
flow-table-info" from the PFE shell.


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Netflow config for MX204

[Tarko Tikan]

hey,


I've used IPFIX before, here is an example of how that might be setup,
whether it is good or not I'll let others judge and I can fix if there
is feedback:

   


I don't have any 204s but perhaps use flex-flow-sizing instead manual 
table sizes?


And if you do a lot of flow then you need to raise flow-export-rate from 
default as well.


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Suggestions for Edge/Peering Router..

[Tarko Tikan]

hey,


7280R, Jericho.


What is the motivation to run jericho in your L2-only setup (instead 
trident)? Only buffer space?


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] What exactly causes inconsistent RTT seen using ping utility in Junos?

[Tarko Tikan]

hey,


Please let me know if anything was unclear or if someone has other
ideas or theories.


Been following this thread and do not have anything to contribute at 
this point but wanted to say I (and I hope many others) appreciate this 
type of proper debugging given the tools we have available these days.


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EVPN all-active toward large layer 2?

[Tarko Tikan]

hey,


You have effectively created L2 loop over EVPN, so to cut it you need a
link between bridged network and EVPN to be a single link. There is no STP
in EVPN.


To be fair it's not a full loop but only BUM traffic will loop back to 
other PE.


Single-active is only way forward if you cannot do something like MC-LAG 
from the L2 domain.


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SNMP OIDs for Yellow/Red Alarm on MX204

[Tarko Tikan]

hey,


i just found out that it seems not to be possible to poll Yellow/Red Alarm 
(Count or State) on MX204 via SNMP.


This is pretty sad, juniper, please fix this.

Polling for redAlarmCount > 0 or yellowAlarmCount > 0 has been a good 
generic solution to cover a lot of ground quickly.


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ARP resolution algorithm? Storage of MX transit packets?

[Tarko Tikan]

hey,


Huawei VRP has magic feature to enable periodic ARP for static route,
so that static route is not installed if far_end does not resolve or
stops resolving. Cisco and Juniper do not.


So does Nokia SROS:

[no] static-route {ip-prefix/prefix-length | ip-prefix netmask } 
[validate-next-hop]


validate-next-hop:

This configuration option tracks the state of the next-hop in the IPv4 
ARP cache or IPv6 Neighbor Cache. When the next-hop is not reachable and 
is removed from the ARP or Neighbor Cache, the next-hop will no longer 
be considered valid. When the next-hop is again reachable and present in 
the ARP/Neighbor Cache, the static route will be considered valid.
Note: This feature is supported for directly connected next-hops only, 
and is exclusive with indirect routes.



--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Opinions on fusion provider edge

[Tarko Tikan]

hey,


Yep, Juniper told us at the time that Fusion was based on open
standards (802.1BR) and not proprietary in any way. Funny how they
don't support the use of any other 802.1BR complaint device and, I
doubt it would work. They must have some property gubbins in there
like pushing the Fusion firmware blob from the aggregation device to
the satellite device. If the Fusion firmware wasn't on the QFX the MX
and QFX wouldn't "bond". Not sure how the MX detects that (LLDP?) - I
had a (albeit quick) look at the standard back then and couldn't seen
anything related, so I presume an MX AD would reject a random 802.1
BR compatible device.


Well, the 802.1BR part might very well be standard. But it does not 
cover functionality like loading the software to port extender, 
discovery etc. This is proprietary and as a result makes the whole thing 
vendor specific.


Funny enough, they do use standards to implement this functionality (why 
reinvent the wheel?). One vendor I know creates internal VRF with DHCP 
server to boot up and manage port extenders.


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Opinions on fusion provider edge

[Tarko Tikan]

hey,


There is
nothing wrong with layer 2 aggregation switches in my opinion, the
only technical advantage in my opinion to using SP Fusion for a layer
1 extension to a router compared to a layer 2 switch is that SP Fusion
is one device to configure and monitor instead of two.


Except that it's not L1. It's still L2 with 802.1BR (or vendor 
proprietary version of that).


You highlight the exact reasons why one should stay away from 
fusion/fex/satellite - features must explicitly be 
ported/accommodated/tested for them. Not all performance data is 
available, OAM/CFM is a struggle etc.


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] vSRX feedback

[Tarko Tikan]

hey,

I'm looking for feedback from vSRX users. Not PoC situations but actual 
users who use it for production traffic.


Are you happy with quality and manageability?

Any gotchas (especially on vmware environments)?

--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX Reth-count

[Tarko Tikan]

hey,


Is this configuration to take effect or change require firewall to reboot
or will it take straight a way?


No reboot is required, new reth interfaces will be immediately created 
after config commit.


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] access-internal routes

[Tarko Tikan]

hey,


how do I turn off the /32 route injection at the
acx5048 ?


I don't have test setup at hand but I belive it is
"forwarding-options dhcp-relay route-suppression access-internal"

They can be safely disabled if you only use basic dhcp relay functionality.

Due to (junos) complicated reasons, I'd actually recommend you to use
"forwarding-options helpers bootp" instead full dhcp relay, if possible.


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Separate internet transit network versus converged

[Tarko Tikan]

hey,


Tarko, can you say something more about traffic ratio/levels - internet
traffic VS vpn-traffic. I assume Internet traffic can consume 5-10 times
more than your VPN customers. Can you agree with that or your numbers are
completely different ?


40% internet

40% IPTV/VOD that stays in our network but lives in L3VPN

15% MBH for our mobile network, L3VPN, including 3GPP voice

5% enterprise L3VPN

--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Separate internet transit network versus converged

[Tarko Tikan]

hey,


Given our current network architecture, we have not found a significant
technical or commercial reason to separate VPN traffic from Internet
traffic as a function of what that will cost us in money and human terms.


Every network is different and YMMV.

In our case, we run BGP-free MPLS aggregation and BGP-free core. All IP 
services, be L3VPN or inet, are terminated in separate edge boxes. Edge 
boxes are only connected to core and are not in traffic path for other 
traffic (typical aggregation-edge-core is not the case for us). Traffic 
from aggregation to edge are transported in PW.


We are major provider for Estonia and Estonian government, banks etc. 
Almost all of the GOV services, banking etc. depends on our network and 
lives in L3VPN. So it's not really a capex/opex issue but more of a PR one.


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] About ISIS export policy behavior

[Tarko Tikan]

hey,


However when I apply this export policy to protocol isis, all non-iso
routes, including lo0's inet/inet6 addresses are not advertised in LSP
anymore.

Shouldn't these routes be advertised by flooding? Or did I miss something?


Documentation is indeed confusing. Do not reject anything in your policy 
and everything that is accepted gets exported to IS-IS, like so:


isis {
export isis-export;
}
policy-statement isis-export {
term radius_dhcp_bgp {
from {
protocol bgp;
neighbor [ 194.126.114.19 194.126.114.36 ];
route-filter 84.50.32.0/27 exact;
}
then accept;
}
}


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Tarko Tikan]

hey,


I always found using communities on non-BGP routes a little weird,
but everyone has their favorite operational tricks.  (And I try to
seek out people to talk about them at conferences.  It often leads to
small features.)


Communities on static routes are great.

But everyone wants more :) It would be super helpful if you would 
support communities or tags on connected routes as well.


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Tarko Tikan]

hey,


set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 tag Z
set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 community K


Thats what I had in mind as well.

--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] dynamic prefix list based on as-path .. is it possible?

[Tarko Tikan]

hey,


We are shipping an SMP kernel in the 15.x timeframe.  Even with no
daemon changes, it helps by spreading the load of the daemons to some
extent.


From engineering perspective, what will break if you just enable SMP 
kernel?


I would expect processes to be spread to different cores (with caveats 
regarding affinity and NUMA) and thats about it. Sounds like an easy win 
and would give more CPU time to RPD. But I'm not J software engineer and 
it sounds too good to be true anyway.



So yes, we have plans.  More than plans.


Excellent, thanks.

--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] dynamic prefix list based on as-path .. is it possible?

[Tarko Tikan]

hey,


The issue with such well, that sounds easy solutions is what it
does to system scale.  In the days of 2G 32-bit RPD, the addition of
a single*word*  (4 bytes) to the route data structures was reason for
massive freak-out.  Even in 3G 32-bit RPD, it's problematic.

We're now in the land of 64-bit RPD as an option.


Slightly related and I totally accept if you can't/want to answer...

Do you have any plans how to dig yourself out from the current 
monolithic RPD and non-SMP enabled kernel hole? Maybe move to linux 
userland altogether? Virtualizing fbsd on top of linux doesn't 
necessarily make things better.


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Parameters of default_arp_policer

[Tarko Tikan]

hey,

Create your custom policer and attach it to interface with family inet 
policer arp foo.


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Peering Configuration

[Tarko Tikan]

hey,


Can anybody share with me
(on or off list) some configuration templates for setting up prefix
filters such as maximum prefix count, filtering bogons and martians
etc, max AS path length?


http://www.cymru.com/gillsr/documents/junos-bgp-template.pdf

I don't agree with everything thats in there (dampening for example) but 
it's a start. It's also pretty old but syntax is syntax.


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] L2VPN Termination

[Tarko Tikan]

hey,


Alternatively use routed VPLS on the core box if it is also an MX and a
standard VPLS instance on the edge:
http://www.juniper.net/techpubs/en_US/junos10.2/topics/task/configuratio
n/vpls-irb-solutions.html


+1 for this. Not a hack, we have been using this for a while now and got 
all major bugs fixed over time. In production for hundreds of thousands 
of customers.


Don't use lt- interfaces if you don't have to.


Or if you are game then in the next release you should get psX
interfaces on the MX for direct PWHT although it will still be bound to
an lt- interface underneath.  Documentation already exists for this for
13.1.


+1 for this as well. This will supposedly support all the features 
physical ports do so you can do HQoS etc.


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MS NLB multicast mode and EX 12.x new behaviour issues

[Tarko Tikan]

hey,


EX also had no support for
the equivalent of Cisco's 'bpdufilter', and working around that with manual
ethernet-switching family filters in 11.4 has been a mixed experience.


By 'mixed' you surely mean painful. E-s filters do not work for STP, 
period. STP traffic is captured to RE first, bypassing all ingress 
filters and is then sent out from RE to be flooded as normal multicast.


If you need bpdufilter on EX, you have to use the proper knob that was 
introduced in 12.2, otherways it's just useless.


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MS NLB multicast mode and EX 12.x new behaviour issues

[Tarko Tikan]

hey,

I just want to let everyone know about the new behaviour for unknown 
multicast that was introduced in junos 12.1 for EX switches. I'm also 
looking for feedback from other EX users because we have been unable to 
convince juniper to rethink this for 4 months now.


In 12.1, EX will now copy all transit multicast packets matching 
destination mac 03:bf:* to control plane. This is normally used for MS 
NLB multicast mode and should be flooded. I would somewhat understand if 
they would do it in management vlan but this is done for all vlans, 
including ones that should be pure transit in L2 device.


The side effect of this is that multicast will totally congest some of 
your inband management queues leaving you without ssh and telnet.


You can verify this by running show sh packet-descriptor dev 1 pcl-out 
from SFID shell and looking whats in the packet queue. Cut-down example 
(original output has lot more fields):


CPU code   : 253
Dest IP addr   : 192.168.17.95
Dest MAC addr  : 03:bf:c0:a8:11:5f
Ether type : 0x800
IP TTL : 62
Is routed  : 0
MAC DA lookup rslt : 0
MAC DA type: Multicast
Packet command : Mirror to CPU
Src IP addr: 192.168.16.58
Src MAC addr   : 44:d3:ca:ba:55:c1
TCP/UDP dest port  : 3389
TCP/UDP src port   : 47679
Vlan ID: 12

JTAC is now proposing using scripts and cronjobs to run some commands 
from pfe shell on every startup to ratelimit this multicast. Not only is 
this not deployable in large scale, but this is head-in-the-sand type of 
solution. They should really fix the root cause (by redesigning it) or 
revert the change. EX software quality has been going downhill for a 
while now and still keeps doing so.


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Control giaddr in forwarded bootp/dhcp request?

[Tarko Tikan]

hey,

Again, set your required address to primary (not preferred). I'm doing 
exactly that to control GIADDR selection with bootp helper.


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Control giaddr in forwarded bootp/dhcp request?

[Tarko Tikan]

hey,


Can I control the giaddr field in a forwarded bootp request on JunOS?


Set it to primary instead preferred.

--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] maximum number of routing-instances on MX and EX

[Tarko Tikan]

hey,

Just for future reference, this is not true for SRX running in flow mode.

On SRX, number of zones is software limited and interfaces for single 
zone have to be in the same routing-instance. So in essence you are 
limited to 127 routing instances (128 - global) on a box with 128 zones.


More realistically 63 routing instances (min. 2 zones per 
routing-instance) unless you only do global  R-I leaking.


--
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Bricking EX4500 with 11.4R3 to R4 upgrade

[Tarko Tikan]

hey,

As a final update, all our units are now recovered without problems 
using the procedure detailed in the PSN.


--
tarko


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Bricking EX4500 with 11.4R3 to R4 upgrade

[Tarko Tikan]

hey,

I just want to get this information out there for others. We've received 
a batch of new EX4500-40F (manufactured in march) with 11.4R1. They were 
upgraded to R3 without any problems. When upgraded from R3 to R4, they 
will boot once (during the upgrade process) but every subsequent reboot 
will hang before loader prompt leaving you with a bricked device.


Last thing you will see is Consoles: U-Boot console. Investigation 
with JTAC is ongoing but it doesn't seem to be hardware issue as we have 
already bricked 3 devices (2 accidently, one while trying to downgrade 
to R3.


--
tarko

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] forwarding-options helpers bootp vs. forwarding-options dhcp-relay?

[Tarko Tikan]

hey,


Does anyone know why Juniper developed a different, incompatible syntax
logic for extended DHCP?  Why didn't they just expand the logic under
helpers bootp?


dhcp-relay is totally different implementation mainly used to support 
subscriber management. It's (somewhat) stateful, inspects DHCP packets 
on *all* interfaces (somewhat configurable), requires license per user 
and somewhat works.


You should really be using bootp helper unless you require functionality 
only available with dhcp-relay.


--
tarko


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Ethernet OAM, specifically CFM

[Tarko Tikan]

hey,

   I'm trying to figure out if I can create a
 connectivity-fault-management instance between a vlan sub interface on
 an MX and the access port in the same vlan on a down stream switch.

Sane requirement and it's possible with some non-juniper equipment via OAM 
interworking. I don't think it's currently possible to do it with MX, you could 
try bridge-domain with IRB interface and hope IRB is brought down when there 
are no active interfaces (with MEPs) in the domain.

-- 
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VPLS configuration

[Tarko Tikan]

hey,

 You have no CE interface in the chrismas instance.  Do you just want the IRB 
 interface in there?  
 If so, than replace interface irb.800 with routing-interface irb.800

As a sidenote, if you are really planning to do exactly that, be prepared for a 
lot of unexpected.

-- 
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Ex Series VC with *both* high-speed backbone *and* link-aggregation

[Tarko Tikan]

hey,

 I was pretty sure you *cannot* use the remaining SFP ports if they are
 configured for VC??  Am I mistaken?

VCP mode is set per port and you can use second 10G port for ethernet. What you 
cannot do is use one of the ports as 10G and another as 1G (or remaining 2 if 
you use SFP+ module).

-- 
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Ex Series VC with *both* high-speed backbone *and* link-aggregation

[Tarko Tikan]

hey,

 Can I set up a Juniper EX series virtual chassis using a high-speed 
 backbone on one floor of a building and then connect that VC to another 
 switch (or two) via link-aggregation on the SFP ports?

Directly from documentation:
You can select up to four uplink module ports or SFP network ports on an EX4200 
switch that have been configured as Virtual Chassis ports (VCPs) to form a LAG. 
When you set uplink module ports or SFP network ports on Virtual Chassis member 
switches as uplink VCPs, connect two or more of those uplink VCPs on one member 
to at least two uplink VCPs on another member, and configure those uplink VCPs 
to operate at the same link speed, the uplink VCPs automatically form a LAG. 
Each LAG is assigned a positive-integer identifier called a trunk ID.

Haven't tried it but about to.

-- 
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] TCAM full on EX8200?

[Tarko Tikan]

hey,

 Eventually someone will come along and realize that there is an untapped 
 market here, and then the promise of cheap label switching routers will 
 be fulfilled. 

TBH, I haven't checked the pricing but I'd expect Brocade MLX and DellForce10 
to be cheaper than C/J. I'm sure the edge feature software quality is horrible 
(this actually goes for Juniper aswell these days) but they probaby work OK for 
LSR.

-- 
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] TCAM full on EX8200?

[Tarko Tikan]

hey,

 MLX(e) is an edge device and is much like MX in most things. It's cheaper
 but at a cost of some features lack and few caveats. Although it's a good
 product, it's not a label-oriented LSR anyway.

Same way MX is not ment to be used as LSR, yet everyone does that.

-- 
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] TCAM full on EX8200?

[Tarko Tikan]

hey,

 The hardware functionality for label switching in MLX/XMR seems to be 
 fine (as far as I can tell), it's only the software that is still a 
 giant mess. 

In other news, AMS-IX manages to use the very same boxes both very simple PE 
(VPLS) and LSR. But I think we weren't discussing PE, only LSR.

-- 
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] TCAM full on EX8200?

[Tarko Tikan]

hey,

 I meant that in order to do LB on labels alone (to have enough of 
 hash-keys for micro-flows), you need a large enough set of labels in the 
 core and more or less uniformly distributed traffic over these labels. 

Or you could use additional hash-labels. Let the ingress LER do all the lookup 
work first, loadbalance on label-stack later.

-- 
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] JUNOS and 128.0.0.0 martian (JFYI)

[Tarko Tikan]

hey,

 It has been posted on the amsix mailing list that juniper also needs to
 change internal addressing because of the issue with 128.0.0.0/16 as
 addresses of this space are used internally within JunOS (see below).

It's worse. Example from SRX cluster:

show interfaces terse | match ^(fab|fxp1).*inet
fab0.0  upup   inet 30.17.0.200/24  
fab1.0  upup   inet 30.18.0.200/24  
fxp1.0  upup   inet 129.16.0.1/2

Luckily none of the routes in __juniper__private__ tables interferes with 
transit traffic. Same cannot be said for martians.

-- 
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Ingress Firewalling for CoPP on EX4500

[Tarko Tikan]

hey,

 Any ideas how to secure the switch?

Upgrade to 10.4.

-- 
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] /32 host routes on down interfaces

[Tarko Tikan]

hey,

 So I just noticed an interesting behavior which I think is a bad thing, 
 but I want to see what other people think.

Very.

Imagine dual router setup (MX for example as it has all the needed 
capabilities), vpls on both, IRB interfaces in vpls, identical IP config on IRB 
interfaces, redundant pseudowires coming from third box - only one of the IRB 
interfaces is active at once.

This all works fine until you start to source traffic from interface IP - dhcp 
relay for example. DHCP requests are relayed from active router to dhcp server 
(using interface IP as source address) but dhcp replies are transited via 
backup box into active. Leads to dhcp replies being dropped and makes this 
setup impossible on junos.

-- 
tarko
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp