Re: [j-nsp] BCP for filtering management access, system-wide
Assuming an MX, application of the filter can be applied to the loopback interface. This will effectively provide a "system wide" filter. Yes, you would need to allow for control-plane protocols and such. Doug Hank's MX book has a very excellent layout of this methodology: https://www.safaribooksonline.com/library/view/juniper-mx-series/9781449358143/ch04s01.html It also goes into methods of using dynamic prefix filters that update whenever a new interface (address) or bgp peer or whatever is added. That all works pretty well on MX gear, EX is a bit of a different beast and your filter space is much much smaller. Hope that helps a bit, --chip On Mon, Jul 25, 2016 at 4:55 PM, Jason Lixfeld wrote: > Hi, > > I’m trying to write filters to prevent management access to my system > (ssh, SNMP, etc), and I’m unsure about where to apply them. > > Let’s assume I have IPs configured on a bunch of interfaces, both physical > and logical, and I don’t want the majority of them to be able to accept > management attempts to my system. > > One way to prevent this is is to apply a filter to each interface where > there is an IP configured, but I can’t imagine that scales very well. > > Another way I was reading about is to apply a filter via > forwarding-options: > > set forwarding-options family inet filter > > Is this an appropriate way to accomplish this, or should I be looking at a > different method? > > If this is acceptable, my next question is bound to be how a system-wide > filter like that would affects protocols that actually need to talk to the > RE, like BFD, ISIS, BGP, etc., but maybe I can leave that for another > thread :) > > Previously, I tried to apply filters to various lo0 units, thinking those > were the only interface to the RE, but that didn’t seem to help for cases > where the IPs were applied to interfaces other than lo0 units. And I > haven’t been able to find a way to apply a filter or client list > specifically to the ssh service itself like you can with snmp, for example. > > Thanks in advance. > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp -- Just my $.02, your mileage may vary, batteries not included, etc ___ 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
Juniper has a "This Week" book freely available that discussess, in detail, the path of a packet through an MX. It's quite an informative read. http://www.juniper.net/us/en/training/jnbooks/day-one/networking-technologies-series/packet-walkthrough-mx-series/ This Week: An Expert Packet Walkthrough on the MX Series 3D provides the curious engineer with a global view of the short life (a few milliseconds) of packets inside the Juniper Networks MX Series of 3D routers. Cisco had a CEF book that was pretty decent too. --chip On Tue, Mar 29, 2016 at 7:58 AM, Mark Tees wrote: > I watched a video the other day describing the manufacturing process Cisco > used for the UADP ASIC does that count? ;) > > I think it's actually a missing part of the puzzle in most training > material but possibly because previously it has been something vendors > don't talk about much? > > On Tuesday, 29 March 2016, Adam Vitkovsky > wrote: > > > > Saku Ytti [mailto:s...@ytti.fi ] > > > Sent: Monday, March 28, 2016 12:24 PM > > > > > > On 28 March 2016 at 13:32, Adam Vitkovsky > > > > wrote: > > > > > > > Public means exposed to whims of the wild Internet, that is in both > > data > > > rates (DDoS) and updates (Malformed BGP updates) something you can't > > > control. > > > > Private means very good control over traffic rates and control plane > > > > (number of updates,...) > > > > > > QoS should guarantee that Internet DDoS does not hurt L3 MPLS VPN. And > > > BGP free core should guarantee that core does not core(SIC) on random > BGP > > > UPDATE. > > > > > Hey Saku, > > > > Yes please, with BGP free core one usually relies on RRs and my point is > > that it's a good practice to run separate BGP process/RR (or at least > > sessions) for public control plane so malformed update that would god > > forbid cause iBGP session reset won't affect private control-plane > sessions. > > > > With regards to QOS, > > In my opinion QOS is just a small piece in the puzzle (as a meter of fact > > it's not even the first thing that matters when a packet hits the box) > and > > I think that one has to be well versed with how an ideal data-plane > > architecture looks like in order to be able to assess the HW capabilities > > and all the chokepoints across the chassis at hand correctly. Only then > one > > can tell whether a particular HW fits the design requirements. There are > > cases were one doesn't need to bother but designing a converged network > is > > not one of them. > > > > That said, I'd like to encourage all folks on the list to get educated in > > how routers work, it's fun trust me. I find it striking how much we know > > about how control-plane works (SR, BGP, ISIS ...) but so little about a > > life of a packet through the data-plane, even though a great deal of info > > is available online (though don't expect any fancy certificates for > knowing > > this stuff). Every time I ask a data-plane question on the list I get > > little relevant info and Saku is basically the only one whom I may > discuss > > these topics with except the vendor folks. > > > > adam > > > > > > > > > > > > > > > > > > > > > > > > Adam Vitkovsky > > IP Engineer > > > > T: 0333 006 5936 > > E: adam.vitkov...@gamma.co.uk > > W: www.gamma.co.uk > > > > This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents > > of this email are confidential to the ordinary user of the email address > to > > which it was addressed. This email is not intended to create any legal > > relationship. No one else may place any reliance upon it, or copy or > > forward all or any of it in any form (unless otherwise notified). If you > > receive this email in error, please accept our apologies, we would be > > obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or > > email postmas...@gamma.co.uk > > > > Gamma Telecom Limited, a company incorporated in England and Wales, with > > limited liability, with registered number 04340834, and whose registered > > office is at 5 Fleet Place London EC4M 7RD and whose principal place of > > business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 > 5BY. > > > > > > ___ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > -- > Regards, > > Mark L. Tees > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Just my $.02, your mileage may vary, batteries not included, etc ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Snapshot from shell?
Good evening. I've got an SRX5400 that doesn't like to boot from it's compact-flash (ad0) but refused to acknowledge that the part exists when trying to use the `request system snapshot media compact-flash` command. So I'm curious if anyone knows of a procedure for doing the equivalent of a `request system snapshot` from the shell, rather than through the cli. Thanks -- Chip Marshall http://2bithacker.net/ signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Leaking from a vrf to inet0
Hi Raphael,
If I'm understanding what you want correctly you can use rib-groups to do
this.
routing-options {
rib-groups {
FROM-VRF-TO-GLOBAL {
import-rib [ SOURCE-VRF inet.0 ];
import-policy WHATEVER-POLICY-YOU-WANT;
}
}
}
see:
http://forums.juniper.net/t5/TheRoutingChurn/Using-rib-groups-or-auto-export-for-route-leaking/ba-p/202349
http://kb.juniper.net/InfoCenter/index?page=content&id=kb16133&actp=search
--chip
On Mon, Mar 21, 2016 at 12:04 PM, Raphael Mazelier
wrote:
> Hello,
>
> I am currently evaluating how to migrate the internet dmz, and the public
> pfx of my customers into VRF.
> During the migration phase I have to leak pfx from vrf to the global table.
> Don't ask why, but I cannot do the leaking on the PE-CE side as it should
> normaly occur.
> So I want to do leaking on the remote PE from pfx learned via mp-bgp on
> the vrf to the global, and afaik it is not possible directly.
>
> I know that this topic have been discussed before, but if someone have
> some hints on how to do this the cleanest way possible.
>
> Options I found in old threads are :
> - use static routes with next-table (tested and work but completely manual)
> - use a lt interface between global and vrf (and use some routing protocol
> ?)
> - advertise twice the route in family inet in addition to inet-vpn, in
> order to leak it with rib-group (since rib-group only work when pfx is in a
> primary table)
>
> This last solution seems to be the less manual (I don't want to make
> config for each pfx) but seems tricky/ugly.
> I got a working setup with these but definitively looks weird.
>
> What are your opinions/hints ?
>
> --
> Raphael Mazelier
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
--
Just my $.02, your mileage may vary, batteries not included, etc
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RTBH
A strategy that I've seen used is to pick some ip address and add a static
route for it pointing to discard on every router. Then when you receive
the route to black-hole, set the next-hop to the discard route. This way
all routers will drop traffic for the prefix as soon as it enters the
router instead of running through your network first.
On Thu, Jan 14, 2016 at 4:10 PM, Johan Borch wrote:
> Hi!
>
> I have implemented RTBH in my small network of 8 routers. DFZ is running in
> a L3VPN and each router has an multihop ibgp-session with my RTBH-router
> and it works, but I have one thing that annoys me.
>
> If I announce an offending IP to be black holed, only one of the routers
> will point to the discard route. The other 7 will see the announced route
> via BGP från the one that got it first I guess and send the traffic to that
> one where is is discarded. If I do show extensive on the route it is prefer
> because of IGP. I can't figure out how to get each router to prefer the
> discard localy. If I do local pref on one router the other 7 will send the
> traffic there instead.
>
> Every router has
>
> route a.b.c.d/32 {
> discard;
> install;
> }
>
> And from sending RTBH router, they are announced with next-hop a.b.c.d.
>
> Idéas? :)
>
> Regards
> Johan
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Just my $.02, your mileage may vary, batteries not included, etc
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 L2Circuit/VPN to MX80/lt Interface
I was using RSVP at the time, sorry I left that part out. If you're getting one-way traffic it might be that one of the LSPs isn't up. --chip Sent from my mobile device, please excuse any typos. > On Nov 12, 2014, at 5:16 PM, Eduardo Schoedler wrote: > > There's no need to run "protocols ldp" ? > > -- > Eduardo Schoedler > > 2014-11-12 17:18 GMT-02:00 Alexander Arseniev : >> There is a line missing on MX side: >> >> set interfaces lt-0/0/0.0 family ccc >> >> Thanks >> Alex >> >> 12/11/2014 16:51, Raphael Mazelier wrote: >>> >>> >>> >>> Le 11/11/14 22:29, chip a écrit : >>>> >>>> http://pastebin.com/YYfHk9M2 >>>> >>>> That should get you. *Caveats apply* but it does work =) >>>> >>>> --chip >>> >>> >>> Thks you chip. >>> >>> With your configuration I've made some progress. >>> Now I've got some arp replies on the CE connected to the EX : >>> >>> 2.1.1.5 > 2.1.1.6: ICMP echo request, id 26654, seq 11, length 64 >>> 17:42:39.031721 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has >>> 2.1.1.5 tell 2.1.1.6, length 46 >>> 17:42:39.031731 ARP, Ethernet (len 6), IPv4 (len 4), Reply 2.1.1.5 is-at >>> 78:2b:cb:28:2d:55, length 28 >>> >>> The lt mac is correctly learn on the CE. >>> But for one reason or another the mac address of the ce is not learn on >>> the mx80 side ?! >>> >>> >>> I'm just out of luck for this setup :( >> >> ___ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > -- > Eduardo Schoedler ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 L2Circuit/VPN to MX80/lt Interface
http://pastebin.com/YYfHk9M2
That should get you. *Caveats apply* but it does work =)
--chip
On Mon, Nov 10, 2014 at 11:23 AM, Raphael Mazelier
wrote:
> Hello,
>
> I'm redesigning my network, and I have to terminate some customer BGP
> sessions (full view) on new EX4550 (no comment, ... )
>
> Since the EX4550 does not support full view, I had to logicaly terminate
> the session on a real router (MX80 in this case).
>
> The logical way to do is to use bgp multi hop, but some of my customer are
> unaware of changing their settings on their side.
>
> So my plan is to use l2vpn (or l2circuit) between the EX and the MX, and
> to use a virtual interface on the MX to end the sessions.
> And reading some thread it seems that I have to use lt interface.
>
> The l2vpn connections are OK on both side, but nothing is reachable (and I
> have nothing to tcpdump yet).
>
> Bellow is my config :
>
> EX side :
>
> interfaces {
> ge-1/0/11 {
> encapsulation ethernet-ccc;
> unit 0;
> }
> }
>
> routing-instances {
> l2vpn {
> instance-type l2vpn;
> interface ge-1/0/11.0;
> route-distinguisher 666:666;
> vrf-target target:666:666;
> protocols {
> l2vpn {
> encapsulation-type ethernet;
> site EX {
> site-identifier 1;
> ignore-mtu-mismatch;
> interface ge-1/0/11.0 {
> remote-site-id 2;
> }
> }
> ignore-encapsulation-mismatch;
> }
> }
> }
> }
>
> MX side :
>
> interfaces {
>lt-0/0/10 {
> unit 0 {
> encapsulation ethernet-ccc;
> peer-unit 1;
> family ccc;
> }
> unit 1 {
> encapsulation ethernet;
> peer-unit 0;
> family inet {
> address 10.1.1.1/24;
> }
> }
> }
> }
>
> routing-instances {
> l2vpn {
> instance-type l2vpn;
> interface lt-0/0/10.0;
> route-distinguisher 666:666;
> vrf-target target:666:666;
> protocols {
> l2vpn {
> encapsulation-type ethernet;
> site cr-dc2-01 {
> site-identifier 2;
> ignore-mtu-mismatch;
> interface lt-0/0/10.0;
> }
> }
> }
> }
> }
>
>
> Any suggestions ? or other way to do ? (I ve tested l2circuit and it does
> not work anyway)
>
>
> --
> Raphael Mazelier
> AS39605
>
>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
--
Just my $.02, your mileage may vary, batteries not included, etc
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SLAX import problem
On 2013-12-16, OBrien, Will sent: > Try using the absolute path. Relative paths with symbolic links > is great way to break things. Well that's annoying, the symlink does break it. This works: import "/usr/libdata/cscript/import/junos.xsl"; This doesn't: import "/var/db/scripts/import/junos.xsl"; -- Chip Marshall http://2bithacker.net/ pgpPrEbS2B4Ct.pgp Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SLAX import problem
I've got an odd problem on a host that I'm trying to do some SLAX development on, it appears JUNOS is having a problem reading a file I'm trying to import, and I'm really not sure why. The error: error: xsl:import : unable to load /var/db/scripts/import/junos.xsl The offending line: import "../import/junos.xsl"; I did find this KB article that appears to address the same problem, but I don't appear to be having the same issue: http://kb.juniper.net/InfoCenter/index?page=content&id=KB28188 % ls -al /var/db/scripts/ total 24 drwxr-xr-x 6 root wheel 512 Dec 13 18:13 . drwxr-xr-x 16 root wheel 512 Dec 13 18:20 .. drwxrws--- 2 root wheel 512 Nov 6 10:18 commit drwxrws--- 2 root wheel 512 Nov 6 10:18 event lrwxr-xr-x 1 root wheel 27 Dec 13 18:13 import -> /usr/libdata/cscript/import drwxrws--- 2 root wheel 512 Nov 6 10:18 lib drwxrws--- 2 root wheel 512 Dec 13 18:19 op This is on an SRX running 12.1X44-D10.4. Any ideas? -- Chip Marshall http://2bithacker.net/ pgpJl2aePRazq.pgp Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Format of SHA1 Passwords
On 2013-12-03, Paul Goyette sent: > Looks like the output is identical to what would be generated by > the *BSD pwhash(1) utility. > > # pwhash -S 24680 stuff > $sha1$23933$/WgTkHoe$25rdwdZ95cfgY/Tl6li2/LRIbuVT > # > > pwhash(1) in turn calls the crypt(3) library function after it > generates a salt. > > Digging through the sources, we find the following comment block > in src/lib/libcrypt/crypt-sha1.c Ah ha! Perfect! It appears this is specifically a NetBSD thing, or at least my OpenBSD and FreeBSD boxes don't have crypt-sha1.c or the pwhash utility. -- Chip Marshall http://2bithacker.net/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Format of SHA1 Passwords
On 2013-12-03, Chris Morrow sent: > > I get things like "$sha1$19418$aoTClyGU$cix8MhZsXwG6OrwUgeHAoOA8f.AX" > > where it appears to have the format, some number, what I think is > > the salt, and then the hash. > > > > Anyone know how these things are calculated? > > we do this calculation I believe your intended format is: > $1$salt$hash > > or that seems to be what our code does. That's for MD5 passwords. I have a requirement to use SHA-1. -- Chip Marshall http://2bithacker.net/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Format of SHA1 Passwords
I'm trying to write a utility for generating JUNOS-compatible password hashes outside of JUNOS, and I've hit a bit of a stumbling block with JUNOS SHA-1 passwords. They don't seem to follow the normal crypt() pattern of $format$salt$hash and I can't seem to find the format documented anywhere. I get things like "$sha1$19418$aoTClyGU$cix8MhZsXwG6OrwUgeHAoOA8f.AX" where it appears to have the format, some number, what I think is the salt, and then the hash. Anyone know how these things are calculated? -- Chip Marshall http://2bithacker.net/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L2Circuit VLAN-CCC EX4550
Try it like the below, terminating them on brocade gear and saw similar issues. You might need to check MTU operation too. set interfaces xe-0/0/1 description customer-3 set interfaces xe-0/0/1 vlan-tagging set interfaces xe-0/0/1 encapsulation vlan-ccc set interfaces xe-0/0/1 mtu 9216 set interfaces xe-0/0/1 unit 3143 description customer--3 set interfaces xe-0/0/1 unit 3143 encapsulation vlan-ccc set interfaces xe-0/0/1 unit 3143 vlan-id 3143 Then the l2circuit neighbor stuff looks like this: set protocols l2circuit neighbor interface xe-0/0/1.3143 virtual-circuit-id 1029 set protocols l2circuit neighbor interface xe-0/0/1.3143 description customer-3 set protocols l2circuit neighbor interface xe-0/0/1.3143 no-control-word set protocols l2circuit neighbor interface xe-0/0/1.3143 encapsulation-type ethernet set protocols l2circuit neighbor interface xe-0/0/1.3143 ignore-encapsulation-mismatch set protocols l2circuit neighbor interface xe-0/0/1.3143 ignore-mtu-mismatch Hope that helps and good luck! --chip On Fri, Aug 23, 2013 at 8:25 AM, Giuliano Medalha wrote: > People, > > We have an issue when implementing vlan-CCC in JUNIPER EX4550 switches. > > When we put the port like the following mode: > > set interfaces xe-0/0/10 encapsulation vlan-ccc > set interfaces xe-0/0/10 vlan-tagging > set interfaces xe-0/0/10 unit 600 vlan-id 600 > > When we close L2Circuit with non-JUNIPER switches (like cisco or extreme) > the EX4550 is doing a kind of POP in Ethernet framing removing the VLAN-ID > (frames incoming xe-0/0/10 port). > > The communication cannot be established with the neighbor switch. > > Using MX series at the same environment there is no problems and the > behavior is correct (the 802.1Q label entering the port is not altered). > > Do you think there is some kind of bug on JUNOS code for EX4550 ? > > Or this behavior can be modified ? > > Thanks a lot, > > Giuliano > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Just my $.02, your mileage may vary, batteries not included, etc ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SNMP on logical-system fxp0
So, I have an MX5 with it's fxp0 management interface connect to
one network, which I've placed in a logical-system so it can have
it's own default route for out-of-band management.
> show configuration logical-systems
Management {
interfaces {
fxp0 {
unit 0 {
family inet {
address 172.16.10.4/24;
}
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop 172.16.10.1;
}
}
}
I've also enabled SNMP:
community public {
authorization read-only;
clients {
172.16.10.0/24;
}
}
traceoptions {
file size 10m files 10;
flag all;
}
And I've confirmed that SNMP requests are being received and
answered based on the snmpd trace logs.
The problem is the replies to SNMP queries are being routed out
using the main system's routing table, not the routing table of
the logical-system. I have confirmed this with packet captures.
I'm at a bit of a loss on how to correct for this. If it were a
routing-instance, I could just export the direct route into the
main inet.0, but that doesn't appear to be possible with a logical-
system, and I can't use fxp0 with a routing-instance.
I feel like this should be a fairly common configuration, placing
the management interface out-of-band and doing SNMP on that
interface, but I haven't found a lot of useful information
through searching.
Any recommendations?
--
Chip Marshall
http://2bithacker.net/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] next-hop self and RR
With other platforms next-hop-self is applied as a bgp attribute in
the configuration of the process. When that's done, they usually
follow the RFC faithfully in that regard. However upon applying
outbound policy the next-hop attribute is allowed to be modified. To
me, modification of the next-hop attribute that can only be modified
with outbound policies is what Junos is allowing you to do here and
that matches up with the way other platforms are enabling this
ability.
--chip
On Thu, Nov 8, 2012 at 10:45 AM, Mihai Gabriel wrote:
> Hello,
>
> Is Juniper's implementation of next-hop self on a RR a violation of
> RFC1966?
>
> " In some implementations, modification of the BGP path attribute,
>NEXT_HOP is possible. For example, there could be a need for a RR to
>modify NEXT_HOP for EBGP learned routes sent to its internal peers.
>However, it must not be possible for an RR to set on reflected IBGP
>routes as this breaks the basic principle of Route Reflection and
>will result in potential black holeing of traffic."
>
> Testing this feature in a topology with 3 routers, r1 (client) - r3 (rr) -
> r2 (client) , a route originated from r1 and advertised to r2 via it's RR
> will have a next-hop of RR when an export policy is applied to r2:
>
> mihai@mx5t# run show route receive-protocol bgp 10.0.6.1 logical-system r3
> 192.168.10.0
>
> inet.0: 32 destinations, 33 routes (32 active, 0 holddown, 0 hidden)
> Prefix Nexthop MED LclprefAS path
> * 192.168.10.0/24 10.0.6.1 100I
>
> mihai@mx5t# show protocols bgp group 65000 neighbor 10.0.6.2
> export nh-self;
>
> show policy-options policy-statement nh-self
> from {
> protocol bgp;
> neighbor 10.0.6.1;
> }
> then {
> next-hop self;
> }
>
> mihai@mx5t# run show route advertising-protocol bgp 10.0.6.2 logical-system
> r3 match-prefix 192.168.10.0
>
> inet.0: 32 destinations, 33 routes (32 active, 0 holddown, 0 hidden)
> Prefix Nexthop MED LclprefAS path
> * 192.168.10.0/24 Self 100I
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Just my $.02, your mileage may vary, batteries not included, etc
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS design - dual homed
In VPLS, loop avoidance is arranged by the following rule: A PE never forwards a frame received from a PE, to another PE. The use of a full mesh combined with split horizon forwarding guarantees a loop-free broadcast domain. From: wikipedia http://en.wikipedia.org/wiki/Virtual_Private_LAN_Service#Ethernet_emulation So it's much like ibgp. --chip On Mon, Oct 29, 2012 at 7:19 PM, Luca Salvatore wrote: > Hi Guys, > > I have a question regarding dual VPLS links. My topology will look like this: > > MX1-darkfibre--MX2 > | | > | | > MX3-darkfibre--MX4 > > So above you see that there are dual links which will create a loop. > > How does VPLS handle these types of topologies? Do I need to just use > spanning tree and have one link in blocking? > Or perhaps use MSTP and send some VLANs down one link and some down the other? > I will be spanning around 1000 VLANs across these links. They are 10Gb links, > so it seems a shame to have one in a blocking state. > > Any other recommendations? Perhaps M-LAG? > Thanks, > > Luca. > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp -- Just my $.02, your mileage may vary, batteries not included, etc ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JNCIE-SP Personal LAB
There's always the junosphere route. Just make sure you have your topology and ip addressing down when you start so as to not waste the time. Sent from my mobile device, please excuse any typos. On Aug 2, 2012, at 10:39 AM, Diogo Aleixo Vieira wrote: > > > > > Hi all, I am trying to set up a personal lab to JNCIE-SP studies, first of > all I tryed to use Olive but I figure out that it has several limitation to > simulate all the features of the lab. > So now I am looking for a cheap hardware running Junos to simulate the lab, > anyone has any idea of hardware to simulate that? > I thought in SRX branch family but they do not implement logical systems and > I am affraid about this limitation. Thanks, Diogo > ___ > 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] EX3200 vs. EX4200 MPLS
Tomasz,
Thanks for the link, I was going to post that earlier, but got
sidetracked. Anyway, after looking through it, apparently almost none
of the EX's support CCC. Unless I'm reading in the wrong place.
However:
{master:1}
lab@edge1.lab001> show configuration interfaces ge-0/0/9
unit 0 {
family ccc;
}
{master:1}
lab@edge1.lab001>
Hostname: edge1.lab001
Model: ex4500-40f
JUNOS Base OS boot [11.4R1.6]
JUNOS Base OS Software Suite [11.4R1.6]
JUNOS Kernel Software Suite [11.4R1.6]
I haven't actually tried to set one up, but the commit works
--chip
On Mon, Apr 30, 2012 at 5:37 PM, Tomasz Mikołajek wrote:
> Hello.
> ON this site you have list of software features:
> http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/ex-series-software-features-overview.html#mpls-features-by-platform-table
>
> 2012/4/30 Skeeve Stevens
>>
>> Thanks Chip!
>>
>> Any docs or anything like that around on the limits on these sorts of
>> things?
>>
>> *Skeeve Stevens, CEO*
>> eintellego Pty Ltd
>> ske...@eintellego.net ; www.eintellego.net <http://www.eintellego.net.au>
>>
>>
>> Phone: 1300 753 383 ; Fax: (+612) 8572 9954
>>
>> Cell +61 (0)414 753 383 ; skype://skeeve
>>
>> facebook.com/eintellego
>>
>> twitter.com/networkceoau ; www.linkedin.com/in/skeeve
>>
>> PO Box 7726, Baulkham Hills, NSW 1755 Australia
>>
>> The Experts Who The Experts Call
>> Juniper - Cisco – IBM
>>
>>
>>
>> On Tue, May 1, 2012 at 00:10, chip wrote:
>>
>> > Ok, now that I've said that, I realize that's for the 4500, not sure
>> > on the 4200's. Also, its not clear on whether that number scales if
>> > you start clustering things.
>> >
>> > --chip
>> >
>> > On Mon, Apr 30, 2012 at 10:08 AM, chip wrote:
>> > > I seem to recall a 4200 could do around 120ish CCC's, with some
>> > > updated (hardware?) software that number should almost double.
>> > >
>> > > --chip
>> > >
>> > > On Sun, Apr 29, 2012 at 11:39 PM, Chris Kawchuk
>> > >
>> > wrote:
>> > >> I have yet to run into any limit. There probably is one, but would
>> > >> need
>> > to Lab it up and try to max it out.
>> > >>
>> > >> I've heard of people using EX3200/4200s as a pure MPLS CCC endpoint
>> > device (i.e. 1 LSP per physical port) as some kind of wacky olde-style
>> > "M13
>> > Mux" like we used to do in the TDM days; so at least as many CCC's as
>> > there
>> > are physical ports on the box would be a minimum at my guess. You can do
>> > CCC per-VLAN as well, so your can get many more LSPs than just the # of
>> > physical IFDs.
>> > >>
>> > >> - CK.
>> > >>
>> > >> On 2012-04-30, at 1:33 PM, Skeeve Stevens wrote:
>> > >>
>> > >>> Chris/Ben,
>> > >>>
>> > >>> How would I go about finding how how many CCC the EX3200/4200 can
>> > support?
>> > >>>
>> > >>> ...Skeeve
>> > >>
>> > >> ___
>> > >> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> > >> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> > >
>> > >
>> > >
>> > > --
>> > > Just my $.02, your mileage may vary, batteries not included, etc
>> >
>> >
>> >
>> > --
>> > Just my $.02, your mileage may vary, batteries not included, etc
>> >
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
--
Just my $.02, your mileage may vary, batteries not included, etc
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX3200 vs. EX4200 MPLS
Ok, now that I've said that, I realize that's for the 4500, not sure on the 4200's. Also, its not clear on whether that number scales if you start clustering things. --chip On Mon, Apr 30, 2012 at 10:08 AM, chip wrote: > I seem to recall a 4200 could do around 120ish CCC's, with some > updated (hardware?) software that number should almost double. > > --chip > > On Sun, Apr 29, 2012 at 11:39 PM, Chris Kawchuk wrote: >> I have yet to run into any limit. There probably is one, but would need to >> Lab it up and try to max it out. >> >> I've heard of people using EX3200/4200s as a pure MPLS CCC endpoint device >> (i.e. 1 LSP per physical port) as some kind of wacky olde-style "M13 Mux" >> like we used to do in the TDM days; so at least as many CCC's as there are >> physical ports on the box would be a minimum at my guess. You can do CCC >> per-VLAN as well, so your can get many more LSPs than just the # of physical >> IFDs. >> >> - CK. >> >> On 2012-04-30, at 1:33 PM, Skeeve Stevens wrote: >> >>> Chris/Ben, >>> >>> How would I go about finding how how many CCC the EX3200/4200 can support? >>> >>> ...Skeeve >> >> ___ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > -- > Just my $.02, your mileage may vary, batteries not included, etc -- Just my $.02, your mileage may vary, batteries not included, etc ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX3200 vs. EX4200 MPLS
I seem to recall a 4200 could do around 120ish CCC's, with some updated (hardware?) software that number should almost double. --chip On Sun, Apr 29, 2012 at 11:39 PM, Chris Kawchuk wrote: > I have yet to run into any limit. There probably is one, but would need to > Lab it up and try to max it out. > > I've heard of people using EX3200/4200s as a pure MPLS CCC endpoint device > (i.e. 1 LSP per physical port) as some kind of wacky olde-style "M13 Mux" > like we used to do in the TDM days; so at least as many CCC's as there are > physical ports on the box would be a minimum at my guess. You can do CCC > per-VLAN as well, so your can get many more LSPs than just the # of physical > IFDs. > > - CK. > > On 2012-04-30, at 1:33 PM, Skeeve Stevens wrote: > >> Chris/Ben, >> >> How would I go about finding how how many CCC the EX3200/4200 can support? >> >> ...Skeeve > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp -- Just my $.02, your mileage may vary, batteries not included, etc ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Ethernet OAM, specifically CFM
Thanks for all the input. I'm beginning to get an understanding here. So, the vlan sub-int on the MX could be a MEP. The port on the switch where the customer connects can't be a MEP. We'll have to assume that I have no administrative control whatsoever over the customer router. I can't even insure that it's a router. Could be an ASA, could be a server, could be a router, just random device that can route packets to some extent. I would like to vlan connections back up to the MX for layer-3 configurations. My problem is that if the customer facing port on the switch goes down, it won't take down the layer-3 int on the MX, thus sending packets to nowhere. The IRB instance sounds interesting, I'll try playing with that as well. Thanks for the input all, much appreciated! --chip On Fri, Apr 20, 2012 at 4:57 PM, Keegan Holley wrote: > CFM wouldn't monitor a link with no MEP on the other end of it. So you > can't have a router a switch and then a link from the switch to a customer > and monitor a link to a customer where the customer isn't running CFM on > their equipment. > > 2012/4/20 Humair Ali >> >> Actually CFM would be appropriate with what Chip is trying to achieve, >> >> CFM monitor a maintenance session end to end and works a vlan or link >> level. >> >> Why not monitor Cust Rtr interface to MX1 accross the bridge network via >> CFM and have an action profile assign to it ? >> >> or monitor Cust Rtr 1 to remote end Cust Rtr 2 CFM , since usually you >> would want to use CFM to guarantee a service. >> >> >> On 20 April 2012 18:20, Keegan Holley wrote: >>> >>> CFM just performs a continuity check so I'm not sure it will help you >>> here. In other words it just checks if the CFM instance on the switch >>> can >>> talk to the CFM instance on the router. If I understand your question >>> correctly you're trying to verify an access point leading to a customer >>> and >>> not your MX. If there is only one access port per VLAN interface can you >>> move it down to the switch? >>> >>> >>> 2012/4/20 chip >>> >>> > Hi folks, >>> > >>> > 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. >>> > Possibly this will help: http://imgur.com/MMrZm >>> > >>> > Ultimately my goal is to detect an outage on the access port and take >>> > down the layer-3 interface on the MX so I won't blackhole traffic. >>> > Since that interface won't go down if the access port on the >>> > downstream switch does. Or maybe there's a better solution. Either >>> > way, if someone has this setup and can supply some example configs I >>> > would be ever so grateful. I can't quite seem to work it out. >>> > >>> > Thanks all! >>> > >>> > --chip >>> > >>> > -- >>> > Just my $.02, your mileage may vary, batteries not included, etc >>> > >>> > ___ >>> > 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 >> >> >> >> >> -- >> Humair >> > -- Just my $.02, your mileage may vary, batteries not included, etc ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Ethernet OAM, specifically CFM
Hi folks, 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. Possibly this will help: http://imgur.com/MMrZm Ultimately my goal is to detect an outage on the access port and take down the layer-3 interface on the MX so I won't blackhole traffic. Since that interface won't go down if the access port on the downstream switch does. Or maybe there's a better solution. Either way, if someone has this setup and can supply some example configs I would be ever so grateful. I can't quite seem to work it out. Thanks all! --chip -- Just my $.02, your mileage may vary, batteries not included, etc ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] acceptable/good laser receive power in case of different interfaces
Depending on whose optics you're using there should be a data sheet that shows the acceptable Tx/Rx levels for each type available from your vendor. I can't seem to locate a document for Juniper at the moment. But I assume they shouldn't be that far off from Cisco stuff. For example, here's a data sheet for the XENPAK module: http://www.cisco.com/en/US/prod/collateral/modules/ps2797/ps5138/product_data_sheet09186a008007cd00_ps5455_Products_Data_Sheet.html Check Table-2. As far as I know, an optic will output power within a specified range as according to what type it is, SR, LR, ER, ZR, etc... Hope that helps a bit. On Tue, Aug 2, 2011 at 5:26 PM, Martin T wrote: > What is the acceptable Rx power in case of SFP/XFP? For example, here > are XFP Tx and Rx signals from six FXP's: > > 1: > Laser output power : 1.2920 mW / 1.11 dBm > Laser rx power : 0.0285 mW / -15.45 dBm > > 2: > Laser output power : 0.6420 mW / -1.92 dBm > Laser rx power : 0.3054 mW / -5.15 dBm > > 3: > Laser output power : 0.4230 mW / -3.74 dBm > Laser rx power : 0.5092 mW / -2.93 dBm > > 4: > Laser output power : 0.4180 mW / -3.79 dBm > Laser rx power : 0.4208 mW / -3.76 dBm > > 5: > Laser output power : 1.0920 mW / 0.38 dBm > Laser rx power : 0.1801 mW / -7.44 dBm > > 6: > Laser output power : 0.7680 mW / -1.15 dBm > Laser rx power : 0.3337 mW / -4.77 dBm > > > Is there some sort of pattern? It looks like if the Rx signal is > lower, the Tx is higher? And what can one consider a decent Rx laser > power level? > > > regards, > martin > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Just my $.02, your mileage may vary, batteries not included, etc ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP Blackhole communities
On Wed, Oct 20, 2010 at 7:46 AM, Nick Ryce wrote: > Hi Guys, > > I am starting to play with BGP and have set up some communities to separate > customer, peer and transit routes. I am trying to figure out how to allow > customers to send me a blackhole community number and then blackhole this. > Does anyone have any examples? I have set up most of my communities > following http://puck.nether.net/bgp/juniper-config.html but still cannot > find any work examples of a blackhole community and how, when a customer > adds this to a prefix, I can discard/nullroute this. > > Any help much appreciated > > > Nick > > > http://tools.ietf.org/html/rfc5635 http://packetlife.net/blog/2009/jul/6/remotely-triggered-black-hole-rtbh-routing/ And I'm sure there was a few presentations on this in the NANOG archives but I can't seem to locate them at the moment. There's also lots of hits for 'remote triggered black hole' in your favorite search engine. You just need to decide how big of blocks you want to let your customers advertise to be black holed. You can even take this one step further and announce the prefix to your upstreams with the appropriate communities and have them black hole as well. --chip -- Just my $.02, your mileage may vary, batteries not included, etc ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
