Re: [j-nsp] ATM config
Hi Clue,
Your configurations for below mentioned requirement will be as follows in JUNOS.
Suppose you have installed atm pic in fpc 0 pic slot 0.
Configuration for Internet PVC
at-0/0/0 {
mtu 9192;
encapsulation atm-pvc;
atm-options {
pic-type atm2;
promiscuous-mode {
vpi 3;
}
}
unit 101 {
description ***Internet PVC***;
encapsulation atm-snap;
vci 3.101;
family inet {
mtu 1500;
address x.x.x.x/30;
}
}
Configuration for atm cross connect
at-0/0/0 {
mtu 9192;
encapsulation atm-pvc;
atm-options {
pic-type atm2;
promiscuous-mode {
vpi 3;
}
}
unit 102 {
description 1st pvc from Provider to be switched;
encapsulation atm-ccc-cell-relay;
vci 3.102;
}
}
at-0/0/1 {
mtu 9192;
encapsulation atm-pvc;
atm-options {
pic-type atm2;
promiscuous-mode {
vpi 3; # suppose you are using same vp at cisco side too. you can
change here if you want
}
}
unit 102 {
description 1st pvc to Cisco to be switched;
encapsulation atm-ccc-cell-relay;
vci 3.102;
}
}
protocols {
connections {
interface-switch provider-to-cisco-1st-pvc {
interface at-0/0/0.102;
interface at-0/0/1.102;
}
}
}
Similarly you will switch the second pvc.
Regards,
Farooq
Date: Thu, 27 Aug 2009 09:33:05 -0500
From: cluest...@gmail.com
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] ATM config
I have found some info about frame-relay CCC and I would imagine the ATM CCC
would be similar, but I am a little confused as to which CCC variant of ATM
I will need and it can still land one of those PVC's on the m10i doing the
switching.
[edit]
interfaces {
so-1/0/0 {
encapsulation
http://www.juniper.net/techpubs/software/junos/junos76/swconfig76-network-interfaces/html/interfaces-summary112.html#2216533
frame-relay-ccc;
unit
http://www.juniper.net/techpubs/software/junos/junos76/swconfig76-network-interfaces/html/interfaces-summary421.html#1017673
1 {
point-to-point
http://www.juniper.net/techpubs/software/junos/junos76/swconfig76-network-interfaces/html/interfaces-summary292.html#1016678;
eui-64
http://www.juniper.net/techpubs/software/junos/junos76/swconfig76-network-interfaces/html/interfaces-summary122.html#1320392
frame-relay-ccc;
dlci
http://www.juniper.net/techpubs/software/junos/junos76/swconfig76-network-interfaces/html/interfaces-summary100.html#2083014
600;
}
}
so-2/0/0 {
encapsulation
http://www.juniper.net/techpubs/software/junos/junos76/swconfig76-network-interfaces/html/interfaces-summary112.html#2216533
frame-relay-ccc;
unit 2 {
point-to-point;
encapsulation frame-relay-ccc;
dlci
http://www.juniper.net/techpubs/software/junos/junos76/swconfig76-network-interfaces/html/interfaces-summary100.html#2083014
750;
}
}
}
protocols {
connections
http://www.juniper.net/techpubs/software/junos/junos76/swconfig76-network-interfaces/html/interfaces-summary75.html#1014816
{
interface-switch
http://www.juniper.net/techpubs/software/junos/junos76/swconfig76-network-interfaces/html/interfaces-summary169.html#1015803
router-a-router-c {
interface so-1/0/0.1;
interface so-2/0/0.2;
}
}
mpls {
interface all;
}
}
On Wed, Aug 26, 2009 at 10:42 PM, Clue Store cluest...@gmail.com wrote:
Hi List,
I have a situation where I need to take 3 PVC's that I am getting from a
provider and land one of them on an ATM interface (OC-3) and possibly
cross-connect the others to the second port in the PIC to send to another
router (basically performing an ATM switch functionality). Can this be done
on a 2x OC-3 ATM, SMIR PIC on a m10i ?? And if so, can someone point me to
some config samples as to how to do this?? I imagine this would be a CCC
on interface, but I am a complete noob when it comes to ATM on the juniper.
Relevent configs of what I need to do are below.
Current Cisco config...
interface ATM2/0
no ip address
ip route-cache flow
load-interval 30
no atm ilmi-keepalive
!
interface ATM2/0.1 point-to-point -- PVC I wish
to terminate on the first OC-3 Port
description ***Internet PVC***
ip address x.x.x.x 255.255.255.252
pvc 3/101
protocol ip x.x.x.x broadcast
ubr 75000
encapsulation aal5snap
!
!
interface ATM2/0.2 point-to-point 1st PVC
CCC to the second port to connect back to the cisco
description Customer1 T1 #1
ip address x.x.x.x 255.255.255.252
pvc 3/102
protocol ip x.x.x.x broadcast
ubr 75000
encapsulation aal5snap
!
!
interface ATM2/0.3 point-to-point 2nd PVC
CCC to the second
[j-nsp] ISIS default route question
hey everyone, I'm studying junos isis. well, most part is simillar to cisco, but I got a problem with default route. here's the senario: ISP router ---(ebgp with default route )-- edge1 ( L1 router )core1(L1/2 router)l2 adjcore2(L1/2 router)-L1 router for propergating the default learned from ISP at edge1 to the rest of isis network, the cisco solution is simple ( core1 generates default with a rotue-map to check DMZ link up/down ), but I can't figure out junos solution. Can someone help me out on this? Thanks. not quite familar with junos isis since it's not in our production. :) Min ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ISIS default route question
ha, I figured it out. :) on core1, define a generated route ( 0/0, not default ) with a policy match from protocol isis, from route-filter 0/0 exact, then export this generated route to L2. match condition for the policy used by generate could be something else more specific. tested works. On Fri, Sep 4, 2009 at 1:01 AM, Yue Minsmartsui...@gmail.com wrote: hey everyone, I'm studying junos isis. well, most part is simillar to cisco, but I got a problem with default route. here's the senario: ISP router ---(ebgp with default route )-- edge1 ( L1 router )core1(L1/2 router)l2 adjcore2(L1/2 router)-L1 router for propergating the default learned from ISP at edge1 to the rest of isis network, the cisco solution is simple ( core1 generates default with a rotue-map to check DMZ link up/down ), but I can't figure out junos solution. Can someone help me out on this? Thanks. not quite familar with junos isis since it's not in our production. :) Min ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Restore M7 to initial state
sth...@nethelp.no wrote: mas...@voyager# load factory-default The problem with this is that it won't let you commit without setting a root password. Now if I want to create something which looks like a factory fresh router it I specifically don't want it to have a root password. So, a small request for enhancement here: JunOS should let you commit an *empty* configuration even if root password has not been set. You might also need to delete configuration archives nd logs. Have a look @ /config /var/db/config /var It would be nice to have a ready-made command to clean these (and any other directories that might have been written to). Steinar, you are right: it is impossible to restore the machine to true 'factory default' because the JUNOS doesn't allow to commit the config, after a load factory-default with no or empty root password. On the other side I was unable to create a root user with empty password via JUNOS regular commands. *am* - Andrea Montefusco iw0hdvhttp://www.montefusco.com tel: +393356992791 fax: +390623318709 - ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Community RegEx
Hi all, I'm having some trouble identifying the proper way to define some communities. I've read this: http://www.juniper.net/techpubs/software/junos/junos94/swconfig-policy/configuring-the-community-attribute-using-unix-regular-expressions.html but still have questions. Let's say I have three communities 1234:100, 1234:250, and 1234:375. According to the docs, it appears they should be defined as such: ^1234:((100)|(250)|(375))$ However, I have several community definitions that seem to work in the following format: ^1234:(100)|(250)|(375)$ I would think that the first one is the way to go, but it appears that both work. Is one a more righter way of defining these communities? -evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Community RegEx
-Original Message- From: Paul Stewart [mailto:p...@paulstewart.org] Sent: Friday, September 04, 2009 8:02 AM To: Eric Van Tol; juniper-nsp@puck.nether.net Subject: RE: [j-nsp] Community RegEx Probably the real question is what you wish to accomplish with communities - do you want to use them just for marking interesting info or do you want to use them for filtering? You can also take them to the point of allowing your downstream BGP customers to influence their traffic through your network... Communities are very cool in my opinion - but you need a good plan of attack for utilizing them to save yourself headaches..;) Paul Hi Paul, Thanks for the response. We already have a pretty complex community policy, which allows for downstream filtering and also allows our customers to set attributes for their prefixes both within our network and upstream from us. Is there a difference between the two ways to define these communities that works better for one plan of attack than another? I wouldn't think so, but it wouldn't be the first time I was wrong about something like this. -evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Community RegEx
On Fri, Sep 04, 2009 at 07:52:35AM -0400, Eric Van Tol wrote: I would think that the first one is the way to go, but it appears that both work. Is one a more righter way of defining these communities? Thats like asking which of the following two math expressions is more right: A+B+C or (A+B+C) Both say the same thing, the extra ()s on the second are unnecesary because you aren't doing anything else with the expression in which the parenthesis change the order of the operations. Now, if you were to later come along and add * 2 to the expression it would suddenly make a difference to the result. But I doubt you would argue that you should always put all of your existing expressions inside unnecessary parens all the time, just incase someone were to come along and reuse your A+B+C snippit in another expression without fully understanding how math works. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX-4200 VC, unable to lock config on fpc
Hi Ross, Have you got some news about this PR? Do you know in which JUNOS version it will be fixed? Regards, Samuel -Message d'origine- De : juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] De la part de Ross Vandegrift Envoyé : jeudi 25 juin 2009 21:18 À : Firth,MJC,Michael,DMJ R Cc : Juniper-NSP Objet : Re: [j-nsp] EX-4200 VC, unable to lock config on fpc On Thu, Jun 25, 2009 at 07:51:03PM +0100, Firth,MJC,Michael,DMJ R wrote: Could you keep us updated with the progress of this? In particular a PR number if you get one, and whether the issue only affects VCed EXes, or if it can also cause issues on standalone units. I just finished a secure meeting with ATAC and Juniper engineering. It definitely only affects virtual chassis EX-4200s, as it requires a backup RE. No idea if it affects EX-8200s. dcd on the backup RE is leaking one file descriptor per physical interface in the virtual chassis. When the number of leaked descriptors exceeds 2000 (the kern.maxfiles limit), any commit causes mgd to corrupt the configuration database on the backup RE. A PR is being filed on the issue (don't have a number yet). You can clear the condition by killing dcd on the backup, blowing away the config database on the backup, restarting mgd, and HUPing init. -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ 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-4200 VC, unable to lock config on fpc
On Fri, Sep 04, 2009 at 04:06:10PM +0100, samuel@bt.com wrote: Have you got some news about this PR? Do you know in which JUNOS version it will be fixed? Yes! This was fixed as part of 9.3S4, but that release contained a bug that would cause copper ports to spam pause frames. 9.3R4.4 is out and contains the fix for this issue from 9.3S4. We have tested this version and confirmed it looks good. It's in production on some of our VCs and is working great. Upgrades for the rest are in the works. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Community RegEx
-Original Message- From: Richard A Steenbergen [mailto:r...@e-gerbil.net] Sent: Friday, September 04, 2009 11:26 AM To: Eric Van Tol Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Community RegEx On Fri, Sep 04, 2009 at 07:52:35AM -0400, Eric Van Tol wrote: I would think that the first one is the way to go, but it appears that both work. Is one a more righter way of defining these communities? Thats like asking which of the following two math expressions is more right: A+B+C or (A+B+C) Both say the same thing, the extra ()s on the second are unnecesary because you aren't doing anything else with the expression in which the parenthesis change the order of the operations. Now, if you were to later come along and add * 2 to the expression it would suddenly make a difference to the result. But I doubt you would argue that you should always put all of your existing expressions inside unnecessary parens all the time, just incase someone were to come along and reuse your A+B+C snippit in another expression without fully understanding how math works. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) A private response (thanks, Chris!) indicates to me that the following two are actually correct: ^1234:((100)|(250)|(375))$ ^1234:(100|250|375)$ My other example works, but also matches on other patterns such as 999:250, 38549:250, and 7:100: ^1234:(100)|(250)|(375)$ -evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] prefix-limit effectiveness
A follow up from months ago- despite the fact that I was rejecting all of the
routes from my upstream peer on this router, and limiting the total to 5000, it
was still crowding out memory, and not all of the routes from OSPF neighbors
were making it into the routing table. Even though these routes were 'hidden'
they were still taking up space (which is to be expected.)
The keep none command in this particular peer configuration is what did the
trick- it actually removes the routes, not just positing them as 'hidden' which
then cleared up space in the router, and all of my OSPF routes finally had room
to populate within the 5000 prefix limit.
Just thought I'd drop this nugget here in case anyone runs into the same issue.
Thanks,
Dan
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Dan Farrell
Sent: Monday, February 09, 2009 11:33 AM
To: Richard A Steenbergen
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] prefix-limit effectiveness
Thanks for the information... I will let you know how it goes (though it seems
you already know hehehe, since this was your baby.)
Thanks,
Dan
-Original Message-
From: Richard A Steenbergen [mailto:r...@e-gerbil.net]
Sent: Thursday, February 05, 2009 7:04 PM
To: Dan Farrell
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] prefix-limit effectiveness
On Thu, Feb 05, 2009 at 02:05:14PM -0800, Dan Farrell wrote:
Then I limit the number of prefixes it will even look at to 5000 -
import default-route;
family inet {
unicast {
prefix-limit {
maximum 5000;
...
This is effective- I have only the default to use from my upstream.
But I keep generating tons of log messages because I keep getting (and
rejecting) tons of routes. Without asking the upstream to not
advertise the full route table, is there something I can do on my end
to limit the syslog messages I keep getting?
Feb 5 19:00:43 nap-r2-edge-2 rpd[82464]: RPD_RT_PREFIX_LIMIT_REACHED:
Number of prefixes (4000) in table inet.0 still exceeds or equals configured
maximum (4000)
Well technically speaking you can always filter by regexp anything that
you send to system, but what you really want is accepted-prefix-limit
instead of prefix-limit above.
Prefix-limit is applied to all routes received by the router, even if
they are rejected by your import policy. Basically this protects router
DRAM from something going wild and sending you a billion routes, but is
less useful as a policy protection, or in your case to limit the number
of routes being installed to FIB.
Accepted-prefix-limit is a relatively new feature added in 9.2 (and
pardon me while I do a little dance about it, but this is one of my
feature requests which I've been asking for for 6 years and it just
finally got implemented! :P) which limits the number of routes AFTER
your import policy has been applied. In the example above, even though
you are receiving a full table, you are rejecting all but 1 route in
policy, so the value that would be evaluated yb accepted-prefix-limit is
1.
--
Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Community RegEx
On Fri, Sep 04, 2009 at 01:35:53PM -0400, Eric Van Tol wrote: A private response (thanks, Chris!) indicates to me that the following two are actually correct: ^1234:((100)|(250)|(375))$ ^1234:(100|250|375)$ My other example works, but also matches on other patterns such as 999:250, 38549:250, and 7:100: ^1234:(100)|(250)|(375)$ Oh, duh, yes I wasn't even paying attention to that part I thought your question was just about the external parens. To do that or you want (123|234|345), the additional parens around the individual items are what is unnecessary. And of course you need the ^ $ to protect the begin and end, otherwise you'd match 1234 as well as 11234, etc, etc. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
