Re: [j-nsp] MX BNG with both local server and dhcp relay
Thanks Andrey, Yes, I believe you are correct. You can't switch from using local DHCP server in the global routing table to DHCP relay once authenticated in a different VRF. I can split my services onto different interfaces coming into the BNG, though since you need to decapsulate them first, they end up on the same demux interface anyway. I analysed a lot of traceoptions and packet captures. My relay didn't receive a single packet, and the logs indicated that it was not looking for DHCP configuration in my VRF that has forwarding configured. I think my only option is to move everything over to DHCP forwarding in all cases, though this seems quite flaky for v6... Regards, Dave On Tue, 10 Jan 2023 at 15:13, Andrey Kostin wrote: > Hi Dave, > > Don't have experience with your specific case, just a common sense > speculation. When you configure local dhcp server it usually specifies a > template interface, like demux0.0, pp0.0, psX.0. Probably in your case a > conflict happens when junos tries to enable both server and relay on the > same subscriber interface. Maybe if you could dynamically enable dhcp > server or relay for a particular subscriber interface it could solve the > issue. Regarding interface separation, I'm not sure if it's possible to > have more than one demux or pp interface, I believe only demux0 is > supported. With ps interfaces you however can have many of them and if > you can aggregate subscribers to pseudowires by service, you could > enable dhcp server or relay depending on psX interface. However, > pseudowires might be not needed and excessive for your design. > Did you try to analyze DHCP and AAA traceoptions and capture DHCP > packets, BTW? > > Kind regards, > Andrey > > Dave Bell via juniper-nsp писал(а) 2023-01-05 08:50: > > Hi, > > > > I'm having issues with DHCP relay on a Juniper MX BNG, and was > > wondering if > > anyone had an insight on what may be the cause of my issue. > > > > I've got subscribers terminating on the MX, authenticated by RADIUS, > > and > > then placed into a VRF to get services. In the vast majority of cases > > the > > IP addressing information is passed back by RADIUS, and so I'm using > > the > > local DHCP server on the MX to deal with that side of things. > > > > In one instance I require the use of an external DHCP server. I've got > > the > > RADIUS server providing an Access-Accept for this subscriber, and also > > returning the correct VRF in which to terminate the subscriber. I've > > also > > tried passing back the external DHCP server via RADIUS. > > > > In the VRF, I've got the DHCP relay configured, and there is > > reachability > > to the appropriate server > > > > The MX however seems reluctant to actually forward DHCP requests to > > this > > server. From the logging, I can see that the appropriate attributes are > > received and correctly decoded. The session gets relocated into the > > correct > > routing instance, but then it tries to look for a local DHCP server. > > > > I have the feeling that my issues are due to trying to use both the > > local > > DHCP server and DHCP relay depending on the subscriber scenario. If I > > change the global configuration of DHCP from local server to DHCP > > relay, my > > configuration works as expected though with the detriment of the > > scenario > > where the attributes returned via RADIUS no longer work due to it not > > being > > able to find a DHCP relay. > > > > Since the MX decides how to authenticate the subscriber based on where > > the > > demux interface is configured, I think ideally I would need to create a > > different demux interface for these type of subscribers that I can then > > set > > to be DHCP forwarded, thought I don't seem to be able to convince the > > router to do that yet. > > > > Has anyone come across this, and found a workable solution? > > > > Regards, > > Dave > > ___ > > 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
[j-nsp] MX BNG with both local server and dhcp relay
Hi, I'm having issues with DHCP relay on a Juniper MX BNG, and was wondering if anyone had an insight on what may be the cause of my issue. I've got subscribers terminating on the MX, authenticated by RADIUS, and then placed into a VRF to get services. In the vast majority of cases the IP addressing information is passed back by RADIUS, and so I'm using the local DHCP server on the MX to deal with that side of things. In one instance I require the use of an external DHCP server. I've got the RADIUS server providing an Access-Accept for this subscriber, and also returning the correct VRF in which to terminate the subscriber. I've also tried passing back the external DHCP server via RADIUS. In the VRF, I've got the DHCP relay configured, and there is reachability to the appropriate server The MX however seems reluctant to actually forward DHCP requests to this server. From the logging, I can see that the appropriate attributes are received and correctly decoded. The session gets relocated into the correct routing instance, but then it tries to look for a local DHCP server. I have the feeling that my issues are due to trying to use both the local DHCP server and DHCP relay depending on the subscriber scenario. If I change the global configuration of DHCP from local server to DHCP relay, my configuration works as expected though with the detriment of the scenario where the attributes returned via RADIUS no longer work due to it not being able to find a DHCP relay. Since the MX decides how to authenticate the subscriber based on where the demux interface is configured, I think ideally I would need to create a different demux interface for these type of subscribers that I can then set to be DHCP forwarded, thought I don't seem to be able to convince the router to do that yet. Has anyone come across this, and found a workable solution? Regards, Dave ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cisco to Juniper BNG
You can control shaping from RADIUS fairly easily.
Define a dynamic-profile which configures your subscriber as you need:
PPPOE-PROFILE {
predefined-variable-defaults {
cos-shaping-rate 1m;
cos-byte-adjust -4;
}
interfaces {
pp0 {
unit "$junos-interface-unit" {
actual-transit-statistics;
no-traps;
ppp-options {
chap;
}
pppoe-options {
underlying-interface "$junos-underlying-interface";
server;
}
keepalives interval 30;
family inet {
rpf-check;
unnumbered-address "$junos-loopback-interface";
}
family inet6 {
rpf-check;
address $junos-ipv6-address;
}
}
}
}
class-of-service {
traffic-control-profiles {
SUBSCRIBER-TCP {
scheduler-map SUB_MAP;
shaping-rate "$junos-cos-shaping-rate";
overhead-accounting frame-mode-bytes
"$junos-cos-byte-adjust";
}
}
interfaces {
pp0 {
unit "$junos-interface-unit" {
output-traffic-control-profile SUBSCRIBER-TCP;
}
}
}
}
}
You can then populate the various CoS parameters using VSA 26-108
CoS-Parameter-Type
https://www.juniper.net/documentation/us/en/software/junos/subscriber-mgmt-sessions/topics/topic-map/radius-std-attributes-vsas-support.html#id-juniper-networks-vsas-supported-by-the-aaa-service-framework
On Fri, 17 Sept 2021 at 17:14, Mike via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> Hello,
>
> I have decided to investigate reorganizing how I terminate customer
> broadband sessions and I have some questions about differences in Cisco
> vs Juniper radius profiles:
>
> Currently in radius, I have a number of attributes I push out upon
> authentication which can include things like Framed-IP-Address,
> Framed-IP-Netmask, Framed-Route and Filter-id. I know these are pretty
> standard and likely are supported out of the box on Cisco and likely
> juniper too. However, I also do rate limiting in radius since my BNGs
> are cisco, and these rely on the 'Cisco-Service-Info' attribute with
> values like "QU;3000;5625000;1125;D;3000;5625000;1125",
> which establishes a 30m/30m pipe. I like using radius for this but most
> of what I have seen says I need instead to establish profiles on the
> Junos box itself in advance and reference them by name. This seems
> really inconvenient. I have done some poking around and see there is
> some dynamic profile support, but I am just not connecting the dots how
> I would get a similar feature to allow me to set the shaping rates in
> radius for juniper. If it matters, my primary access method is PPPoE but
> in the future I will move to a DHCP / CGNAT arrangement but still want
> to have the filtering/shaping functionality.
>
> Thank you.
>
> Mike-
>
> ___
> 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] Ideas on failure detection for a peering exchange shared between two routers.
Advertise the routes to the rest of your network using next hop self. This way the next hop is the loopback address of your routers, rather than the peering LAN itself. Regards, Dave On Tue, 2 Mar 2021 at 21:08, Jonathan Call wrote: > I've run into a corner case with a peering exchange that has me a little > stumped for a solution that doesn't require redesigning the whole thing: > > Two MX80 routers participate in the same peering exchange. (A Primary and > Secondary) Each has an interface configured in the same IP network within > that IX. During a random bad event (maintenance error or fiber failure > within the IX) the primary router loses access to everything on the IX > network but it's link stays up. The secondary router is not impacted by the > event. When this happens BGP on the primary router detects the loss of > connectivity to its peers and updates all of its routes based on the BGP > table from the secondary router. But because the peering link on the > primary router is still UP/UP, the forwarding table says the next-hop is > available via the bad interface. Here is an example of a Google route being > learned on the IX: > > 34.84.0.0/14 *[BGP/170] 1d 02:06:40, MED 0, localpref 220, from > 172.xx.xx.49 > AS path: 15169 I, validation-state: unverified > > to 19x.xx.x.113 via xe-0/0/2.0 > > Any way to work around this scenario? > ___ > 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] MX204 port 1G
On Fri, 9 Oct 2020 at 16:28, David Miller wrote: > If you are using RFC 1918 private addresses, then you will want to > remove them from the Junos martian dropping. > > Like: > set routing-options martians 192.168.0.0/16 exact allow > > Info: > > https://www.juniper.net/documentation/en_US/junos/topics/topic-map/recognize-martian-addr-routing.html This is not required. RFC1918 are not martians. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] track-igp-metric in LDP
If you are running next hop self on your BGP routes at the edge, the best path will be via a loopback in an LSP. If you have two identical routes, one of the tie breakers is IGP preference. If that knob isn’t set the IGP cost will be 1 for everything, and you will progress down to less helpful tue breakers like router id. Regards, Dave On Sun, 2 Aug 2020 at 11:58, Chen Jiang wrote: > Hi! Michael > > Thanks for your clarification. > > Sure, it will let LDP use IGP metric, but is there any benefit? > > Cause per my understanding LDP only works for label distributing, not path > selection, and LDP always follows the IGP path, so what is the difference > or benefit to add additional configuration knob to let LDP use IGP metric? > > BR! > > Chen Jiang > > On Sun, Aug 2, 2020 at 6:32 PM Michael Hallgren wrote: > > > Hi James, > > > > From memory, Junos assigns metric 1 by default to "LDP routes", not IGP > > metric, unless you push this button. > > > > Cheers, > > mh > > -- > > *De :* Chen Jiang > > *Envoyé :* dimanche 2 août 2020 12:10 > > *À :* Juniper List > > *Objet :* [j-nsp] track-igp-metric in LDP > > > > Hi! Experts > > > > Sorry for disturbing, I am curious about track-igp-metric knob under LDP, > > is there any scenarios it will be useful? I think ldp is just a label > > distribution protocol, the forwarding path always follows the IGP > shortest > > path, is there any benefit for using track-igp-metric? > > > > Thanks for your help! > > > > -- > > BR! > > > > > > > >James Chen > > ___ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > > -- > BR! > > > >James Chen > ___ > 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] Any red flags on this MX240 configuration...
The documentation states its supported: https://www.juniper.net/documentation/en_US/release-independent/junos/topics/concept/enhanced-mx-scb-description-mx960.html It doesn't support "Enhanced IP/Enhanced Ethernet mode" though whatever that is... Dave On Wed, 26 Feb 2020 at 14:37, Benjamin Collet wrote: > On Wed, Feb 26, 2020 at 03:05:16PM +0100, Marcel Bößendörfer wrote: > > The MPC-3D-16XGE-SFPP even works with a 710-021523 / SCB-MX :-) > > On Wed, Feb 26, 2020 at 09:11:50AM -0500, Brendan Mannella wrote: > > We have MPC-3D-16XGE-SFPP and SCBE working in production. Haven’t noticed > > any issues. > > That's good to know. I wonder if there are any limitations whatsoever or > simply a mistake in the documentation and the Hardware Compatibility > Tool). > > -- > Benjamin Collet > ___ > 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] NFX150 VPLS
Looking at the feature explorer, it barely even supports MPLS.
My guess would be that most of the features listed are available in NFVs
that you can install onto the system. The OS running natively just appears
to be a way to orchestrate them.
Regards,
Dave
On Fri, 3 Jan 2020 at 02:55, Olivier FRUQUET
wrote:
> Hi Folks,
>
> Happy new year everyone!
> I'm trying to configure a VPLS routing-instance on a NFX150 with the latest
> update (19.3R2.9).
> When I try to commit, I get the following error message :
> root@cpe-hq# commit
> [edit routing-instances]
> 'vpls-cust-1'
> RT Instance: Route-distinguisher cannot be configured for
> non-forwarding instance: vpls-cust-1
> [edit interfaces ge-1/0/1 unit 0]
> 'family'
> interface needs to be in a VPLS routing instance to support family
> VPLS
> error: configuration check-out failed
>
>
> When I look the configuration I see that the instance type VPLS is not
> supported ?!
> root@cpe-cust-hq# show routing-instances
> vpls-cust-1 {
> ##
> ## Warning: statement ignored: unsupported platform (nfx150_s1)
> ##
> instance-type vpls;
>
>
> The NFX150 datasheet says that VPLS is supported on this platform.
> Am I missing something?
>
> Thank you
> Regards,
> Olivier
> ___
> 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] Managing MX480 fxp0
Hi Aaron. This is definitely not possible. You can’t jump from the data plane out of the fxp port. This is why things like jflow are only possible inband Regards Dave On Fri, 22 Nov 2019 at 17:01, Aaron Gould wrote: > Thanks again (Chris) for solving my vpls/irb/tagging combination problem > yesterday. we can bridge successfully now. > > > > Taking this one step further, we now are trying to route via fxp0 and > *through* it to the irb.100 interface and are unable to. > > > > Is it possible to route traffic *through* an fxp0 interface ? (MX204) > > > > I'm asking since it seems that someone mentioned that it is in fact > possible > with some sort of static routes. but I'm unsure what they meant exactly. > > > > If it's definitely not possible to transit an fxp0 interface, I just need > to > know that, and I will seek solutions using a revenue interface instead. > > > > Resurrecting an old thread(s).. > > https://www.mail-archive.com/juniper-nsp@puck.nether.net/msg09809.html > > https://puck.nether.net/pipermail/juniper-nsp/2010-August/017545.html > > > > subnet A-fxp0/mx204/irb.100subnet B > > > > <---is bi-dir comms possible?--> > > > > > > -Aaron > > ___ > 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] good study guide/material for jncis - SP/P
Yes: https://learningnetwork.cisco.com/community/certifications/cisco-continuing-education-program On Thu, 16 May 2019 at 17:10, Aaron Gould wrote: > Does Cisco have recertification through continuing education (attend a > class > and recert!) like Juniper does ? > > https://www.juniper.net/us/en/training/certification/recertification/ > > touché :) > > > -Aaron > > > > > -Original Message- > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf > Of > Hitesh Kumar > Sent: Thursday, May 16, 2019 1:04 AM > To: mcbob 58 > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] good study guide/material for jncis - SP/P > > I am not taking cisco side.but that is why cico is best. > > Look at devnet!! > > Br > Hitesh > > On Thu, 16 May 2019, 03:13 mcbob 58, wrote: > > > Aaron , Alexander > > > > > > Thanks for responding. I contacted Juniper to see if there are many > > differences with the 2013 version. > > I am now doubting whether I should buy the books. There are 3 books and > > they cost $ 400 each on the Juniper site. Shame there are no fast tracks > > anymore. I am now learning with genius and the old material > > > > Br mc bob > > > > > > Van: Aaron Gould > > Verzonden: woensdag, mei 15, 2019 5:04 PM > > Aan: 'mcbob 58'; juniper-nsp@puck.nether.net > > Onderwerp: RE: [j-nsp] good study guide/material for jncis - SP/P > > > > Btw, I just heard back from Juniper (certificat...@juniper.net) that the > > fast track study guides are no longer available. > > > > - Aaron > > > > > > ___ > > 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 > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Avoid transit LSPs
I'm not aware of any option that will do this. The three solutions that I can think of are: Link colouring like Adam suggests An explicit path that avoids the interfaces you are worried about Set the RSVP cost for the interfaces really high Dave On Thu, 24 Jan 2019 at 17:01, Luis Balbinot wrote: > It's a permanent thing. > > These boxes are PE routers that are not supposed to handle transit > traffic but during certain network events a few FRR bypass LSPs are > established through them because that's the only remaining path. > > Something easier like a "no-eligible-backup" toggle like the one we > have with OSPF LFA would be nice. > > Luis > > On Thu, Jan 24, 2019 at 2:53 PM wrote: > > > > > Luis Balbinot > > > Sent: Thursday, January 24, 2019 4:45 PM > > > > > > Hi. > > > > > > How could I prevent a device from getting transit RSVP LSPs being > > > established through it? I only want it to accept ingress LSPs destined > to > > that > > > box. > > > > > If this is a permanent thing, > > You could create a colouring scheme where all links connected to this > node > > have to be avoided by all LSPs with the exception of LSPs terminated on > this > > node (or originated by this node). > > > > If this is a maintenance thing, > > There's a command that can be enabled to drain all transit LSPs out the > box. > > But, all the LSPs would need to be configured with this capability in the > > first place. > > > > > > adam > > > ___ > 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] Finding drops
Are you sure your tester is capable of generating that volume of traffic? Dave On Mon, 21 Jan 2019 at 20:09, Jason Lixfeld wrote: > Hi all, > > I’m doing some RFC2544 tests through an MX204. The tester is connected to > et-0/0/2, and the test destination is somewhere out there via et-0/0/0. 64 > byte packets seem to be getting dropped, and I’m trying to find where on > the box those drops are being recorded. > > I’ve distilled the test down to generating 100 million 64 byte (UDP) > packets to the destination, but the counters on et-0/0/2 read as though > they’ve only received about 76.6% of those packets. > > If I change the test to send 100 million 100 byte packets, the counters on > et-0/0/2 account for all packets. > > I’ve tried looking at various output to find a counter that registers the > missing packets, but I’m not having any luck. > > Aside from 'show interface et-0/0/2 extensive’, I’ve looked here with no > luck: > > show interface queue et-0/0/2 > show pfe statistics traffic detail > show pfe statistics exceptions > show pfe statistics error > > Somewhere else I should be looking? > ___ > 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] inline-jflow monitoring
> > i want samples of a every 128 packets > Netflow/Jflow/IPFIX does not sample packets. It samples flows. A flow is (could be?) made up of many packets. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] inline-jflow monitoring
set forwarding-options sampling instance inline input rate 128 This sets a sampling rate of 128:1. Is that intentional? Dave On Wed, 2 Jan 2019 at 10:08, A. Camci wrote: > Hi Steinar, > > see the config: > > set services flow-monitoring version-ipfix template ipv4 ipv4-template > set services flow-monitoring version-ipfix template ipv6 ipv6-template > > > set forwarding-options sampling instance inline input rate 128 > set forwarding-options sampling instance inline family inet output > flow-server xx.xx.10.34 port 2055 > set forwarding-options sampling instance inline family inet output > flow-server xx.xx.10.34 version-ipfix template ipv4 > set forwarding-options sampling instance inline family inet output > inline-jflow source-address xx.xx.0.238 > > set forwarding-options sampling instance inline family inet6 output > flow-server xx.xx.10.34 port 2055 > set forwarding-options sampling instance inline family inet6 output > flow-server xx.xx.10.34 version-ipfix template ipv6 > set forwarding-options sampling instance inline family inet6 output > inline-jflow source-address xx.xx.0.238 > > set chassis fpc 0 sampling-instance inline > set forwarding-options sampling instance inline family inet output > flow-server xx.xx.10.34 version-ipfix template ipv4 > set forwarding-options sampling instance inline family inet6 output > flow-server xx.xx.10.34 version-ipfix template ipv6 > set protocols bgp group fulltable-2-genie neighbor xx.xx.10.34 > > set interfaces ae0 unit 0 family inet sampling input > set interfaces ae0 unit 0 family inet6 sampling input > set interfaces ae1 unit 0 family inet sampling input > set interfaces ae1 unit 0 family inet6 sampling input > set interfaces ae5 unit 0 family inet sampling input > set interfaces ae5 unit 0 family inet6 sampling input > > > is a reboot necessary after the configuration ? > > thanks > ap > > Op wo 2 jan. 2019 om 10:56 schreef : > > > > Does anyone have experience with GENIEATM ( 6.3.2 ) and Juniper MX480 > > MPCE > > > Type 2 3D ( 16.1R4-S3.6). > > > recently we use the inline-jflow monitoring. > > > > > > it works but we receive too little sampling. > > > expect a 10k of sampling per second instead of 100 samples > > > > We have quite a bit of experience with inline-jflow/IPFIX. It mostly > > works just fine. Show your JunOS config, please. > > > > Steinar Haug, Nethelp consulting, sth...@nethelp.no > > > ___ > 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] Junos Telemetry Interface (JTI)
Sounds like SevOne to me (https://www.sevone.com/) On Fri, 28 Sep 2018 at 14:08, Colton Conor wrote: > Are there any third party network monitoring systems capable of interacting > with Junos Telemetry Interface (JTI)? Many of the third party systems are > SNMP and ICMP based, but we are looking for more real-time metrics. We > could set the SNMP polling to intervals of less than a minute, but I assume > that doesn't work very well and why JTI was released? > > I am aware of OpenNTI, but that doesn't seems to be a commercially > supported platform and it is missing the elements of a true NMS from what I > can tell. > > This YouTube video mentions Juniper working with partners, they even > mention one, but I can't make out the name at time 11:48. Can anyone > translate? https://www.youtube.com/watch?v=BeprCbmuqLA > > Does anyone know why the entire ACX line does not have Junos Telemetry > Interface (JTI)? Is this a coming feature to the ACX platform? > > Besides SNMP, ICMP, and JTI, are there any other protocols that can be used > for networking monitoring and management in Juniper that I am unaware of? > ___ > 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] ISIS L1 and L2 adjacency
For an adjacency in L1 to come up, the area ID must match. This is not the case for L2. http://www.cisco.com/c/en/us/support/docs/ip/integrated-intermediate-system-to-intermediate-system-is-is/200293-IS-IS-Adjacency-and-Area-Types.html On 18 July 2017 at 13:02, Aaron Gould wrote: > https://www.juniper.net/assets/us/en/local/pdf/study- > guide/study-guide-jncip > .pdf > > > > page 279 of 708 - shows the topology > > > > page 295 and 296 of 708 - begins to speak of a problem with r5 not being > able to become adjacent with r6 and r7 because the NET's area ID portion is > different at Level 1 with r6 and r7. once changed to 0002 to match r6 and > r7 level 1, everything works. > > > > Question, why doesn't this then create an issue with r5 now not having a > matching NET area ID 0001 with r3 and r4 and thus creating the same issue > that we previously saw with r6 and r7, but now with r3 and r4 ? > > > > in other words, if the adjaceny problem from r5 to r6 and r7 was because of > a mismatched area ID, then why after changing r5's area ID to 0002 to match > r6 and r7, why didn't this break the adjacencies with r3 and r4 since now > r5 > deosn't match r3 and r4 area id of 0001 ? > > > > -Aaron Gould > > ___ > 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] confederation bgp - path selection
From: https://www.juniper.net/documentation/en_US/junos12.3/topics/reference/general/routing-ptotocols-address-representation.html "A confederation segment (sequence or set) has a path length of 0. " On 12 June 2017 at 13:53, Aaron Gould wrote: > I'm working through a Confederation Lab for JNCIP-SP study > > > > Why is r3 choosing that the prefix with the longer AS PATH is better ? > > > > I thought shortest AS Path was typically more attractive > > > > JNCIP book... > https://www.juniper.net/assets/us/en/local/pdf/study- > guide/study-guide-jncip > .pdf > > > > on page 444 of 708 ...the topology is just one page prior... > > > > 4th bullet... > > > > - Configure r1 and r2 to redistribute a 192.168.100/24 static route into > IBGP and ensure that all other routers forward through r1 when its IBGP > session is up. ( i haven't done any tweaks on attributes yet to make r1 > more attractive because i wanted to first understand why r2's path is > preferred from r3's perspective even though it has longer AS PATH ) > > > > i wonder if this has something to do with it - "Inactive reason: Not Best > in > its group - Router ID" > > > > [edit] > > r3@lab-mx104:r3# run show route receive-protocol bgp 10.0.6.1 > 192.168.100.0 > > > > inet.0: 38 destinations, 41 routes (38 active, 0 holddown, 0 hidden) > > Prefix Nexthop MED LclprefAS path > > 192.168.100.0/2410.0.6.1 100I > > > > [edit] > > r3@lab-mx104:r3# run show route receive-protocol bgp 10.0.2.6 > 192.168.100.0 > > > > inet.0: 38 destinations, 41 routes (38 active, 0 holddown, 0 hidden) > > Prefix Nexthop MED LclprefAS path > > * 192.168.100.0/2410.0.6.2 100(65001) > I > > > > [edit] > > r3@lab-mx104:r3# run show route protocol bgp 192.168.100.0 > > > > inet.0: 38 destinations, 41 routes (38 active, 0 holddown, 0 hidden) > > + = Active Route, - = Last Active, * = Both > > > > 192.168.100.0/24 *[BGP/170] 00:51:05, localpref 100, from 10.0.2.6 > > AS path: (65001) I, validation-state: unverified > > > to 10.0.4.2 via lt-0/1/0.32 > > [BGP/170] 00:50:56, localpref 100, from 10.0.6.1 > > AS path: I, validation-state: unverified > > > to 10.0.4.14 via lt-0/1/0.31 > > > > [edit] > > r3@lab-mx104:r3# run show route protocol bgp 192.168.100.0 detail > > > > inet.0: 38 destinations, 41 routes (38 active, 0 holddown, 0 hidden) > > 192.168.100.0/24 (2 entries, 1 announced) > > *BGPPreference: 170/-101 > > Next hop type: Indirect > > Address: 0x2bd4e80 > > Next-hop reference count: 6 > > Source: 10.0.2.6 > > Next hop type: Router, Next hop index: 874 > > Next hop: 10.0.4.2 via lt-0/1/0.32, selected > > Session Id: 0x158 > > Protocol next hop: 10.0.6.2 > > Indirect next hop: 0x2c68110 1048622 INH Session ID: 0x201 > > State: > > Local AS: 65000 Peer AS: 65001 > > Age: 51:08 Metric2: 1 > > Validation State: unverified > > Task: BGP_65001.10.0.2.6+50172 > > Announcement bits (3): 2-KRT 4-BGP_RT_Background 5-Resolve > tree 2 > > AS path: (65001) I > > Accepted > > Localpref: 100 > > Router ID: 10.0.3.4 > > BGPPreference: 170/-101 > > Next hop type: Indirect > > Address: 0x2bd4844 > > Next-hop reference count: 4 > > Source: 10.0.6.1 > > Next hop type: Router, Next hop index: 1099 > > Next hop: 10.0.4.14 via lt-0/1/0.31, selected > > Session Id: 0x152 > > Protocol next hop: 10.0.6.1 > > Indirect next hop: 0x2c68000 1048575 INH Session ID: 0x1fc > > State: > > Inactive reason: Not Best in its group - Router ID > > Local AS: 65000 Peer AS: 65000 > > Age: 50:59 Metric2: 1 > > Validation State: unverified > > Task: BGP_65000.10.0.6.1+179 > > AS path: I > > Accepted > > Localpref: 100 > > Router ID: 10.0.6.1 > > > > > > - Aaron Gould > > > > > > ___ > 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] need HELP black holing a /32 via BGP community.
Looks good. You may just want to add a /32 route so you have one to send.
set routing-options static route A.B.C.D/32 discard
Looks like you may be missing a 6 from a community too?
Regards,
Dave
On 15 September 2016 at 17:53, Matthew Crocker
wrote:
>
>
> Hello,
>
> I have a /32 that I need to add a community to so get my upstreams to
> blackhole the traffic.
>
> Can anyone send me any points on how to do that?
>
> I have:
>
> policy-statement pl-blackhole {
> term match-route {
> from {
> prefix-list blackhole-prefixes;
> }
> }
> then {
> community add blackhole;
> accept;
> }
> }
>
>
> prefix-list blackhole-prefixes {
> A.B.C.D/32;
> }
>
> community blackhole members [ 7922:666 1239:66 ];
>
>
>
> I’ve added pl-blockhole to my upstream BGP group export statement.
>
> Am I on the right track? What am I missing?
>
>
>
> --
> Matthew Crocker
> President – Crocker Communications
> matt...@corp.crocker.com
>
> ___
> 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] MPC-3D-16XGE-SFPP at 1G speed
Further to this, all documentation I've quickly looked through seems to indicate its 10G only. http://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/general/mpc-16x10ge.html lists the compatible optics. On 26 April 2016 at 20:30, Dave Bell wrote: > I have no idea if you can use 1G optics in this card, but if you can, you > likely want to configure the interface as ge-0/0/0, instead of xe. This is > how it works on the EX4200 with the SFP+ module. > > Regards, > Dave > > On 26 April 2016 at 20:23, Dave Peters - Terabit Systems < > d...@terabitsystems.com> wrote: > >> Hi all-- >> >> Stupid question, here. Can the MPC-3D-16XGE-SFPP run with 1G optics (e.g. >> EX-SFP-1GE-SX), and if so, is there a specific port setting I need to >> commit? I'm running an MX480 with 13.3R8.7, and Uncle Google hasn't been >> too useful, yet. >> >> I tried: >> >> set interfaces xe-0/0/0 auto-negotiate >> >> inserted the EX-SFP-1GE-SX connected to an outside 1G port, no lights, no >> joy. >> >> Any help is appreciated. >> >> Thanks much. >> >> --Dave Peters >> ___ >> 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] MPC-3D-16XGE-SFPP at 1G speed
I have no idea if you can use 1G optics in this card, but if you can, you likely want to configure the interface as ge-0/0/0, instead of xe. This is how it works on the EX4200 with the SFP+ module. Regards, Dave On 26 April 2016 at 20:23, Dave Peters - Terabit Systems < d...@terabitsystems.com> wrote: > Hi all-- > > Stupid question, here. Can the MPC-3D-16XGE-SFPP run with 1G optics (e.g. > EX-SFP-1GE-SX), and if so, is there a specific port setting I need to > commit? I'm running an MX480 with 13.3R8.7, and Uncle Google hasn't been > too useful, yet. > > I tried: > > set interfaces xe-0/0/0 auto-negotiate > > inserted the EX-SFP-1GE-SX connected to an outside 1G port, no lights, no > joy. > > Any help is appreciated. > > Thanks much. > > --Dave Peters > ___ > 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] Cisco vs Juniper confused
You use destination black holing. Sacrifice the connectivity to one customer to save the rest. On 16 April 2016 at 17:25, Satish Patel wrote: > We are seeing attack all over the world, how you will stop them using > source blackholing? These day most of people use opendns and chargen > style spoofing attack. > > On Sat, Apr 16, 2016 at 10:53 AM, Roland Dobbins > wrote: > > On 16 Apr 2016, at 19:22, Satish Patel wrote: > > > >> also in DDoS S/RTBH not handy. > > > > Incorrect. > > > > --- > > Roland Dobbins > > ___ > > 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] Cisco vs Juniper confused
In my opinion trying to scrub DDoS traffic yourself is a losing battle. Its likely that an attacker can easily fill the ingress points onto your network. If this is the case, then legitimate traffic will be dropped before it even hits you. The damage is already done. The only way around this is bigger links, which can be costly and your not even guaranteed to have links big enough to cope with an attack. You're better off looking at your upstreams to assist you with this. They likely have some form of traffic scrubbing solution that you can employ when under attack. Its likely a lot easier for you to administrate too. Regards, Dave On 14 April 2016 at 22:57, Payam Chychi wrote: > What gear do you currently have? What do your filtering rules look like? > You don't need to buy new gear if your filtering much of the bad traffic at > the edge using simple ACLs > > > > On Apr 14, 2016, 2:39 PM -0700, Dovid Bender, wrote: > > Why not use an external service to scrub your traffic? > > > > Regards, > > > > Dovid > > > > -Original Message- > > From: Satish Patel > Sender: "juniper-nsp"Date: Thu, 14 > Apr 2016 17:35:17 > > To: > Subject: [j-nsp] Cisco vs Juniper confused > > > > This is my first port here, We are small size of company and now we > > are getting harsh by DDoS stuff. We have 10G link in our network > > terminated on L3 Cisco switch and from there other switches. > > Everything was working great but recently we started seeing DDoS more > > and more. They are filling 10G link using NTP, IPFrag etc. attack. > > > > Now we are looking for big gear so we keep bad guys out and scrub > > traffic but confused between Juniper Vs Cisco war.. I am not able to > > decide what to buy and how it will help us. I have following in my > > mind, We thought about ASR firewall too but not sure because it can > > handle DDoS or not. > > > > Need your suggestion what i should buy and why? One more thing we are > > planning to run BGP so we can do null triggering etc. > > > > MX80 vs ASR100X - Does this enough to handle DDoS and filter traffic? > > > > MX240 vs ASR900X > > ___ > > 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 > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX960 with two SCBEs and redundancy
All ports will remain active, but the bandwidth that each PFE has available will drop by 50%. I believe on that card, there are 4 PFEs, each with around 78Gbps. If you don't need to use all ports, and you select the ones you use carefully, you will be able to lose an SCBE without dropping any performance. Regards, Dave On 26 February 2016 at 10:55, v wrote: > Hello, > > we would like to build a MX960 with two SCBEs and just two line cards (2x > MPC-3D-16XGE-SFPP-R-B) for the beginning. What happens if one of the SCBEs > fails in such a configuration? > > Will we still have full performance on all ports of our two line cards? > Will the performance drop by 50%? > Or will half of the ports on each line card become inactive? > > Regards > v > ___ > 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] leak routes between L3VPN VRF's
Hi Tim, The only additional config to import routes between VRFs on the same PE, as opposed to between VRFs on different PEs is the auto-export knob. No rib-groups required. Just configure the required RTs for import under the vrf-import config. If you want to have a bit more control about what you import, you can implement this as a routing policy. Regards, Dave On 20 February 2016 at 11:21, tim tiriche wrote: > Hello, > > I am looking for a clean and simple way to leak routes between VRF's on the > same PE and across different PE? > > For eg: On PE1 and PE2, if i have 3 VRF's. (VRF1, VRF2, VRF3). These are > mpls l3vpn vrf's. > > How can i leak routes between VRF1 and VRF2 on the same PE and across PE > > a) Can i do it only using RT (vrf-import)? or do i need to also implement > rib-groups? > b) can i do auto-export with policies on PE1 for exchanging routes only > between VRF1 and VRF2 > > I would like to avoid rib-groups if possible and looking for simplicity and > best practices around this. > > -Tim > ___ > 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] Optimizing the FIB on MX
I've not used the MX104, but the MX80 is incredibly slow to commit changes, and from discussion on this mailing list slow to converge also. As has been mentioned though, this can be got around by using things like BGP PIC, and LFA to maintain a valid forwarding path while the control plane sorts itself out though. What I would be interested to know though is do these technologies use additional FIB slots? IE by enabling BGP PIC, are you effectively cutting your FIB capacity in half, from 1 million routes to 0.5 million? Regards, Dave On 18 February 2016 at 13:31, Colton Conor wrote: > So is the MX-104 processor really that underpowered? I have heard reports > that is was too underpowered for its pricepoint, and now I am starting to > believe it. Vincent what are your thoughts? > > On Wed, Feb 17, 2016 at 5:14 PM, Vincent Bernat wrote: > >> ❦ 17 février 2016 22:56 GMT, Adam Vitkovsky > > : >> >> >> Being a bit unsatisfied with a pair of MX104 turning themselves as a >> blackhole >> >> during BGP convergence, I am trying to reduce the size of the FIB. >> >> >> > You mentioned earlier that this is a new installation so why not use >> > routing instance for Internet which allows you to use PIC with your >> > current version of code and save you all this trouble duck-taping the >> > solution together. >> >> You are right. I didn't understand your answer the first time as I >> thought that PIC was for "programmable integrated circuit", so I thought >> this was a plan for Juniper to fix the problem with some dedicated piece >> of hardware. >> -- >> Truth is the most valuable thing we have -- so let us economize it. >> -- Mark Twain >> ___ >> 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] Which BOGON filter strategy you would recommend IPv4 and IPv6
Hi, I would follow RFC 6890 when creating my bogon list. I would be a bit nervous about taking a BGP feed of bogons from a 3rd party in case they were compromised, and valid address space was introduced into, or invalid address space was removed from their feed. Regards, Dave On 16 February 2016 at 11:37, Saku Ytti wrote: > On 16 February 2016 at 09:49, Alexander Marhold > wrote: > > Hey, > >> What do you recommend, and which way to get the lists and how often is an >> update needed > > I recommend bogonising only statically bogons, which never change. No > unallocated bogonising (calling those bogons is false anyhow), it has > brought lot more harm than good. > > -- > ++ytti > ___ > 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] Juniper EX2200 virtual-chassis
Hi, Its been quite some time since I've used EX switches. From memory though, even if you don't explicitly have any VC configuration the switch will believe itself to be part of a VC with only one member - itself. Run some show virtual-chassis commands to confirm that this is the case. If it does believe it is, then you can likely add in the appropriate VC configuration that designates it as master, and insert your new switch into the chassis without interruption. This part is completely unhelpful for you but we configured all switches going into production as a VC even if they didn't have any other members for situations like this. Regards, Dave On 3 February 2016 at 13:34, Matthew Crocker wrote: > > Hello, > > I have an EX-2200 in production and would like to add another to create a > virtual-chassis. The current production unit will be the master and the > new unit will be the backup.Does creating a virtual-chassis cause a RE > reset? Will my production traffic take a hit? > > Thanks > > -Matt > > — > > Matthew Crocker > President - Crocker Communications, Inc. > Managing Partner - Crocker Telecommunications, LLC > E: matt...@corp.crocker.com > E: matt...@crocker.com > > > > ___ > 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] Could JUNOS OP Script support generate firewall filter term and added before original one?
You could always have your op script delete the default-all term, add
your new network term, then re-add the default-all term.
On 17 December 2015 at 14:27, Chen Jiang wrote:
> Hi! Jordan
>
> End user's MX has a firewall filter named metro-access has many terms in
> it, just like below:
>
> lab@mx#show firewall family inet filter metro-access
>
> term inside-test {
>
> from {
>
> source-address {
>
> 124.42.96.208/29;
>
> }
>
> }
>
> then {
>
> policer inside-test-2m;
>
> accept;
>
> }
>
> }
>
> term bj_kun_lun_fan_dian-15m {
>
> from {
>
> source-address {
>
> 119.253.129.64/28;
>
> }
>
> }
>
> then {
>
> policer bj_kun_lun_fan_dian-15m;
>
> accept;
>
> }
>
> }
>
> ...
>
> term default-all {
>
> then accept;
>
> }
>
> Every time end user want to add a new network he will create a term match
> new net's source address and add it before the last "default-all" term.
>
> Use JUNOS OP script we could simplify this procedure: auto generate the new
> term content and merge it into the configuration (this step is tested
> successfully in POC lab), but the new term is always arranged as the last
> term in the firewall filter, I haven't find any method to insert the new
> term before the original last "accept all" term and it will make traffic
> never hit the generated new term.
>
> Thanks for your help!
>
> On Thu, Dec 17, 2015 at 8:53 PM, Jordan Head
> wrote:
>
>> Hi James
>>
>> An op script could definitely do this, but I haven't seen a basic template
>> for this use case. Depending on *exactly* what you want it to do, it might
>> be a better job for Python, and maybe some netconf.
>>
>> Here's something that might help get you started.
>>
>>
>> http://www.juniper.net/documentation/en_US/junos12.3/topics/example/junos-script-automation-op-script-changing-configuration.html
>>
>> How complex are the rules that need to be generated? Could you provide
>> some examples? Feel free to ping me off list if necessary.
>>
>> -JH
>>
>> > On Dec 17, 2015, at 2:35 AM, Chen Jiang wrote:
>> >
>> > Hi! Experts
>> >
>> > I have a requirement from end user that want to automate firewall filter
>> > configuration procedure, that means they want to use OP script to
>> generate
>> > a customized firewall filter term and added it before the last "deny all"
>> > term.
>> >
>> > I have searched official documents but couldn't find helpful information,
>> > it seems there is no method could manage firewall filter term sequence in
>> > SLAX language.
>> >
>> > Could you pls shed some light on this if you have experience on this,
>> > Thanks!
>> >
>> > --
>> > BR!
>> >
>> >
>> >
>> > James Chen
>> > ___
>> > juniper-nsp mailing list juniper-nsp@puck.nether.net
>> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
>
>
> --
> BR!
>
>
>
>James Chen
> ___
> 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] Unwanted newline characters in Netconf XML
On 2 December 2015 at 07:04, Tore Anderson wrote:
> Works fine for me? Even in JUNOS versions as old as 11.4. Try:
>
> {master:1}[edit]
> tore@lab-ex4200# load merge terminal
> [Type ^D at a new line to end input]
> /* This is a
> * multi-line
> * comment.
> */
> protocols{}
> [edit]
> 'protocols'
> warning: statement has no contents; ignored
> load complete
>
Ah, I was using 'annotate ' which doesn't appear to allow it. This
method does.
Regards,
Dave
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unwanted newline characters in Netconf XML
It certainly looks like a bug to me. I've tested it in our lab on an MX running 12.3R8, and get the same problem as you. Interestingly this conflicts with their documentation: "The NETCONF server returns the information in XML-tagged format, which is identical to the output displayed in the CLI when you include the | display xml option after the operational mode command." http://www.juniper.net/documentation/en_US/junos13.2/topics/task/operational/netconf-operational-request-output-format.html Clearly this is not identical! Have you tried upgrading to a later version of JunOS? With actually no information about what you are actually trying to do, I don't see there being a massive issue with stripping out new lines. I can't think of anything other than comments that might allow a line break. In fact I've just been playing with trying to put a line break in a comment, and that doesn't even seem to work! Regards, Dave On 1 December 2015 at 13:21, Tore Anderson wrote: > I'm assuming this must be a JUNOS bug? > > $ echo '' | ssh -s lab-ex netconf > [...] > xmlns:junos="http://xml.juniper.net/junos/12.3R10/junos";> > xmlns="http://xml.juniper.net/junos/12.3R10/junos-interface"; > junos:style="normal"> > > > ge-0/0/0 > > [...] > > The newline characters immediately following and preceeding > becomes part of the node value - that is, the interface name > becomes "\nge-0/0/0\n" instead of "ge-0/0/0". (This does not happen > only with interface names, pretty much any value is wrapped in these > newline characters.) > > This in turn makes using XPath with expressions such as for example > «//physical-interface[name="ge-0/0/0"]» to fail miserably. > > A simple workaround is to strip all the newline characters from the XML > string before feeding it to the XML parser. But that of course will > also break nodes may actually contain newlines - comes > to mind, are there others? > > I'm far from being an expert on XML or Netconf for that matter, so I'm > wondering if anyone else on the list ran into this issue (surely yes?) > and if so if there's a better way to deal with it? > > Interestingly, running "show interfaces | display xml" from the JUNOS > shell looks much better: > > http://xml.juniper.net/junos/12.3R10/junos";> > xmlns="http://xml.juniper.net/junos/12.3R10/junos-interface"; > junos:style="normal"> > > ge-0/0/0 > [...] > > If I could only convince the Netconf service to give me its replay > formatted in this way instead everything would have worked well. > > Tore > ___ > 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] Mx Policy routing problem
Hi Cahit,
> root@mx80-core# show interfaces ae0
> aggregated-ether-options {
> minimum-links 1;
> lacp {
> active;
> periodic fast;
> }
> }
> unit 0 {
> family inet {
> filter {
> input FWDirect;
> }
> address 10.32.35.14/30;
> }
> }
> Request timeout for icmp_seq 14714
> 36 bytes from 10.32.35.14: Destination Net Unreachable
> Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
> 4 5 00 5400 938d 0 38 01 d3ad 192.168.2.102 185.9.159.86
This looks like you are sourcing your traffic from the address on
interface ae0? If this is the case, then it is not actually ingressing
ae0, therefore the firewall won't be hit.
Try testing from the thing connected to ae0 (if you can).
Regards,
Dave
On 23 November 2015 at 10:08, Cahit Eyigünlü wrote:
> Hello friends ;
>
> We have an MX80 router which has connection on ae0 to our isp
>
>
>
> root@mx80-core# show interfaces ae0
> aggregated-ether-options {
> minimum-links 1;
> lacp {
> active;
> periodic fast;
> }
> }
> unit 0 {
> family inet {
> filter {
> input FWDirect;
> }
> address 10.32.35.14/30;
> }
> }
>
>
> [edit]
> root@mx80-core# show firewall
> filter FWDirect {
> term UDPFW {
> from {
> destination-address {
> 185.9.159.86/32;
> }
> protocol udp;
> }
> then {
> log;
> routing-instance UDP-Routes;
> }
> }
> term TCPFW {
> from {
> destination-address {
> 185.9.159.86/32;
> }
> }
> then {
> count TCPFWTR;
> log;
> routing-instance TCP-Routes;
> }
> }
> term Default {
> then accept;
> }
> }
>
> [edit]
> root@mx80-core# show routing-instances
> Normal-Routes {
> instance-type virtual-router;
> }
> TCP-Routes {
> instance-type forwarding;
> routing-options {
> static {
> route 0.0.0.0/0 next-hop 37.123.100.122;
> }
> }
> }
> UDP-Routes {
> instance-type forwarding;
> routing-options {
> static {
> route 0.0.0.0/0 next-hop 37.123.100.98;
> }
> }
> }
>
> [edit]
> root@mx80-core# show protocols ospf
> rib-group SPD-Route;
> area 0.0.0.0 {
> interface all;
> interface ae0.0 {
> disable;
> }
> }
>
> [edit]
>
> root@mx80-core# show routing-options rib-groups
> SPD-Route {
> import-rib [ inet.0 UDP-Routes.inet.0 TCP-Routes.inet.0 ];
> }
>
> [edit]
> root@mx80-core#
>
>
>
> The router has connection to routing instance ip addresses and logging the
> connections :
>
>
> root@mx80-core# run ping 37.123.100.122
> PING 37.123.100.122 (37.123.100.122): 56 data bytes
> 64 bytes from 37.123.100.122: icmp_seq=0 ttl=64 time=1.194 ms
> 64 bytes from 37.123.100.122: icmp_seq=1 ttl=64 time=0.956 ms
> ^C
> --- 37.123.100.122 ping statistics ---
> 2 packets transmitted, 2 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 0.956/1.075/1.194/0.119 ms
>
> [edit]
> root@mx80-core# run ping 37.123.100.98
> PING 37.123.100.98 (37.123.100.98): 56 data bytes
> 64 bytes from 37.123.100.98: icmp_seq=0 ttl=64 time=0.490 ms
> 64 bytes from 37.123.100.98: icmp_seq=1 ttl=64 time=8.739 ms
> 64 bytes from 37.123.100.98: icmp_seq=2 ttl=64 time=0.422 ms
> ^C
> --- 37.123.100.98 ping statistics ---
> 3 packets transmitted, 3 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 0.422/3.217/8.739/3.905 ms
>
> [edit]
> root@mx80-core# run show firewall log
> Log :
> Time FilterAction Interface ProtocolSrc Addr
> Dest Addr
> 08:44:20 pfe A ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:19 pfe A ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:18 pfe A ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:17 pfe A ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:16 pfe A ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:15 pfe A ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:14 pfe A ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:13 pfe A ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:12 pfe A ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:11 pfe A ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:10 pfe A ae0.0 ICMP212.174.232.182
> 185.9.159.86
> 08:44:09 pfe A ae0.0 ICMP212.174.232.182
> 185.9.159.86
>
>
>
> but we can not access from outside
Re: [j-nsp] inet6 ttl filter / equivalent of hop-limit on non MX series
Hi Scott,
I would drop that accept-traceroute-tcp term. It will allow any TCP
traffic with a TTL of 1. If you can fudge your TTL (Simple on linux,
just write the value to /proc/sys/net/ipv4/ip_default_ttl) then you
can connect to any open TCP port. Additionally I don't think I've seen
a legitimate use case for TCP traceroute.
As for how to implement this in IPv6... I'm unsure. I suspect without
the hop-limit statement being available you are going to be stuffed.
You could just make do with ICMP traceroute, and don't bother with
checking the TTL field.
Regards,
Dave
On 22 November 2015 at 04:22, Scott wrote:
> Hi All,
>
> I am currently rewriting the inet6 firewall on a M120 and I am trying to
> figure out how I can effectively filter traceroutes, especially tcp, as
> hop-limit is supported on MX MIC/MPC only.
>
> Any pointers are highly appreciated
>
> The config is largely based on the Day One books, here is the inet version
> I am trying to convert
>
> filter accept-traceroute {
> apply-flags omit;
> term accept-traceroute-udp {
> from {
> destination-prefix-list {
> router-ips-ipv4;
> router-ips-logisys-ipv4;
> }
> protocol udp;
> ttl 1;
> destination-port 33434-33523;
> }
> then {
> policer management-1m;
> count accept-traceroute-udp;
> accept;
> }
> }
> term accept-traceroute-icmp {
> from {
> destination-prefix-list {
> router-ips-ipv4;
> router-ips-logisys-ipv4;
> }
> protocol icmp;
> ttl 1;
> icmp-type [ echo-request timestamp time-exceeded ];
> }
> then {
> policer management-1m;
> count accept-traceroute-icmp;
> accept;
> }
> }
> term accept-traceroute-tcp {
> from {
> destination-prefix-list {
> router-ips-ipv4;
> router-ips-logisys-ipv4;
> }
> protocol tcp;
> ttl 1;
> }
> then {
> policer management-1m;
> count accept-traceroute-tcp;
> accept;
> }
> }
> }
>
> Thanks,
>
> Scott
> ___
> 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] BGP routes in srx100
Hi Sebastian, The datasheet I'm reading (http://www.juniper.net/assets/fr/fr/local/pdf/datasheets/1000281-en.pdf page 9) says it supports 8k BGP routes. What datasheet are you reading? Regards, Dave On 20 November 2015 at 17:07, Sebastian Bermeo wrote: > Hi, I need to configure a bgp peer in juniper srx100, and I do not know how > many routes support this device. In the datashet this informationsay 4 K / > 8 K5 , but I do not understand. > > > Thanks for any answer. > > Regards. > ___ > 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] EX CVID untagged
Hi Andrew,
To be clear, you want untagged frames to be double tagged on ingress
on a specific port?
This is possible on the MX, I'm unsure if it is on the EX though. You
want to look at vlan rewrite.
interface ge-0/0/0 {
encapsulation flexible-ethernet-services;
flexible-vlan-tagging;
unit 0 {
input-vlan-map {
push-push;
inner-vlan-id 901;
vlan-id 101;
}
output-vlan-map {
pop-pop;
}
}
This may work for you. You may also need to set the tpid.
Regards,
Dave
On 17 November 2015 at 22:47, Andrew Thrift wrote:
> Hello,
>
> We have EX switches and are successfully carrying QinQ frames across
> the switches.
>
> Recently we have had the requirement to operate a number of CVID's as
> untagged interfaces on the EX switches, but so far have not found a
> clear answer on if this is possible, or how to do it.
>
> e.g. SVID of 101, CVID of 901. SVID/CVID 101/901 is untagged on port
> ge-0/0/1
>
> Is this possible ? and how might we go about achieving it ?
>
>
>
> Thanks,
>
>
>
>
> Andrew
> ___
> 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] Redistribute Connected in Junos
Hi James,
Your export policy isn't adding on your community.
Try:
term 10 {
from {
protocol direct;
interface [ ge-0/1/0.89 fe-1/1/3.89 ];
}
community add 0089_VRF;
then accept;
}
You also need to make sure your import policy is importing that.
In fairness, you probably don't need an import/export policy here, as
your policy is very simple. You could just remove vrf-import/export,
and set vrf-target target:12345:89
Regards,
Dave
On 17 November 2015 at 15:42, James Bensley wrote:
> Hi All,
>
> I'm much more of a Cisco head; trying to redistribute the connected
> subnets into an MPLS L3VPN form PE2, up to some RRs then down to PE1,
> not sure what I've missed here, can anyone help me out?
>
> bensley@PE2> show route table 0089.inet.0
> 172.31.253.100/31 *[Direct/0] 3w4d 12:42:16
> > via fe-1/1/3.89
> 172.31.253.100/32 *[Local/0] 3w4d 12:42:16
> Local via fe-1/1/3.89
> 172.31.253.102/31 *[Direct/0] 3w4d 12:42:16
> > via ge-0/1/0.89
> 172.31.253.102/32 *[Local/0] 3w4d 12:42:16
> Local via ge-0/1/0.89
> PE2.Lo0.IP.80/32*[Direct/0] 3w4d 12:42:16
> > via lo0.89
>
> bensley@PE2> show configuration policy-options community 0089_VRF
> members target:12345:89;
>
> bensley@PE2> show configuration routing-instances 0089
> instance-type vrf;
> interface lo0.89;
> interface ge-0/1/0.89;
> interface fe-1/1/3.89;
> route-distinguisher PE2.Lo0.IP.80:89;
> vrf-import plc-VRF-0089-Import;
> vrf-export plc-VRF-0089-Export;
> vrf-table-label;
>
>
> bensley@PE2> show configuration policy-options policy-statement
> plc-VRF-0089-Export
> term 10 {
> from {
> protocol direct;
> interface [ ge-0/1/0.89 fe-1/1/3.89 ];
> }
> then accept;
> }
>
> bensley@PE2> show route advertising-protocol bgp RR1.Lo0.IP.165 table
> bgp.l3vpn.0 | match 89
> PE2.Lo0.IP.80:89:172.31.253.100/31
> PE2.Lo0.IP.80:89:172.31.253.102/31
>
>
> So that all looks good to my layman eyes, however over on PE1 we don't
> receive the routes:
>
> bensley@PE1> show route receive-protocol bgp RR1.Lo0.IP.165 table
> bgp.l3vpn.0 | match 89
> PE9.Lo0.IP.9:1067:10.1.89.0/24
> PE9.Lo0.IP.9:1067:10.2.89.0/24
> RR1.Lo0.IP.165:511:10.89.55.0/28
>
>
>
> The RR also doesn't show the routes in "show route receive-protocol
> bgp..." (it doesn't have the routing instance configured either but I
> don't believe that should make a difference in Junos? I think I should
> at least see the routes in the BGP RIB?). PE1 is sending some eBGP
> learnt routes inside this VRF to PE2 via the RR, and PE2 is
> successfully receiving them so I'm just trying to get some directly
> connected return routes back from PE2 via RR to PE1.
>
> Many thanks,
> James.
>
>
> bensley@RR1> show configuration protocols bgp group Core-MX480
> type internal;
> local-address RR1.Lo0.IP.165;
> family inet {
> unicast;
> }
> family inet-vpn {
> unicast;
> }
> family inet6 {
> unicast;
> }
> family l2vpn {
> signaling;
> }
> export [ export-ibgp-ipv4-default-route export-ibgp-ipv4-client-routes
> export-ibgp-ipv4-no-transit ];
> cluster RR1.Lo0.IP.165;
> neighbor PE1.Lo0.IP.85 {
> description "PE1";
> }
> bensley@RR1> show configuration protocols bgp group Core-Others
> type internal;
> local-address RR1.Lo0.IP.165;
> family inet {
> unicast;
> }
> family inet-vpn {
> unicast;
> }
> family inet6 {
> unicast;
> }
> family l2vpn {
> signaling;
> }
> export [ export-ibgp-ipv4-default-route export-ibgp-ipv4-client-routes
> export-ibgp-ipv4-no-transit ];
> cluster RR1.Lo0.IP.165;
> local-as 12345;
> neighbor PE2.Lo0.IP.80 {
> description " PE2";
> }
>
> # There are no import statements, iBGP should advertise all routes
> then, so only the export statements could potentially filter the
> routes but thye *seem* to be allowed
>
> bensley@RR1> show configuration policy-options policy-statement
> export-ibgp-ipv4-client-routes
> term downstream-transit {
> from {
> protocol bgp;
> community [ downstream-transit lpsn-ipv4-route ];
> }
> then accept;
> }
> term vpn-routes {
> from {
> protocol bgp;
> rib bgp.l3vpn.0;
> }
> then accept;
> }
> term l2vpn-routes {
> from {
> protocol bgp;
> rib bgp.l2vpn.0;
> }
> then accept;
> }
>
>
> bensley@PE1> show configuration protocols bgp group core-mx480-rr
> type internal;
> local-address PE1.85;
> family inet {
> unicast;
> }
> family inet-vpn {
> unicast;
> }
> family inet6 {
> unicast;
> }
> family l2vpn {
> signaling;
> }
> export [ export-bgp-default export-bgp-ipv4-transit
> export-bgp-ipv4-downstream-routes export-bgp-vrf-all
> export-bgp-ipv4-deny-all export-bgp-ipv6-deny-all ];
> neighbor RR1.Lo0.IP.165 {
> description "RR1";
> }
> neighbor RR2.Lo0.IP.166 {
> description "RR2";
> }
> ___
> juniper-nsp maili
Re: [j-nsp] Asymmetric Routing
Alternatively drop the iBGP session between the two MX80s. Depending on the topology, it may not be needed. Regards, Dave On 13 October 2015 at 14:38, Mark Tinka wrote: > > > On 13/Oct/15 15:18, Dave Bell wrote: > >> >> Packet is sent to the EX. It does a route lookup, and has its default >> route set at MX80 A. Packet is forwarded to MX80 A. >> Packet is received by MX80 A. It does a route lookup, and the best >> route is via MX80 B. Packet is forwarded to EX. >> EX receives packet. It does a route lookup. Default route is via... > > This is exactly what I am thinking the issue is. > > No way the EX4550 can handle a full table (two, moreover) coming from > the MX80's. > > I'd say dump the EX4500 into Layer 2-only mode, run VRRP between the > MX80's, and Bob's the other thing... > > Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Asymmetric Routing
Hi Chad, How is this iBGP session formed? Is it over L3 links via the EX, or do they have a direct physical link? If it is via the EX, then the issue may be with it not having a full routing table, like your MX80s. Packet is sent to the EX. It does a route lookup, and has its default route set at MX80 A. Packet is forwarded to MX80 A. Packet is received by MX80 A. It does a route lookup, and the best route is via MX80 B. Packet is forwarded to EX. EX receives packet. It does a route lookup. Default route is via... Do a route lookup for the destination on each of the MX's, see where it thinks it should be forwarding the packet. Regard, Dave On 13 October 2015 at 14:04, Chad Levy wrote: > Hi Mark, > > The default gateway of the machine is the EX4500. > > I have since tried another scenario. If I place both ISPs on the same MX80, > and the same asymmetric route exists on the ingress and egress, there is no > longer an issue with connectivity. I only have an issue when the ingress and > egress paths traverse different MX80 devices. > > Thank you, > Chad > >> Subject: Re: [j-nsp] Asymmetric Routing >> To: clevy...@outlook.com; juniper-nsp@puck.nether.net >> From: mark.ti...@seacom.mu >> Date: Tue, 13 Oct 2015 08:07:36 +0200 >> >> >> >> On 13/Oct/15 04:56, Chad Levy wrote: >> >> > Hi all, >> > >> > I am having an issue with a new set of Juniper MX80 routers and an EX4500 >> > switch. My topology is extremely simple, each MX80 has its own internet >> > provider running full BGP routes, and iBGP between the two. The EX4500 is >> > connected to both MX80 devices with /30 P2P running OSPF with route >> > redistribution. The MX80s are originating a default route to the EX4500 >> > via OSPF. >> > >> > I have a single /24 announced to both of my internet providers with a >> > machine connected to the EX4500 via a /30. >> > >> > Both MX80 devices can ping the machine, and vice-versa. My issue becomes >> > when I have an inbound route traverse "ISP A" on one MX, but the return >> > path tries to egress "ISP B" on the other MX. Traffic is dropped and never >> > reaches its final destination. The same behavior happens when the ingress >> > is on "ISP B" and egress on "ISP A". >> > >> > If the ingress and egress paths are symmetrical, connectivity is fine. >> > Additionally, if I override the OSPF learned route for the machines /30 on >> > the ingress MX80, and point a static route to the egress path MX80 for the >> > /30, traffic flows perfectly fine. >> > >> > I do not have any elaborate firewall filters or anything such as RPF >> > enabled, etc on any of the devices at this time. My carriers are also not >> > filtering any traffic on their side. >> > >> > Are there any default configurations in place on either the MX80 or EX4500 >> > that could cause this behavior? One MX80 is running JunOS 13.3, the second >> > MX and the EX4500 are both running JunOS 12.3. The behavior is similar to >> > using a pair of SRX devices in flow mode with traffic ingress on one >> > device, and egress on another. >> >> What is the PC's default gateway? The MX80's or the EX4500? >> >> Mark. > > ___ > 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] Static route with tracking
Hi Fabien, It depends on the platform you are using. If you are using the SRX you can use IP monitoring https://www.juniper.net/techpubs/en_US/junos12.1x44/topics/example/ip-monitoring-security-configuring.html I'm not aware of any other method outside of EventScript. Regards, Dave On 12 October 2015 at 08:28, Fabien Leboedec wrote: > Hi everybody, > > I need your help to know if it's possible to set an static route with > tracking (like dvsr on Redback or IP SLA + tracking on Cisco) on MX480 (Junos > V13.3R7.4)? > > I want to install in the forwarding table and propagate one static route in > iBGP only if the IP of Gateway if reachable. > > It's possible to do this in very simple manner without Eventscript? > > Thanks you to your answers > Regards, > > > > Fabien Le Boëdec > > ___ > 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] Where to find install media for EOL hardware platforms and Junos releases?
Not the best solution, but have you thought about taking your live routers down for maintenance, and dd'ing the contents of the CF onto another card? Regards, Dave On 23 September 2015 at 13:10, Martin T wrote: > Or maybe someone has install-media-8.5R4.3-domestic image on some old > tape-drive and is willing to share it? :) > > > thanks, > Martin > > On 9/21/15, Martin T wrote: >> Hi, >> >> I have one RE-600-2048(256MB CF and 40GB HDD) and one RE-333-768(256MB >> CF and 40GB HDD) routing engine. Both are with blank CF and HDD. I >> would like to install Junos 8.5R4.3 on those routing engines and use >> those as spares for some old routers with the same routing-engines and >> software, but I cant find the install media for such legacy software >> release. Oldest one available from Juniper web site for M series seems >> to be 12.3R1.7(install-media-12.3R1.7-domestic), but I need >> install-media-8.5R4.3-domestic. Is there a way to download EOL Junos >> releases from Juniper web-site? Or is there a way to build >> install-image from jinstall >> tarball(jinstall-8.5R4.3-domestic-signed.tgz)? >> >> >> thanks, >> Martin >> > ___ > 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] Setting CoS bits on ingress frames
Glad to hear you have got it working.
You can make your config a little more concise too if you wanted.
Under the interfaces section under class-of-service, you can use the *
operator to match multiple interfaces.
This will apply to all interfaces on the box, and in effect become the default.
You can then pick out specific interfaces that require a different
configuration.
EG:
class-of-service {
interfaces {
* {
unit 0 {
classifiers {
ieee-802.1 pasolink;
}
rewrite-rules {
ieee-802.1 default;
}
}
}
ge-0/0/0 {
unit 0 {
forwarding-class assured-forwarding;
}
}
}
}
This will have the same net effect of the snippet you replied with
earlier. All ports will get the trunk config, unless you state
otherwise.
You can also specify part of the interface name, and use * to match
the rest. ie you could have the following:
class-of-service {
interfaces {
xe-* {
unit 0 {
forwarding-class assured-forwarding;
}
}
}
}
This will match all 10G interfaces on the box and apply that config to it.
I believe you can also use the * operator on the unit number also for
added flexibility.
This may or may not be useful to you, but its there.
Regards,
Dave
On 4 August 2015 at 15:10, Victor Sudakov wrote:
> Thank you Dave and Chuck and all who have replied.
>
> I now have a working configuration which does what I wanted (using
> default forwarding classes and default rewrite rules to make it
> concise).
>
> class-of-service {
> classifiers {
> ieee-802.1 pasolink {
> forwarding-class best-effort {
> loss-priority low code-points [ 000 001 ];
> }
> forwarding-class expedited-forwarding {
> loss-priority low code-points [ 010 011 ];
> }
> forwarding-class assured-forwarding {
> loss-priority low code-points [ 100 101 ];
> }
> forwarding-class network-control {
> loss-priority low code-points [ 110 111 ];
> }
> }
> }
> interfaces {
> /* access port */
> ge-0/0/0 {
> unit 0 {
> forwarding-class assured-forwarding;
> }
> }
> /* trunk port */
> ge-0/0/22 {
> unit 0 {
> classifiers {
> ieee-802.1 pasolink;
> }
> rewrite-rules {
> ieee-802.1 default;
> }
> }
> }
> /* trunk port */
> ge-0/0/23 {
> unit 0 {
> classifiers {
> ieee-802.1 pasolink;
> }
> rewrite-rules {
> ieee-802.1 default;
> }
> }
> }
> }
> }
>
> --
> Victor Sudakov, VAS4-RIPE, VAS47-RIPN
> sip:suda...@sibptus.tomsk.ru
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Setting CoS bits on ingress frames
On 30 July 2015 at 14:49, Victor Sudakov wrote: > Dave Bell wrote: >> >> When frames enter the switch, the switch will need to classify them >> >> and place them into a queue. By default everything goes into queue 0, >> >> regardless of what other switches have done. >> > >> > I am afraid you are mistaken. If a frame enters a switch via a trunk >> > port and the frame already has a non-zero COS value, this COS value is >> > forwarded *intact* out the egress interface. >> > >> > I have experimental proof of this. In my lab, Sw1 (Cisco) classifies >> > frames and their COS value set by Sw1 is visible at HostC. >> >> When a frame enters port it is classified and placed into a forwarding >> class. There are defaults for some traffic types, but for .1p on the >> EX, everything goes into the forwarding class that is associated with >> queue 0. > > Are you speaking now about access or trunk ports? If tagged frames enter a > trunk port and already have non-zero COS values, will they all go into > queue 0 ? > > Personally I have no problem with them all going into one queue provided > they leave the switch with the COS fiels unmolested. I'm talking about all ports. The type is not relevant (from a JunOS perspective). >> On egress, if there is a rewrite rule on the forwarding class on the >> egress interface, then all traffic gets set regardless if there is >> already markings on the packet. > > And this is not desirable for me. I want frames entering trunk ports > to leave unmolested while frames entering access ports to have their > COS set. > >> >> If there is no rewrite rule on the forwarding class, then the marking >> remains unmolested. > > Well then, how do I handle the situation when I need to have some frames > rewritten on egress and some not? > >> >> The solution to this is to make sure that all your traffic enters the >> correct forwarding class on ingress. This means when it egresses the >> switch, it will have the intended markings. > > This sounds good. Have you looked at the chart at > ftp://ftp.sibptus.ru/pub/vas/chart2.pdf > This means that I need some frames to be rewritten and some not, > right? > >> >> Have you tried the configuration I have suggested? > > No, I have not yet tried to apply a classifier to the ingress trunk. I > don't like the idea of reclassifying transit frames on ingress. I'd > prefer some kind of passthru mode the way Cisco works. You just > configure "mls qos trust cos" on trunk ports and you are done. The problem you seem to be having is Juniper and Cisco do not work the same. On Juniper, forwarding classes are king. They define what happens to your traffic, including what marking it leaves the switch with. If you want to use rewrite to mark some of the packets entering the switch and exiting one of your ports then you need to classify appropriately on ingress on all ports. You place each frame in the appropriate FC, the markings then get written on egress. This may be with the same marking that it entered with. Example. Frame enters a trunk port with .1P marking of 3. Classifier examines this, and places it in a forwarding class associated with queue 3 (in your example ca). Frame gets switched to egress port where it runs through the rewrite rule. The rewrite rule for ca states set .1P bit to 3. Frame leaves egress port with a marking of 3. Another example. Frame enters an access port. Classifier sends all frames on this port to a forwarding class associated with queue 6 (in your example ic) Frame gets switched to the egress port where it runs to the rewrite rule. The rewrite rule states set .1P bit to 6. Frame leaves egress port with a marking of 6. What you currently (seem to) have happening. Frame enters a trunk port with .1P marking of 3. Default classifier ignores ,1P markings and places frame into a forwarding class associated with queue 0 (in your example bk). Frame gets switched to egress port where it runs through the rewrite rule. The rewrite rule for bk states set .1P bit to 0. Frame leaves egress port with a marking of 0. >> Have you looked at >> port counters for your interfaces to see what is happening to the >> traffic? > > I am mostly looking at tcpdump and WireShark on HostC. What command do > you suggest to look at the counters? show interface detail will show you how many packets are entering each queue. Dave ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Setting CoS bits on ingress frames
On 30 July 2015 at 13:07, Victor Sudakov wrote: > Dave Bell wrote: >> When frames enter the switch, the switch will need to classify them >> and place them into a queue. By default everything goes into queue 0, >> regardless of what other switches have done. > > I am afraid you are mistaken. If a frame enters a switch via a trunk > port and the frame already has a non-zero COS value, this COS value is > forwarded *intact* out the egress interface. > > I have experimental proof of this. In my lab, Sw1 (Cisco) classifies > frames and their COS value set by Sw1 is visible at HostC. When a frame enters port it is classified and placed into a forwarding class. There are defaults for some traffic types, but for .1p on the EX, everything goes into the forwarding class that is associated with queue 0. On egress, if there is a rewrite rule on the forwarding class on the egress interface, then all traffic gets set regardless if there is already markings on the packet. If there is no rewrite rule on the forwarding class, then the marking remains unmolested. The solution to this is to make sure that all your traffic enters the correct forwarding class on ingress. This means when it egresses the switch, it will have the intended markings. Have you tried the configuration I have suggested? Have you looked at port counters for your interfaces to see what is happening to the traffic? Dave ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Setting CoS bits on ingress frames
When frames enter the switch, the switch will need to classify them and place them into a queue. By default everything goes into queue 0, regardless of what other switches have done. You have a rewrite rule on your port facing host C that sets the .p bits on queue 0 to 0. To fix this, you need to have a classifier on ingress that moves the frames into the correct queue. This means when it egresses the switch, it goes through the correct part of the rewrite rule and keeps its markings. Dave On 30 July 2015 at 10:54, Victor Sudakov wrote: > Dave Bell wrote: >> Apply it to the port on SW3 that is facing SW2. > > Why would I apply a classifier on a trunk port? I need to classify > frames entering the network via _access_ ports, and keep this > classification intact on trunk ports. > > I'm afraid you are not following me. > > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > sip:suda...@sibptus.tomsk.ru ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Setting CoS bits on ingress frames
Apply it to the port on SW3 that is facing SW2.
On 30 July 2015 at 10:02, Dave Bell wrote:
> Hi Victor,
>
> I see two potential problems here.
>
> 1) SW2 is doing something weird and bleaching the frames before they
> reach SW3. You can apply a firewall filter to the ingress interface to
> match your .p bit value and count to check this.
>
> 2) As you don't have a classifier on your ingress interface, all
> traffic is getting placed in queue 0 by default, and your rewrite
> rules are now setting queue 0 to 0.
>
> To fix this one, you need a classifier on ingress. Try something like
> the following:
>
> class-of-service {
> classifiers {
> ieee-802.1 my-classifier {
> forwarding-class bk {
> loss-priority low code-points 000;
> }
> forwarding-class be {
> loss-priority low code-points 001;
> }
> forwarding-class ee {
> loss-priority low code-points 010;
> }
> forwarding-class ca {
> loss-priority low code-points 011;
> }
> forwarding-class vi {
> loss-priority low code-points 100;
> }
> forwarding-class vo {
> loss-priority low code-points 101;
> }
> forwarding-class ic {
> loss-priority low code-points 110;
> }
> forwarding-class nc {
> loss-priority low code-points 111;
> }
> }
> }
> interfaces {
> {
> classifiers {
> ieee-802.1 my-classifier;
> }
> }
> }
> }
>
> Regards,
> Dave
>
> On 30 July 2015 at 05:39, Victor Sudakov wrote:
>> Alexander Arseniev wrote:
>>> > The FC in JUNOS is the same as "qos-group" in CSCO IOS - invisible
>>> > internal-only field which travels along with packet content across the
>>> > switch, but is never inserted in the actual packet. The FC has
>>> > significance for choosing output scheduling, RED drop, marking.
>>
>>
>> I have come across a problem with the fixed port classifier.
>>
>> I would be grateful if someone could help me out. My lab setup is at
>> ftp://ftp.sibptus.ru/pub/vas/lab2.pdf
>>
>> Normally I see frames from HostA arriving at HostC with COS=3. I also
>> want frames from HostB to arrive at HostC with COS=6.
>>
>> However, when I enable the rewrite-rules section at Sw3, frames from
>> HostA no more have COS=3 (i.e. the COS field is cleared).
>>
>> I am ready to provide any additional detail. Below is my QoS
>> configuration.
>>
>>
>> admin@sw-kedr> show configuration class-of-service | no-more
>> forwarding-classes {
>> queue 0 bk;
>> queue 1 be;
>> queue 2 ee;
>> queue 3 ca;
>> queue 4 vi;
>> queue 5 vo;
>> queue 6 ic;
>> queue 7 nc;
>> }
>> interfaces {
>> ge-0/0/0 {
>> unit 0 {
>> forwarding-class ic;
>> }
>> }
>> inactive: ge-0/0/22 {
>> unit 0 {
>> rewrite-rules {
>> ieee-802.1 output;
>> }
>> }
>> }
>> ge-0/0/23 {
>> unit 0 {
>> rewrite-rules {
>> ieee-802.1 output;
>> }
>> }
>> }
>> }
>> rewrite-rules {
>> ieee-802.1 output {
>> forwarding-class bk {
>> loss-priority high code-point 000;
>> loss-priority low code-point 000;
>> }
>> forwarding-class be {
>> loss-priority high code-point 001;
>> loss-priority low code-point 001;
>> }
>> forwarding-class ee {
>> loss-priority high code-point 010;
>> loss-priority low code-point 010;
>> }
>> forwarding-class ca {
>> loss-priority high code-point 011;
>> loss-priority low code-point 011;
>> }
>> forwarding-class vi {
>> loss-priority high code-point 100;
>> loss-priority low code-point 100;
>> }
>> forwarding-class vo {
>> loss-priority high code-point 101;
>> loss-priority low code-point 101;
>> }
>> forwarding-class ic {
>> loss-priority high code-point 110;
>> loss-priority low code-point 110;
>> }
>> forwarding-class nc {
>> loss-priority high code-point 111;
>> loss-priority low code-point 111;
>> }
>> }
>> }
>>
>> {master:0}
>> admin@sw-kedr>
>>
>> --
>> Victor Sudakov, VAS4-RIPE, VAS47-RIPN
>> sip:suda...@sibptus.tomsk.ru
>> ___
>> 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] Setting CoS bits on ingress frames
Hi Victor,
I see two potential problems here.
1) SW2 is doing something weird and bleaching the frames before they
reach SW3. You can apply a firewall filter to the ingress interface to
match your .p bit value and count to check this.
2) As you don't have a classifier on your ingress interface, all
traffic is getting placed in queue 0 by default, and your rewrite
rules are now setting queue 0 to 0.
To fix this one, you need a classifier on ingress. Try something like
the following:
class-of-service {
classifiers {
ieee-802.1 my-classifier {
forwarding-class bk {
loss-priority low code-points 000;
}
forwarding-class be {
loss-priority low code-points 001;
}
forwarding-class ee {
loss-priority low code-points 010;
}
forwarding-class ca {
loss-priority low code-points 011;
}
forwarding-class vi {
loss-priority low code-points 100;
}
forwarding-class vo {
loss-priority low code-points 101;
}
forwarding-class ic {
loss-priority low code-points 110;
}
forwarding-class nc {
loss-priority low code-points 111;
}
}
}
interfaces {
{
classifiers {
ieee-802.1 my-classifier;
}
}
}
}
Regards,
Dave
On 30 July 2015 at 05:39, Victor Sudakov wrote:
> Alexander Arseniev wrote:
>> > The FC in JUNOS is the same as "qos-group" in CSCO IOS - invisible
>> > internal-only field which travels along with packet content across the
>> > switch, but is never inserted in the actual packet. The FC has
>> > significance for choosing output scheduling, RED drop, marking.
>
>
> I have come across a problem with the fixed port classifier.
>
> I would be grateful if someone could help me out. My lab setup is at
> ftp://ftp.sibptus.ru/pub/vas/lab2.pdf
>
> Normally I see frames from HostA arriving at HostC with COS=3. I also
> want frames from HostB to arrive at HostC with COS=6.
>
> However, when I enable the rewrite-rules section at Sw3, frames from
> HostA no more have COS=3 (i.e. the COS field is cleared).
>
> I am ready to provide any additional detail. Below is my QoS
> configuration.
>
>
> admin@sw-kedr> show configuration class-of-service | no-more
> forwarding-classes {
> queue 0 bk;
> queue 1 be;
> queue 2 ee;
> queue 3 ca;
> queue 4 vi;
> queue 5 vo;
> queue 6 ic;
> queue 7 nc;
> }
> interfaces {
> ge-0/0/0 {
> unit 0 {
> forwarding-class ic;
> }
> }
> inactive: ge-0/0/22 {
> unit 0 {
> rewrite-rules {
> ieee-802.1 output;
> }
> }
> }
> ge-0/0/23 {
> unit 0 {
> rewrite-rules {
> ieee-802.1 output;
> }
> }
> }
> }
> rewrite-rules {
> ieee-802.1 output {
> forwarding-class bk {
> loss-priority high code-point 000;
> loss-priority low code-point 000;
> }
> forwarding-class be {
> loss-priority high code-point 001;
> loss-priority low code-point 001;
> }
> forwarding-class ee {
> loss-priority high code-point 010;
> loss-priority low code-point 010;
> }
> forwarding-class ca {
> loss-priority high code-point 011;
> loss-priority low code-point 011;
> }
> forwarding-class vi {
> loss-priority high code-point 100;
> loss-priority low code-point 100;
> }
> forwarding-class vo {
> loss-priority high code-point 101;
> loss-priority low code-point 101;
> }
> forwarding-class ic {
> loss-priority high code-point 110;
> loss-priority low code-point 110;
> }
> forwarding-class nc {
> loss-priority high code-point 111;
> loss-priority low code-point 111;
> }
> }
> }
>
> {master:0}
> admin@sw-kedr>
>
> --
> Victor Sudakov, VAS4-RIPE, VAS47-RIPN
> sip:suda...@sibptus.tomsk.ru
> ___
> 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] MC-LAG and layer 3 routing
What are the switches? If they are EX series, you could do redundant trunk groups up to the MX, have the port facing the switches and the port between the MXs in a bridge domain, and configure an irb interface running VRRP between them. Regards, Dave On 9 July 2015 at 10:16, Tomasz Mikołajek wrote: > http://imgur.com/xI5VdGn > > W dniu czwartek, 9 lipca 2015 besscou napisał(a): > >> Hi, >> Could you provide the architecture? >> >> Tomasz Mikołajek > wrote: >> >> >Hello. >> >I have two MX5 routers. I would like to configure mc-lags and to hosts in >> >my network. Do i have to use vrrp and rvi to get HA or i can only >> configure >> >same gateway on mc-lag interface? >> >Thank you in advance for help. >> >___ >> >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] Quick way to Shift MPLS traffic away from an interface
Hi Tim, If you are using LDP then traffic will automatically switch to follow the IGP. No clearing of LSPs required. Regards, Dave On 21 May 2015 18:49, "tim tiriche" wrote: > Hello, > > What is the quick way to shift LSP traffic from an interface after > increasing the igp metric? > > question: > > - What command can I use to find all lsp traversing the iface and a good > way to clear them? I am assuming I would need to run clear mpls > optimize-aggressive on the lsp's on that particular router only? Is my > understanding correct? > > - Is it a good idea to turn on optimize-aggressive? > > Any best practices or pointers would be appreciated! > > -Tim > ___ > 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] MX80 upgrade caveats
http://www.juniper.net/techpubs/en_US/junos14.1/information-products/topic-collections/release-notes/14.1/topic-83364.html#jd0e8341 This isn't very clear, but It would appear you will need to go through a couple of versions to get there. On 7 May 2015 at 18:49, thiyagarajan b wrote: > Hi, Any constraints for upgrading jmx80 from 11.4 to 14.1 directly? > > Warm Regards > Thiyagarajan B. > ___ > 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] 10G Interfaces
It looks like you have a card which has 2x10GE interfaces installed... FPC 5REV 18 750-022765 XX4446DPCE 20x 1GE + 2x 10GE R http://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/general/dpc-mx-series-dpce-r-20ge-2xge-description.html On 14 January 2015 at 09:45, Mohammad Khalil wrote: > Thanks for the replies > I have the machine up and running with SFPs for 1G capacity > I want to know if it supports 10G SFPs installation > > admin@CR01-A> show chassis hardware > Hardware inventory: > Item Version Part number Serial number Description > ChassisJN1160459AFB MX480 Midplane > Midplane REV 05 710-017414 ABAA5940 MX480 Midplane > FPM BoardREV 02 710-017254 XY0425Front Panel Display > PEM 0Rev 01 740-022697 QCS0946C06T PS 1.2-1.7kW; > 100-240V AC in > PEM 1Rev 01 740-022697 QCS0951C00W PS 1.2-1.7kW; > 100-240V AC in > PEM 2Rev 01 740-022697 QCS0951C00P PS 1.2-1.7kW; > 100-240V AC in > PEM 3Rev 01 740-022697 QCS0946C027 PS 1.2-1.7kW; > 100-240V AC in > Routing Engine 0 REV 09 740-015113 9009023662RE-S-1300 > CB 0 REV 07 710-021523 XX6292MX SCB > FPC 5REV 18 750-022765 XX4446DPCE 20x 1GE + 2x > 10GE R > CPUREV 03 710-022351 XX4190DPC PMB > PIC 0 BUILTIN BUILTIN 10x 1GE(LAN) > Xcvr 0 REV 02 740-013111 9423555 SFP-T > Xcvr 1 REV 01 740-031851 AC1101S005S SFP-SX > Xcvr 2 REV 02 740-013111 9420346 SFP-T > Xcvr 3 REV 02 740-013111 9423194 SFP-T > Xcvr 4 REV 02 740-013111 9420414 SFP-T > Xcvr 5 REV 02 740-013111 9423127 SFP-T > Xcvr 6 REV 02 740-013111 9420351 SFP-T > Xcvr 7 REV 02 740-013111 9420272 SFP-T > Xcvr 8 REV 02 740-013111 9420480 SFP-T > Xcvr 9 REV 02 740-013111 9420573 SFP-T > PIC 1 BUILTIN BUILTIN 10x 1GE(LAN) > Xcvr 0 REV 02 740-013111 9420295 SFP-T > Xcvr 1 REV 02 740-013111 B111787 SFP-T > Xcvr 2 REV 02 740-013111 B131674 SFP-T > Xcvr 3 REV 02 740-013111 9420452 SFP-T > Xcvr 4 REV 02 740-013111 A492228 SFP-T > Xcvr 5 REV 02 740-013111 A492642 SFP-T > Xcvr 6 REV 02 740-013111 9414690 SFP-T > Xcvr 7 REV 02 740-013111 A492426 SFP-T > Xcvr 8 REV 02 740-013111 B149378 SFP-T > Xcvr 9 REV 02 740-013111 9420474 SFP-T > PIC 2 BUILTIN BUILTIN 1x 10GE(LAN/WAN) > PIC 3 BUILTIN BUILTIN 1x 10GE(LAN/WAN) > Fan Tray Left Fan Tray > > On Tue, Jan 13, 2015 at 9:38 PM, Brad Fleming wrote: > >> Supports? Or has 10G interfaces currently installed? If you’re looking for >> installed 10G interfaces your can use the “show interface terse | match >> xe-“ command to find only the 10G interfaces currently installed in the >> box. NOTE: If you have SFP+ ports they will not show as ge- or xe- until >> the optic slot is populated since their personality can change with the >> module. >> >> >> > On Jan 13, 2015, at 8:28 AM, Mohammad Khalil wrote: >> > >> > Hi all >> > How can I know if My device supports 10G interfaces? >> > ___ >> > 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] Merging routes from VRF to inet.0
rib-groups is indeed the simplest way to do this. Something like this
should work for you:
routing-options {
rib-groups {
import_inet0 {
import-rib inet.0;
import-policy my_pol;
}
}
policy-options {
policy-statement my_pol {
term 10 {
from {
route-filter a.b.c.d/32 exact;
}
then accept;
}
term 30 {
then reject;
}
}
}
routing-instances {
my_instance {
routing-options {
static {
route 0.0.0.0/0 next-table inet.0;
}
auto-export {
family inet {
unicast {
rib-group import_inet0;
}
}
}
}
}
On 14 January 2015 at 09:31, Tom Eichhorn wrote:
> Hi Guys,
>
> I am currently facing a problem,
> to which I do not have currently a clean solution:
>
> I have routes in some L3 VPN vrf, and I need to merge some of them to
> inet.0,
> but I have no real clue how to do that.
>
> RIB-groups would only merge all, and tbh, I never understood rib-groups and
> the
> documentation is a little bit unclear how they work.
>
> My current solution is having a lt-interface between the inet.0 and
> vrf.inet.0 and speaking BGP,
> but that limits the traffic volume to one PFE (yes, I could have
> lt-interfaces on each PFE and do ECMP, but
> that would be that dirty...)
>
> I tried also instance-import under routing-options, but that doesn't work
> for some reason, instance-export
> in the vrf is not supported - this only works for virtual routers, but not
> VRFs...
>
> I also tried some bad hacks on the bgp configuration, e.g. deleting the
> vrf-community before importing etc,
> but all of that also did not work :(
>
> Any hint or idea?
>
> Thanks,
> Tom
>
> PS: For the other way round, getting the default route to the VRF, I simply
> use a next-table inet.0 route in the vrf.
> ___
> 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] ARP on unnumbered interfaces
Would the preferred-source-address statement work in your situation?
>From the link Madood posted:
interfaces {
lo0 {
unit 0 {
family inet {
address 2.2.2.1/32;
address 3.3.3.1/32;
}
}
}
}
interfaces {
ge-4/0/0 {
unit 0 {
family inet {unnumbered-address lo0.0 preferred-source-address
3.3.3.1;
}
}
}
}
On 11 Jan 2015 07:06, "Mihai" wrote:
> Thank you for your response.If the document is true,then all ARPs should
> be originated with the primary address and as you can see this is not the
> case (tested on multiple platforms with different codes,Cisco included).
> One workaround i found is to delete/add the static route,but it doesn't
> work in all cases.
>
>
> On 01/11/2015 02:13 AM, Masood Ahmad Shah wrote:
>
>> AFAIK, router uses the preferred source address when it is configured
>> for an unnumbered Eth interface, for arp requests and replies. arp
>> requests need to match the preferred source address, which is by default
>> primary interfaces
>>
>> lo0 {
>> unit 55 {
>> family inet {
>> address 5.5.5.5/32 { //That
>> would be this in your case.
>> primary;
>> }
>> address 10.10.10.1/24 ;
>> address 20.20.20.1/24 ;
>> }
>> }
>> }
>>
>> More here:
>> http://www.juniper.net/documentation/en_US/junos13.2/
>> topics/usage-guidelines/interfaces-configuring-an-
>> unnumbered-interface.html
>>
>> Cheers,
>> Masood
>>
>> On Sun, Jan 11, 2015 at 2:34 AM, Mihai > > wrote:
>>
>> Hello,
>>
>> After the migration of a large network from a Cisco 7600 to a
>> MX104 a lot of users started to have random problems with their
>> connection.
>> The setup is based on unnumbered interfaces and /32 static routes
>> through IFLs.
>> Basically, all clients with Cisco routers will have at some point a
>> missing ARP entry for their default gateway because the MX is
>> changing the ARP source address from the gw_addr to the primary
>> address.On Cisco i see the well known 'wrong cable' error.
>> Does anyone have a clue why is this happening beside a bug? I've
>> made some tests on MX960,MX480 and MX5 and didn't see this behavior.
>> This is a lab simulation:
>>
>>
>> mx# show
>>
>> interfaces {
>> ge-1/1/8 {
>> unit 55 {
>> vlan-id 55;
>> proxy-arp unrestricted;
>> family inet {
>> unnumbered-address lo0.55;
>> }
>> }
>> unit 56 {
>> vlan-id 56;
>> proxy-arp unrestricted;
>> family inet {
>> unnumbered-address lo0.55;
>> }
>> }
>> }
>> lo0 {
>> unit 55 {
>> family inet {
>> address 5.5.5.5/32 {
>> primary;
>> }
>> address 10.10.10.1/24 ;
>> address 20.20.20.1/24 ;
>> }
>> }
>> }
>> }
>> routing-options {
>> static {
>> route 20.20.20.2/32 {
>> qualified-next-hop ge-1/1/8.55;
>> }
>> route 10.10.10.2/32 {
>> qualified-next-hop ge-1/1/8.56;
>> }
>> }
>> router-id 5.5.5.5;
>> }
>>
>> mx> monitor traffic interface ge-1/1/8.55 detail no-resolve matching
>> arp
>> Address resolution is OFF.
>> Listening on ge-1/1/8.55, capture size 1514 bytes
>>
>> 17:28:11.105586 Out arp who-has 20.20.20.2 tell 20.20.20.1
>> 17:28:11.106100 In arp reply 20.20.20.2 is-at 00:1e:4a:fc:44:84
>> 17:29:20.504891 Out arp who-has 20.20.20.2 tell 20.20.20.1
>> 17:29:20.505375 In arp reply 20.20.20.2 is-at 00:1e:4a:fc:44:84
>> 17:30:30.104188 Out arp who-has 20.20.20.2 tell 20.20.20.1
>> 17:30:30.104632 In arp reply 20.20.20.2 is-at 00:1e:4a:fc:44:84
>>
>> .
>>
>> 17:53:01.790690 Out arp who-has 20.20.20.2 tell 5.5.5.5
>> 17:54:05.690056 Out arp who-has 20.20.20.2 tell 5.5.5.5
>>
>> 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
>
_
Re: [j-nsp] MPC3E oversubscribe rate with two 10x10GE MICs
"Supports up to 200 Gpbs aggregate WAN bandwidth connectivity for the two MIC slots; the line card is oversubscribed in the ratio of 1.5:1." https://www.juniper.net/documentation/en_US/junos12.1/topics/concept/chassis-mpc-100-gigabit-ethernet-mpc-overview.html Although it doesn't mention the 10x10GE card is supported, but I can't imagine it wouldn't be. Especially as you state you're already running it! Regards, Dave On 30 Nov 2014 23:23, "Robert Hass" wrote: > Hi > I'm currently using MPC3E with one 10x10GE MICs in my MX480 and MX960 > routers. > > I need to add 10GE ports, if I will put second 10x10GE MIC in existing > MPC3E what will be oversubscribe rate ? I'm not sure but docs says about > 200Gbps for MPC3E then It should be wire-speed if docs claims full-duplex > or 1:2 if docs claims half-duplex. > > What is best solution (from price point of view) to have 16 x 10GE in 1 > slot on MX480/MX960 ? MPC3E + 10x10GE MICs or something different ? > > Rob > ___ > 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] Firewall Policy Description !!
You can annotate your terms.
{master}[edit]
ad...@pe2.lab# edit policy-options policy-statement test
{master}[edit policy-options policy-statement test]
ad...@pe2.lab# set term test_term then accept
{master}[edit policy-options policy-statement test]
ad...@pe2.lab# annotate term test_term "This was an annotation"
{master}[edit policy-options policy-statement test]
ad...@pe2.lab# show
/* This was an annotation */
term test_term {
then accept;
}
Annoyingly you have to be in edit mode at the exact part of the hierarchy
to apply an annotation. You can't apply it from the top level.
Regards,
Dave
On Wed Nov 05 2014 at 15:34:15 Harri Makela via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
>
> Hi There
>
>
>
>
> is there anyway that we can add description of firewall policies. Firewall
> policy name is restricted to 63 chracters on Junos which is not sufficient
> to review the firewall policies on periodic basis. I can only add flows
> related information with policy name and description is required to add
> further details like who requested it, when it was added, quarterly review
> if this flow is required not etc. to comply with AUDIT requirements
>
>
>
>
>
> Thnaks
>
> On Wednesday, 29 October 2014, 16:05, "juniper-nsp-requ...@puck.neth
> er.net" wrote:
>
>
> Send juniper-nsp mailing list submissions to
> juniper-nsp@puck.nether.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> or, via email, send a message with subject or body 'help' to
> juniper-nsp-requ...@puck.nether.net
>
> You can reach the person managing the list at
> juniper-nsp-ow...@puck.nether.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of juniper-nsp digest..."
>
>
> Today's Topics:
>
> 1. Re: CoS on iSCSI ports (Eugeniu Patrascu)
> 2. EX4600 third party optic (Johan Borch)
>
>
> --
>
> Message: 1
> Date: Wed, 29 Oct 2014 01:09:49 +0200
> From: Eugeniu Patrascu
> To: Mike Gonnason
> Cc: "juniper-nsp@puck.nether.net"
> Subject: Re: [j-nsp] CoS on iSCSI ports
> Message-ID:
>
> Content-Type: text/plain; charset=UTF-8
>
> If memory serves me right, the 5% bandwidth is actually prioritized when
> you do something on the switch via SSH/Telnet/J-Web so that in case your
> switch is running line-rate, you can actually log into it.
>
> Also, disable flow-control, it's not helping.
>
> Regards,
> Eugeniu
>
> On Wed, Oct 15, 2014 at 2:49 AM, Mike Gonnason wrote:
>
> > For my iSCSI stuff, I have been disabling pause frames as they are not
> > really beneficial for my situation. I had a NetApp (forget what model)
> that
> > would saturate a 10Gb link and the Juniper would send a pause frame with
> > the result of dropping all connections across that trunk. Not very
> helpful.
> >
> > You can try modifying the NC class and alter how the scheduling is
> > performed. in section 21 you can see 5% is specified for the NC
> scheduler.
> >
> >
> > http://www.juniper.net/documentation/en_US/junos13.2/topics/
> example/cos-ex-series-configuring.html
> >
> >
> > -Mike Gonnason
> >
> > On Tue, Oct 14, 2014 at 3:39 PM, Josh Farrelly
> > wrote:
> >
> > > Hi all.
> > >
> > > We have 2x EX4550's in VC that provide switching for an iSCSI network.
> > > There are 3 Dell SANs and 4 Dell R820 ESXi hosts connected via twinax @
> > > 10Gbps. Jumbo frames and flow control is enabled.
> > >
> > > My knowledge around Juniper tech is a little vague, but what's with the
> > > default CoS settings on the switch? It seems they will automatically
> > > reserve 5% for network control traffic. Is there anyway to disable CoS
> > > entirely? AFAIK Brocade & Cisco don't have this type of default, and 5%
> > of
> > > a 10Gbps is actually a rather significant chunk of bandwidth.
> > >
> > > The reason I'm asking is that we've seen some performance issues
> lately.
> > > We have a hybrid-SSD tray of storage that can saturate a link, so we're
> > > seeing MAC pause frames being received by the switch as well as
> discards
> > on
> > > some of the queues.
> > >
> > > Thanks for any pointers.
> > >
> > > Regards,
> > >
> > > Josh.
> > > ___
> > > 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
> >
>
>
> --
>
> Message: 2
> Date: Wed, 29 Oct 2014 09:51:15 +0100
> From: Johan Borch
> To: "juniper-nsp@puck.nether.net"
> Subject: [j-nsp] EX4600 third party optic
> Message-ID:
>
> Content-Type: text/plain; charset=UTF-8
>
> Hi!
>
> Do anyone have experience with third party optics (SFP/SFP+) in EX4600?
>
> Johan
>
>
> --
>
Re: [j-nsp] warning: dhcp-service subsystem not running - not needed by configuration
As per http://forums.juniper.net/t5/Ethernet-Switching/DHCP-service/td-p/14917
try running
'restart dhcp gracefully'
On 7 July 2014 10:03, Victor Sudakov wrote:
> Colleagues,
>
> I am trying to configure an EX4200-24T as a DHCP server, but all I
> get is the "warning: dhcp-service subsystem not running - not needed
> by configuration" message.
>
> Could you please give me a hand and look what's wrong with the following
> configuration. I expected the DHCP server to run on the ge-0/0/0.0
> interface. I tried the legacy configuration from
> http://www.juniper.net/techpubs/en_US/junos13.2/topics/task/configuration/dhcp-server-cli.html
>
> admin@sw-km337> show configuration system services dhcp
> maximum-lease-time 604800;
> name-server {
> 10.14.140.125;
> 10.14.140.5;
> 10.14.140.38;
> }
> domain-search {
> sibptus.transneft.ru;
> }
> wins-server {
> 10.14.134.1;
> 10.14.134.4;
> }
> boot-file pxelinux.0;
> next-server 10.14.140.126;
> pool 10.14.135.176/29 {
> router {
> 10.14.135.177;
> }
> }
>
> {master:0}
> admin@sw-km337>
>
> admin@sw-km337> show configuration interfaces ge-0/0/0
> unit 0 {
> description Test;
> family inet {
> address 10.14.135.177/29;
> }
> }
>
> Thank you for any input.
>
> --
> Victor Sudakov, VAS4-RIPE, VAS47-RIPN
> sip:suda...@sibptus.tomsk.ru
> ___
> 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] loop detection on EX4200
You could try enabling bpdu-block-on-edge. http://www.juniper.net/techpubs/en_US/junos12.2/topics/task/configuration/spanning-trees-bpdu-block-cli.html Regards, Dave On 21 Apr 2014 05:56, "Victor Sudakov" wrote: > I have just had a funny experience on an EX4200 switch. > > An Avara ENT100 multiplexer is connected to ge-0/0/22 on the > EX4200. By mistake, an E1 port on the ENT100 was physically looped. > This resulted in an Ethernet loop in all the vlans which were active > on the ge-0/0/22 port, which the EX4200 was unable to prevent. > > Cisco switches can detect such conditions by sending special loopback > keepalives (Ether type 0x9000) and put the interface into errdisabled > state. Is there a similar feature in Juniper switches? > > Thank you for any input. > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > sip:suda...@sibptus.tomsk.ru > ___ > 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] apply-path regex for specific interface matching
I'm not sure you can do exactly what you are interested in. I would use two
prefix lists as follows.
policy-options {
prefix-list list1 {
apply-path "interfaces unit <*> family inet address <*>";
}
prefix-list list2 {
apply-path "interfaces unit <*> family inet
address <*>";
}
}
On 7 April 2014 02:45, Ben Dale wrote:
> Dredging up an old thread here, but I have a requirement for an apply-path
> that matches ae* and ge-1/[01]/[0-4] unit * (for a prefix-list).
>
> I must be missing something fundamental about the regex you can use in
> apply-path though, because all combinations I've tried seem to fail.
>
> About as close as I can get to something that actually gives me results is
> "interfaces <[ae|ge-1/0/]*> unit <*> family net address <*>" which isn't
> all that useful.
>
> It doesn't look like apply-path supports any nesting of regexes either eg:
> interfaces <[ae|ge-1/[01]/]*> returns no results at all
>
> Any thoughts?
>
> On 26 Feb 2014, at 1:48 pm, Michael Gehrmann <
> mgehrm...@macquarietelecom.com> wrote:
>
> > Hi Ben,
> >
> > I believe this document on the juniper site is what you were looking for.
> >
> >
> http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/junos-cli-wildcard-characters-configuration-groups-usage.html
> >
> > Cheers
> > Mike
> >
> > -Original Message-
> > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On
> Behalf Of Ben Dale
> > Sent: Wednesday, 26 February 2014 9:43 AM
> > To: juniper-nsp@puck.nether.net
> > Subject: [j-nsp] apply-path regex for specific interface matching
> >
> > Hi all,
> >
> > I'm trying to generate a prefix-list for all CE-facing interfaces on a
> PE (assume L3VPN).
> >
> > As a test, I'm just trying to match all ge interfaces, but the following
> returns no match at all:
> >
> > prefix-list CE-LINKS {
> >apply-path "interfaces ge-<*> unit <*> family inet address <*>"; }
> >
> > I've tried both ge<*>, ge-<*> but no luck either way, and as soon as I
> remove "ge-", I get all interface prefixes as expected.
> >
> > I vaguely remember a post here on this a while back, but I haven't been
> able to track it down and google/Juniper docs are not providing any info.
> >
> > Is anyone aware of 1) a solution, or 2) any docs that go through what
> regex is actually available in apply-path?
> >
> > Thanks,
> >
> > Ben
> >
> > ___
> > 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] Community matching policy
Yes, that's what that documentation is saying. You probably don't want a
single community statement then.
Regards,
Dave
On 31 March 2014 13:13, Andrew Khan wrote:
> Thanks, Dave! Your table is awesome and clarified my doubts and clicked
> into my mind :) On your query, "It may be possible to add the two
> communities into one community statement. I'm unsure how exactly that will
> behave though"
>
> let's say something like
> community A members [ 100:100 101:101 ]; // pretty much (100:100 AND
> 101:101) //
>
> In that case, the route must have a community that matches 100:100 and a
> community that matches 101:101
>
> http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-policy/policy-bgp-communities-extended-communities-evaluation-in-routing-policy-match-conditions.html
>
> Kind regards,
>
>
> --
> Date: Mon, 31 Mar 2014 12:59:57 +0100
>
> Subject: Re: [j-nsp] Community matching policy
> From: m...@geordish.org
> To: good1...@outlook.com
> CC: kr...@smartcom.bg; juniper-nsp@puck.nether.net
>
>
> The logic of !A OR !B makes my head hurt, so its simple to write out a
> truth table to work out exactly what it does.
>
> A | B | !A OR !B
> ---
> T | T | F
> T | F | T
> F | T | T
> F | F | T
>
> This makes it clear that !A OR !B is identical to !(A AND B)
>
> I don't think there is any way to do what you are interested in with the
> invert-match statement. I would just do something like this
>
> term A {
> from {
> community [ A B ];
> }
> then accept;
> }
> reject;
>
> community A {
> members 100:100;
> }
> community B {
> members 101:101;
> }
>
> It may be possible to add the two communities into one community
> statement. I'm unsure how exactly that will behave though.
>
> Regards,
> Dave
>
>
> On 31 March 2014 12:47, Andrew Khan wrote:
>
> In addition to my last question, what I don't understand is that !A OR !B
> <=> !(A AND B) /// how come it became AND operation rather than logical
> OR///
>
> From Juniper documentation:
> You can include the names of multiple communities in the community match
> condition. If you do this, only one community needs to match for a match to
> occur (matching is effectively a logical OR operation).
>
> Is it invert-match causing this behavior? What if I don't use
> invert-match, will it be a logical OR operation e.g. A OR B <=> A OR B or
> will it be A OR B <=> (A AND B)
>
> Thanks
>
>
>
> > From: good1...@outlook.com
> > To: kr...@smartcom.bg
> > Date: Mon, 31 Mar 2014 11:00:48 +
> > CC: juniper-nsp@puck.nether.net
> > Subject: Re: [j-nsp] Community matching policy
> >
> >
> >
> >
> > Hello Krasi,
> > Thanks for the reply, appreciated. Sorry I did not mention in my first
> email that I'm trying to find a workaround while using invert-match. Any
> idea on achieving the same results when using invert-match.
> >
> > Kind regards,
> >
> >
> > Date: Mon, 31 Mar 2014 13:41:40 +0300
> > Subject: Re: [j-nsp] Community matching policy
> > From: kr...@smartcom.bg
> > To: good1...@outlook.com
> > CC: juniper-nsp@puck.nether.net
> >
> > A match 100:100B match 101:101 Your TEST1 term match on !A OR !B <=> !(A
> AND B), so it effectively rejects every route that has NO communities
> 100:100 AND 101:101 (at the same time)
> > Your target is to accept A OR B, so you can first match and accept on
> these communities (TEST1 OR TEST2 defined without invert-match) and then
> reject everything else.
> > Best Regards,
> > Krasi
> >
> > On 31 March 2014 12:10, Andrew Khan wrote:
> >
> > Hi -
> >
> >
> >
> > Let's say I want to reject everything except the following communities:
> >
> >
> >
> > Either 100:100
> >
> > OR 101:101
> >
> > OR both 100:100 101:100
> >
> >
> >
> > Tried to setup something:
> >
> >
> >
> > [edit policy-options]
> >
> > policy-statement TEST {
> >
> > term TEST1 {
> >
> > from community [ TEST1 TEST2 ]; ///Is not it logical OR,
> and matching everything except what I want because of invert-match//
> >
> >then reject;
> >
> >}
> >
> > term TEST2 {
> >
> > then accept; And then this should accept what I wanted /
> >
> >}
> >
> > }
> >
> >
> >
> > [edit policy-options]
> >
> >community TEST1 {
> >
> > invert-match;
> >
> >members 100:100;
> >
> >}
> >
> >community TEST2 {
> >
> >invert-match;
> >
> >members 101:101;
> >
> >}
> >
> >
> >
> > However it is rejecting everything. Any thoughts what I'm missing here
> or perhaps the approach is not correct.
> >
> >
> >
> > Thanks in advance.
> >
> >
> >
> >
> >
> > ___
> >
> > 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
Re: [j-nsp] Community matching policy
The logic of !A OR !B makes my head hurt, so its simple to write out a
truth table to work out exactly what it does.
A | B | !A OR !B
---
T | T | F
T | F | T
F | T | T
F | F | T
This makes it clear that !A OR !B is identical to !(A AND B)
I don't think there is any way to do what you are interested in with the
invert-match statement. I would just do something like this
term A {
from {
community [ A B ];
}
then accept;
}
reject;
community A {
members 100:100;
}
community B {
members 101:101;
}
It may be possible to add the two communities into one community statement.
I'm unsure how exactly that will behave though.
Regards,
Dave
On 31 March 2014 12:47, Andrew Khan wrote:
> In addition to my last question, what I don't understand is that !A OR !B
> <=> !(A AND B) /// how come it became AND operation rather than logical
> OR///
>
> From Juniper documentation:
> You can include the names of multiple communities in the community match
> condition. If you do this, only one community needs to match for a match to
> occur (matching is effectively a logical OR operation).
>
> Is it invert-match causing this behavior? What if I don't use
> invert-match, will it be a logical OR operation e.g. A OR B <=> A OR B or
> will it be A OR B <=> (A AND B)
>
> Thanks
>
>
>
> > From: good1...@outlook.com
> > To: kr...@smartcom.bg
> > Date: Mon, 31 Mar 2014 11:00:48 +
> > CC: juniper-nsp@puck.nether.net
> > Subject: Re: [j-nsp] Community matching policy
> >
> >
> >
> >
> > Hello Krasi,
> > Thanks for the reply, appreciated. Sorry I did not mention in my first
> email that I'm trying to find a workaround while using invert-match. Any
> idea on achieving the same results when using invert-match.
> >
> > Kind regards,
> >
> >
> > Date: Mon, 31 Mar 2014 13:41:40 +0300
> > Subject: Re: [j-nsp] Community matching policy
> > From: kr...@smartcom.bg
> > To: good1...@outlook.com
> > CC: juniper-nsp@puck.nether.net
> >
> > A match 100:100B match 101:101 Your TEST1 term match on !A OR !B <=> !(A
> AND B), so it effectively rejects every route that has NO communities
> 100:100 AND 101:101 (at the same time)
> > Your target is to accept A OR B, so you can first match and accept on
> these communities (TEST1 OR TEST2 defined without invert-match) and then
> reject everything else.
> > Best Regards,
> > Krasi
> >
> > On 31 March 2014 12:10, Andrew Khan wrote:
> >
> > Hi -
> >
> >
> >
> > Let's say I want to reject everything except the following communities:
> >
> >
> >
> > Either 100:100
> >
> > OR 101:101
> >
> > OR both 100:100 101:100
> >
> >
> >
> > Tried to setup something:
> >
> >
> >
> > [edit policy-options]
> >
> > policy-statement TEST {
> >
> > term TEST1 {
> >
> > from community [ TEST1 TEST2 ]; ///Is not it logical OR,
> and matching everything except what I want because of invert-match//
> >
> >then reject;
> >
> >}
> >
> > term TEST2 {
> >
> > then accept; And then this should accept what I wanted /
> >
> >}
> >
> > }
> >
> >
> >
> > [edit policy-options]
> >
> >community TEST1 {
> >
> > invert-match;
> >
> >members 100:100;
> >
> >}
> >
> >community TEST2 {
> >
> >invert-match;
> >
> >members 101:101;
> >
> >}
> >
> >
> >
> > However it is rejecting everything. Any thoughts what I'm missing here
> or perhaps the approach is not correct.
> >
> >
> >
> > Thanks in advance.
> >
> >
> >
> >
> >
> > ___
> >
> > 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
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QinQ
I think you have your outer and inner vlans mixed up. The config you have written for the EX will have 305 as the outer, but on the MX you have 105 as the outer. Dave On 6 March 2014 09:23, Mohammad Khalil wrote: > Hi guys , can anyone assist with the above configuration ? > I have tried the same with EX4200 and MX480 and did not work as well > > BR, > Mohammad > > > On Wed, Jun 26, 2013 at 11:20 AM, Mohammad Khalil >wrote: > > > Hi and sorry for the late reply > > Please find the configuration I did > > > > ex3200: > > > > -- > > > > > > > > set interfaces ge-0/0/23.0 family ethernet-switching vlan members v305 > > > > set vlans v305 vlan-id 305 > > > > set vlans v305 interface ge-0/0/23.0 > > > > set vlans v305 dot1q-tunneling customer-vlans 105 > > > > > > > > MX480: > > > > --- > > > > set interfaces ge-5/0/8 unit 0 family bridge vlan-id-list 305 > > > > set bridge-domains VLAN-305 domain-type bridge > > > > set bridge-domains VLAN-305 vlan-tags outer 105 > > > > set bridge-domains VLAN-305 vlan-tags inner 305 > > > > set bridge-domains VLAN-305 routing-interface irb.305 > > BR, > > Mohammad > > > > > > On Tue, Jun 18, 2013 at 4:17 PM, Jared Gull wrote: > > > >> Hi Mohammad, > >> > >> Can you share your current configurations and the topology details? > Also, > >> please explain how you're testing this and what you're seeing or not > seeing. > >> > >> -Thanks, > >> > >> Jared > >> > >> -- > >> *From:* Mohammad Khalil > >> *To:* "juniper-nsp@puck.nether.net" > >> *Sent:* Tuesday, June 18, 2013 1:49 AM > >> *Subject:* [j-nsp] QinQ > >> > >> Hi all , i am trying to implement QinQ between mx480 and ex4200 , does > >> anyone have previous experience with that ? > >> > >> 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] apply-path regex for specific interface matching
Try .
Dave
On 25 Feb 2014 22:45, "Ben Dale" wrote:
> Hi all,
>
> I'm trying to generate a prefix-list for all CE-facing interfaces on a PE
> (assume L3VPN).
>
> As a test, I'm just trying to match all ge interfaces, but the following
> returns no match at all:
>
> prefix-list CE-LINKS {
> apply-path "interfaces ge-<*> unit <*> family inet address <*>";
> }
>
> I've tried both ge<*>, ge-<*> but no luck either way, and as soon as I
> remove "ge-", I get all interface prefixes as expected.
>
> I vaguely remember a post here on this a while back, but I haven't been
> able to track it down and google/Juniper docs are not providing any info.
>
> Is anyone aware of 1) a solution, or 2) any docs that go through what
> regex is actually available in apply-path?
>
> Thanks,
>
> Ben
>
> ___
> 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] CoS and ingress traffic with DSCP markings
Hi John, As far as I'm aware, when traffic hits the box, it has to be put into a forwarding class. If you have not defined any, it will drop into the default forwarding class. There are commands you can run that will show you what forwarding classes are attached to your interfaces - I can't remember them off the top of my head though! If you do have rewrite rules on egress, then you will likely mark it to DF as you were seeing. It sounds like you have hit the nail on the head. Dave On 22 January 2014 16:20, John Neiberger wrote: > I ran into an issue yesterday that confused me, which seems to be a > weekly occurrence lately regarding Juniper CoS.. We had an interface > that was receiving traffic marked as EF. The interface only had the > default CoS configuration. For some reason, the traffic was arriving > at the destination marked as CS0. After I applied the CoS group to the > interface, which included classifiers, the packets started arriving at > the destination as EF like they were supposed to be. > > I don't understand why a lack of CoS config would reset DSCP markings > for traffic that is already marked when it hits the router. Could it > be that since there were no ingress classifiers, the traffic was not > put into a forwarding class, so the rewrite rules on egress re-marked > it? That just occurred to me. I'm going to go check the rewrites rules > we have applied on egress to see if that is what was happening. I was > under the bad assumption that traffic already marked would traverse > the router unchanged. > > Thanks, > John > ___ > 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] batch on junos ?
I believe this should be possible to do with Junoscript. Dave On 14 January 2014 10:28, R S wrote: > Is there a way to run a sort of .bat on SRX junos ? > > I mean, to run a single command from cli to do some actions (set xxx/ set > yyy/ commit check / commit) ? > > This is useful to be runned by NOC for scheduled action every day. > > Tks > > > > ___ > 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] EoMPLS data rate
Have you thought about traffic shaping instead?
On 29 November 2013 10:54, Vincent wrote:
> Hello all,
>
> we are trying to build for a customer an EoMPLS circuit of 10 Mbps over a
> GE interface.
>
> Configuration looks like this at this moment:
>
> dude@LAB-MX960> show configuration protocols l2circuit
> neighbor 172.16.50.1 {
> interface ge-0/1/1.0 {
> virtual-circuit-id 1;
> }
> }
>
> ... with something similar at the other end of the network. This is easy
> and works quite well.
>
> Next step is to limit the traffic to 10 Mbps.
>
> We were thinking of using a simple policer like:
>
> dude@LAB-MX960> show configuration firewall policer 10M_fwp
> if-exceeding {
> bandwidth-limit 10m;
> burst-size-limit 15k;
> }
> then discard;
>
> ... and apply it on the ingress interface, but maybe that's a little bit
> too rough (in terms of packet drops and TCP backoff)? Furthermore we are
> not sure on how to select the burst parameter.
>
> Is there any better way to achieve this ? Note that the customer should not
> be able to burst for a long time, and have this traffic above 10 Mbps go to
> a best-effort QoS: we just want to limit its traffic to a certain level
> without completely breaking its TCP connections.
>
> Does this all make sense?
>
> Thanks,
>
> Vincent
> ___
> 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] LAG on Ex4200 fiber + copper
It appears to work..
david.bell@sw1> show chassis hardware
Hardware inventory:
Item Version Part number Serial number Description
ChassisBRXX Virtual Chassis
Routing Engine 0 REV 18 750-021258 BRXX EX4200-24F
FPC 0REV 18 750-021258 BRXX EX4200-24F
...
FPC 1REV 22 750-021256 BMXX EX4200-24T, 8 POE
CPU BUILTIN BUILTIN FPC CPU
PIC 0 BUILTIN BUILTIN 24x 10/100/1000
Base-T
david.bell@sw1# show | compare
[edit chassis]
+ aggregated-devices {
+ ethernet {
+ device-count 1;
+ }
+ }
[edit interfaces ge-0/0/10]
+ether-options {
+802.3ad ae0;
+}
[edit interfaces ge-1/0/10]
+ether-options {
+802.3ad ae0;
+}
[edit interfaces]
+ ae0 {
+ aggregated-ether-options {
+ lacp {
+ active;
+ }
+ }
+ unit 0 {
+ family ethernet-switching;
+ }
+ }
david.bell@sw1# commit check
configuration check succeeds
fpc1:
configuration check succeeds
Not actually tried in the lab however.
On 29 November 2012 14:07, Riccardo S wrote:
>
> Tks
> I'd like to buy them after I'm aware it works... ;-)
>
> @Darius, if you are able to try pls share the results... ;-)
>
> tks
>
> Date: Thu, 29 Nov 2012 08:27:50 -0500
> Subject: Re: [j-nsp] LAG on Ex4200 fiber + copper
> From: ja...@freedomnet.co.nz
> To: dim0...@hotmail.com
> CC: juniper-nsp@puck.nether.net
>
> In theory it should be possible. The best thing todo is configure it and
> do a commit check and see what happens.
>
>
> On Thu, Nov 29, 2012 at 3:07 AM, Riccardo S wrote:
>
>
>
> Mates
>
> any other experience in regards on the initial question ?
>
>
>
> Tks
>
>
>
> Date: Wed, 28 Nov 2012 11:00:59 +0100
>
> Subject: Re: [j-nsp] LAG on Ex4200 fiber + copper
>
> From: dariu...@gmail.com
>
> To: dim0...@hotmail.com
>
> CC: juniper-nsp@puck.nether.net
>
>
>
> As far as I know and according to all Juniper docs you can only use
> optical pic ports and of course the dedicated vc port for this
>
> eg.
>
>
> https://www.juniper.net/techpubs//en_US/junos/topics/example/virtual-chassis-ex4200-link-aggregation-over-extended-vcps.html
>
>
>
>
> Regards,Darius
>
>
>
> On Wed, Nov 28, 2012 at 10:28 AM, Riccardo S wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On ex-4200-24T
>
>
>
> is it possible to create a LAG using a 1 Gb up-link fiber port + a 1 Gb
> copper
>
>
>
> port ?
>
>
>
>
>
>
>
>
>
>
>
> Any juniper.net
>
>
>
> reference about that ?
>
>
>
>
>
>
>
>
>
>
>
> Tks
>
>
>
>
>
>
>
>
>
>
>
> ___
>
>
>
> 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
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Tacacs on Junos
On 17 September 2012 15:04, Mohammad Khalil wrote: > I was expecting that adding a user and password on the tacacs server and > adding server related parameters on the device will be enough such as on > Cisco ? why should I configure a user on the router itself ?! The users aren't users as such, they are more privilege classes. We for instance configure a 'noc' user, which contains all the permissions our NOC would require when logging into a device. All users that then log in are given the permissions of this 'noc' user. The following URL should help you with the full configuration: http://kb.juniper.net/InfoCenter/index?page=content&id=KB17269 Regards, -- Dave ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
