Re: [j-nsp] SRX Layer 2 Bridge
You need to keep all vlans on a physical interface as "routed style" (family inet ...) or convert all of them to a vlan + l3-interface (int vlan unit xxx) + family bridge It's tough because once you go to bridging you lose some functionality and certain interfaces types (example, gig-e SFP mini-pim) are supported only in more recent releases. -Will On Fri, Nov 21, 2014 at 10:59:12AM -0600, Levi Pederson wrote: > Date: Fri, 21 Nov 2014 10:59:12 -0600 > From: Levi Pederson > To: juniper-nsp@puck.nether.net > Subject: [j-nsp] SRX Layer 2 Bridge > > All, > > I'm in a bit of a quandry. I need to land a vlan on a Tagged interface and > then have it processed by the l3 vlan interface. > > I currently have 5 different tags landing on that interface and would like > to add another. > > Has anyone accomplished this. All the internet has given me is the use of > the "family bridge" and that is being rejected as there is an "inet" > statement (on another Logical interface) in existence. > > Thank you, > > *Levi Pederson* > Mankato Networks LLC > cell | 612.481.0769 > work | 612.787.7392 > levipeder...@mankatonetworks.net > ___ > 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] Do the old M-series fixed optic SONET/SDH PICs wear out?
I've come across things like: http://assets.newport.com/webDocuments-EN/images/AN29_Life_Test_Laser_Diode_1310nm_IX.PDF Which seem to indicate that 30,000-50,000 hours of life from a 1310nm laser diode is within reason (but that's at 60C, and with control circuitry that limits to 20% increase in drive current, and putting out 5mW which is more power than the SM-IR I have). I know for sure that the modules I have have been live for at least 70,000 hours, and they were probably 4-5 years old when I got them, and they were older than the tech referenced in that 2006 paper. If this is all the case it seems like we'd be seeing lots of early-2000's fixed optic Juniper PICs start dying. Maybe enough have come out of service that people just trash them without comment. -Will ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Do the old M-series fixed optic SONET/SDH PICs wear out?
I have a couple P(E)-4OC3-SON-SMIR that I purchased used and successfully ran in a production network in the 2007-2009 timeframe. Then, about 5 years ago the OC3 links were taken out of service and the PICs sat in their routers (an M10 and an M20) for 4-5 more years doing nothing. The ports were set "disable" but the PIC was online, so I believe the optical transmitters were still active. Now I'm trying to reussurect them for lab use and I cannot for the life of me get them to link up back-to-back. Only one port out of eight will even go "green" when looped to itself with a 1m patch cable. None will link port-to-port. LOL clears and I get PLL lock, but then either LOS or LOF, AIS, BERR, etc on both sides. I've tried: -multiple patch cables (yes they're SMF) -cleaning the cables' SC connector with tissue/alcohol -blowing canned air into the ports on the PIC -5 & 10db optical attenuators in case it was rx overload even though that shouldn't matter -verifying tx/rx strands and swapping just in case -every combination of clocking,enable/disable scrambling, crc16/32, etc -JUNOS 10, 11, and 12 in both M10 and M20 with FPC-E Unfortunately I don't have a light meter. But I'm starting to think the transmitters might just be toast and not pushing enough light to present a usable signal to the other end even with only a 1m patch. http://www.juniper.net/techpubs/software/junos/junos85/swconfig85-network-interfaces/id-12763130.html says: "To extend the life of the laser, when a SONET/SDH PIC is not being actively used with any valid links, take the PIC offline until you are ready to establish a link to another device. To do this, issue the request chassis pic offline fpc-slot slot-number pic-slot slot-number operational mode command" Is this a real thing? Is 10-15 years in the expected usable lifetime of a circa-2001 1310nm laser? -Will Orton ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VLAN sub-ints and VPLS
> ge-0/0/12 {
> encapsulation ethernet-vpls;
> unit 0 {
> encapsulation vlan-vpls;
> input-vlan-map {
> push;
> tag-protocol-id 0x8100;
> vlan-id 123;
> }
> output-vlan-map pop;
> family vpls;
> }
> }
>
> but I dont seem to be able to get the right combination of
> encapsulations and other settings to be able to commit.
>
> Q2. Does anyone have a working example I could look at?
This works for me on MX to swap .1q 2700 to 603 in the VPLS.
ge-1/0/4 {
flexible-vlan-tagging; // plain vlan-tagging would be ok too
encapsulation flexible-ethernet-services;
unit 2700 {
encapsulation vlan-vpls;
vlan-tags outer 2700;
input-vlan-map {
swap;
vlan-id 603;
}
output-vlan-map swap;
family vpls;
}
So your example looks okay except the encaps on the phys interface.
I haven't tried on SRX (yet); not sure what is correct if you don't
want or can't do flexible-ethernet-services.
> Also, are VPLS and L2VPN the same thing or different? Once source I
> read said L2VPN is ptp while VPLS is ptmp.
That's basically it. VPLS being multi-point means your PE routers are
mac-learning, snd you can of course have a full range of issue like
layer-2 loops (hence STP coming into play sometimes too). l2vpn is
simpler.
-Will
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MPLS PEs out in the last-mile
I have found recently that we are pushing MPLE PE's closer and closer out towards some customers, which means sometimes across flaky RF and DSL last-mile type connections. Usually this is with small SRX's, to provide a managed-endpoint for L2VPN over nasty last-mile topology. Is there some way to have a PE hanging out in the breeze without setting it up directly in my IGP? I don't really want last-mile IGP churn from hundreds of "micro-PEs" in my network. Does it work to build the MPLS LSPs to endpoints learned over BGP instead of an IGP, since I need BGP to the local POP's RRs for L2VPN NLRI anyway? I'm waiting on some junosphere credits to test this out but thought I'd ask what others are doing. -Will ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Migration of RE between M20 and M5/10
Wondering if anyone's tried to do this before: I need to test/set up a RE-600 in a lab M20 and then move it to a live M10. Is there any way to get junos (9.x) to install the M5/10 PFE package while running in the lab M20 so I don't have to have the live M10 down for a whole 'request system software add ...' cycle to get the pfe package correct. Maybe I should buy a cheap M10 for the lab instead? That costs more than the RE-600 of course... -Will Orton ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] RE-850 memory/ram refurb
I have serveral RE-850-1536's that are starting to show ECC erorrs and HD failures. I replaced the CF cards a couple years ago but I suppose it's time for more parts to die now. (These are gray-market/non-support contracted). For the drives I'm guessing Hitachi HTE541040G9AT00 might be a good fit: http://www.hitachigst.com/tech/techlib.nsf/techdocs/58B76A9EC8766D3B86256F0900747A03/$file/E5K100_DS.pdf The drives I seem to be pulling out of the RE's are Hitachi HTS, not the "enhaced availability" version, though I have no idea if they're the original Juniper supplied or if the previous owner messed with them too. The memory is proving to be a little harder to find. Are they just regular PC133/ECC/CL3, maybe similar to what works in RE-3.0? Seem that info on this particular RE is hard to find, maybe not enough of them have starting dying yet... -Will ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] BGP import policy not refreshing properly
I have 2 POPs each with a connection to a common upstream. The upstream
is sending me MEDs, but lots of routes have (missing or 0) MEDs and I
want to reset those to a fixed value so I can tweak them later.
So I have an import policy on each BGP session like so:
term setall-meds {
from metric 0;
then {
metric 3;
}
}
term def {
then {
local-preference 110;
accept;
}
}
term rej {
then reject;
}
I apply this on both routers and get, for example:
At POP A (M10i 9.3R1.7):
A DestinationP Prf Metric 1 Metric 2 Next hopAS path
* 64.152.0.0/13 B 170110 0 >(TO POP B) 3356 I
B 170110 3 >(UPSTREAM AT A) 3356 I
At POP B (M10 9.3R3.8):
A DestinationP Prf Metric 1 Metric 2 Next hopAS path
* 64.152.0.0/13 B 170110 0 >(UPSTREAM AT B) 3356 I
So the M10 at POP B doesn't appear to be applying the import policy and
setting the MED to 3. POP A as a result picks the route through B.
(Yes, I waited more than the 15 minutes for POP B's CPU to go back to
idle so the RE-333-768 churned through the whole table).
This resolved itself with a hard clear of the BGP session to the upstream
at POP B. 'soft-intbound' clear at B didn't do it (other than pegging the
RE CPU for another 15 minutes).
Any ideas? JUNOS bug? Old/decrepit RE getting non-deterministic
with age? Do I really have to hard-clear the BGP session on the 'B'
router any time I change the import policy now? :/
-Will Orton
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] ATM <-> Ethernet TCC or VPLS, converting from cisco
Hey all,
I have a working config running on a Cisco 7206 I've inherited.
It looks like a TCC between an ATM DS3 PVC and a fast-E VLAN:
interface ATM1/0
no ip address
atm scrambling cell-payload
atm framing cbitplcp
no atm ilmi-keepalive
no atm enable-ilmi-trap
pvc 1/100 l2transport
ubr 44209
encapsulation aal5snap
interface FastEthernet2/0
description Trunk to switch
no ip address
duplex full
interface FastEthernet2/0.101
encapsulation dot1Q 101
connect foo ATM1/0 1/100 FastEthernet2/0.101 interworking ethernet
--
The ATM PVC is a feed into a VPLS cloud (all IP addressed in a /24).
The ethernet VLAN feeds to another router (also with an address in the
/24). So ARP and IPv4 packets are getting switched between this
ethernet and the VPLS cloud out on the ATM (out of my control).
Now, I want to replace this with an M20 with a 4FE PIC and a DS3 ATM
PIC. It really seems like I just want a ATM PVC - ethernet TCC:
unit 910 {
encapsulation vlan-tcc;
vlan-id 910;
family tcc {
proxy {
inet-address 10.1.1.1;
}
remote {
inet-address 10.1.1.2;
}
[...]
but in my case, the proxy and remove inet-addresses don't make sense. I
need ARP to get passed through the TCC since there's 200 other IPs
(remote site routers) on the provider side of the ATM.
Do I need to do something like a 2-port VPLS setup locally on my M20
instead (so as to handle the ARP correctly, with multiple IPs out on the
ATM)?. That seems like it would work, but then I need a ATM2 DS3 card
instead of an ATM1 ($$), and suddenly it becomes cheaper to leave the
Cisco in place.
Any ideas?
--
-Will Orton :: http://www.loopfree.net/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
