[j-nsp] MPC-3D-16XGE-SFPP on MX960
Hey Guys, We just tired installing a MPC-3D-16XGE-SFPP on a MX960 running 10.0R2.10 on slot 0 and got a error FPC 0 misconfigured. After this message, any attempt to online the FPC just fails with the same message again. The output of show chassis fpc shows the following; Temp CPU Utilization (%) MemoryUtilization (%) Slot State(C) Total Interrupt DRAM (MB) Heap Buffer 0 Offline ---FPC misconfiguration--- 1 Online28 12 0 1024 23 33 Anyone else encounter this problem before? This is occurring on 2 separate cards on different routers, so I don't think the cards are faulty. Any help would be greatly appreciated! Thanks, Michael ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MPC-3D-16XGE-SFPP on MX960
Hi Michael You cannot mix MPC and DPC in the same chassis before 10.2, so you'll need either to upgrade to 10.2 (which is in beta) or remove the DPC in slot 1 You *should* also have upgraded the fan trays cheers Sean On 5/4/10 8:25 AM, Michael Phung wrote: Hey Guys, We just tired installing a MPC-3D-16XGE-SFPP on a MX960 running 10.0R2.10 on slot 0 and got a error FPC 0 misconfigured. After this message, any attempt to online the FPC just fails with the same message again. The output of show chassis fpc shows the following; Temp CPU Utilization (%) MemoryUtilization (%) Slot State(C) Total Interrupt DRAM (MB) Heap Buffer 0 Offline ---FPC misconfiguration--- 1 Online28 12 0 1024 23 33 Anyone else encounter this problem before? This is occurring on 2 separate cards on different routers, so I don't think the cards are faulty. Any help would be greatly appreciated! Thanks, Michael ___ 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 IPSEC VPN
Dear Nick, You could check your IPSec logs to dig down the exact reason due to which tunnel is dropping. It must be some parameter mismatch. Normally if your establish tunnel between cisco devices and there is a parameter mismatch, the tunnel wont establish. but incase of juniper the tunnel will establish but you will face abnormal behavior. regards, Asad On Tue, May 4, 2010 at 3:16 AM, Joe C joe.cob...@googlemail.com wrote: Nick, I have set up IPsec tunnels between Juniper SRX 240 (started with 9.6, current one is a 10.x) and Cisco ISR and, the devil hides in the small details. Off the top of my head, I remember the lifetime defaults on both cisco and Juniper don't get along and I found the SRX setting a lifetime of 0 seconds, endlessly dropping and re-establishing the SA. Although it's not the same hardware scenario, it might help. JC On 3 May 2010, at 22:26, Nick Ryce wrote: After some further testing it looks like the juniper keeps re-establishing the tunnel every 10-20 seconds or so. Does anyone have real world experience of getting a j2320 ipsec tunnel working with an ASA5510? Nick ___ 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] policy from JNCIP book
Hi,
I am trying to understand the policy in BGP, in JNCIP book we have following
policy with term 1 to 3. Term 1 and 2 is rejecting all unwanted routes and
term 3 is matching those are originating in C1 and reference to the next
policy. So here next policy will be next term (term4) if so then it will be
rejected ? if it is pointing to other policy then it is not define then will
it mach to the BGP default policy to accept all EBGP routes? Please help me
to understand. This policy is used in import at EBGP peer to accept the
selected route. Same way if I want to match customer prefix route, lets say
1.1.1.0/24 then in term I will use route filter to match the prefix and then
next-policy?
term 1 {
from {
route-filter 0.0.0.0/0 through 0.0.0.0/7 reject;
route-filter 0.0.0.0/1 prefix-length-range /1-/7 reject;
}
}
term 2 {
from {
route-filter 0.0.0.0/0 prefix-length-range /29-/32 reject;
route-filter 172.16.0.0/12 orlonger reject;
route-filter 192.168.0.0/16 orlonger reject;
route-filter 10.0.0.0/8 orlonger reject;
}
}
term 3 {
from as-path c1;
then next policy;
}
term 4 {
then reject;
}
--
David W.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] policy from JNCIP book
So in my case, sanity checks mean the from action in term 3, if term 3 is
true then only jump to next policy and if not then continue to the next
term(term 4) and that will be reject, correct me if I am wrong.
On Tue, May 4, 2010 at 8:43 AM, vvasi...@vvasilev.net wrote:
Hi David,
Here next policy means the default BGP policy which by default accepts
all BGP routes that pass sanity checks.
Vladi
Sent from my BlackBerry® wireless device
-Original Message-
From: David water dwater2...@gmail.com
Date: Tue, 4 May 2010 08:31:22
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] policy from JNCIP book
Hi,
I am trying to understand the policy in BGP, in JNCIP book we have
following
policy with term 1 to 3. Term 1 and 2 is rejecting all unwanted routes and
term 3 is matching those are originating in C1 and reference to the next
policy. So here next policy will be next term (term4) if so then it will be
rejected ? if it is pointing to other policy then it is not define then
will
it mach to the BGP default policy to accept all EBGP routes? Please help me
to understand. This policy is used in import at EBGP peer to accept the
selected route. Same way if I want to match customer prefix route, lets
say
1.1.1.0/24 then in term I will use route filter to match the prefix and
then
next-policy?
term 1 {
from {
route-filter 0.0.0.0/0 through 0.0.0.0/7 reject;
route-filter 0.0.0.0/1 prefix-length-range /1-/7 reject;
}
}
term 2 {
from {
route-filter 0.0.0.0/0 prefix-length-range /29-/32 reject;
route-filter 172.16.0.0/12 orlonger reject;
route-filter 192.168.0.0/16 orlonger reject;
route-filter 10.0.0.0/8 orlonger reject;
}
}
term 3 {
from as-path c1;
then next policy;
}
term 4 {
then reject;
}
--
David W.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
David W.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Basic BGP Questions
Hi folks. I'm having a hard time getting a 'stock configuration' done on JunOS for eBGP peering.. Been reading Juniper docs and keep circling back with more questions than answers ;) Could someone get me pointed in the right direction? . In Cisco, we do this: neighbor xxx.32.235.39 remote-as 12345 neighbor xxx.32.235.39 peer-group peering-exchangename neighbor xxx.32.235.39 description xx neighbor xxx.32.235.39 activate neighbor xxx.32.235.39 maximum-prefix 100 95 neighbor peering-exchangename peer-group neighbor peering-exchangename send-community neighbor peering-exchangename route-map inbound-exchangename in neighbor peering-exchangename route-map outbound-exchangename out route-map inbound-exchangename permit 10 set metric +110 set local-preference 200 set community 11666:2000 11666:2002 additive route-map outbound-exchangename permit 10 match community 100 set metric 110 I realize that there's quite a bit going on here - just need some samples of folks doing similar and I'll be off to the races. ;) Cheers, Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MPC-3D-16XGE-SFPP on MX960
Ahh now that makes sense. Yes the other card is a DPC card. In order to correct this, I'll have to migrate our connections the MPC card. Do you know if a reload is required or can I just pull the DPCs and online the MPC? Thanks, Michael On Tue, May 4, 2010 at 2:46 AM, Richard A Steenbergen r...@e-gerbil.net wrote: On Tue, May 04, 2010 at 02:25:16AM -0400, Michael Phung wrote: Hey Guys, We just tired installing a MPC-3D-16XGE-SFPP on a MX960 running 10.0R2.10 on slot 0 and got a error FPC 0 misconfigured. After this message, any attempt to online the FPC just fails with the same message again. The output of show chassis fpc shows the following; Temp CPU Utilization (%) Memory Utilization (%) Slot State (C) Total Interrupt DRAM (MB) Heap Buffer 0 Offline ---FPC misconfiguration--- 1 Online 28 12 0 1024 23 33 Anyone else encounter this problem before? This is occurring on 2 separate cards on different routers, so I don't think the cards are faulty. Is the other card in the chassis a trio card as well? You can't mix trio and non-trio cards until 10.2, and you can't run the MPC/MIC cards until 10.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] Basic BGP Questions
I tend to use groups (under [edit groups]) to create sections of
commonly-applied configurations. Very nice JUNOS feature. This might
be where you'd list elements that would apply to multiple BGP
neighbours (though groups can be used for ANY configuration elements
that you might want to reuse...not just BGP stuff). For example
(using arbitrary values, not necessarily yours):
[edit groups ebgp-peers]
protocols {
bgp {
group * {
type external;
log-updown;
import inbound-exchange;
export outbound-exchange;
family inet {
unicast {
prefix-limit {
maximum 128;
teardown idle-timeout 3;
}
}
}
remove-private;
}
}
}
The inbound-exchange and outbound-exchange are 'policy-statements',
defined at [edit policy-options policy-statement
your-policy-name-here] (as described here:
http://www.juniper.net/techpubs/en_US/junos9.6/information-products/topic-collections/config-guide-policy/frameset.html
)
so far though, nothing has been actually 'applied' to your bgp
neighbor. To apply the above config, list the above 'group' in the
neighbor configuration, something like:
[edit protocols bgp]
group arbitrary-name-here1 {
apply-groups ebgp-peers;
neighbour neighbour.ip.address
...
}
group arbitrary-name-here2 {
apply-groups ebgp-peers;
neighbour other.ip.address
...
...
}
and so on.
HTH,
DB
On 4 May 2010 08:16, Paul Stewart p...@paulstewart.org wrote:
Hi folks.
I'm having a hard time getting a 'stock configuration' done on JunOS for
eBGP peering.. Been reading Juniper docs and keep circling back with more
questions than answers ;)
Could someone get me pointed in the right direction? .
In Cisco, we do this:
neighbor xxx.32.235.39 remote-as 12345
neighbor xxx.32.235.39 peer-group peering-exchangename
neighbor xxx.32.235.39 description xx
neighbor xxx.32.235.39 activate
neighbor xxx.32.235.39 maximum-prefix 100 95
neighbor peering-exchangename peer-group
neighbor peering-exchangename send-community
neighbor peering-exchangename route-map inbound-exchangename in
neighbor peering-exchangename route-map outbound-exchangename out
route-map inbound-exchangename permit 10
set metric +110
set local-preference 200
set community 11666:2000 11666:2002 additive
route-map outbound-exchangename permit 10
match community 100
set metric 110
I realize that there's quite a bit going on here - just need some samples of
folks doing similar and I'll be off to the races.
;)
Cheers,
Paul
___
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] RPD event M20
Hello, I've just executed this comand on the shell and it appeared a lot of routes: r...@eg01% rtsockmon -t rpd sender flagtype op [17:30:29] rpd Proute add inet6 2401:ee00:: tid=2 plen=32 type=user flags=0x10 nh=indr nhflags=0x4 nhidx=262144 filtidx=0 [17:30:29] rpd Proute add inet6 2401:ee00:1c1c::2001:668 tid=0 plen=32 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=591 filtidx=0 [17:30:29] rpd Proute change inet6 2401:ee00:1c1c::2001:668 tid=2 plen=32 type=user flags=0x10 nh=indr nhflags=0x4 nhidx=262151 filtidx=0 [17:30:29] rpd Proute add inet6 2400:6800:1c1c::2001:668 tid=0 plen=32 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=591 filtidx=0 [17:30:29] rpd Proute add inet6 2400:6800:1c1c::2001:668 tid=2 plen=32 type=user flags=0x10 nh=indr nhflags=0x4 nhidx=262151 filtidx=0 [17:30:29] rpd Proute add inet6 2404:8000:f:0:1c1c:: tid=0 plen=48 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=591 filtidx=0 [17:30:29] rpd Proute add inet6 2404:8000:5:0:1c1c:: tid=0 plen=48 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=591 filtidx=0 [17:30:29] rpd Proute add inet6 2404:8000:c:0:1c1c:: tid=0 plen=48 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=591 filtidx=0 [...] [17:30:31] rpd Proute change inet 195.140.208.0 tid=0 plen=22 type=user flags=0x0 nh=indr nhflags=0x4 nhidx=262147 filtidx=0 [17:30:31] rpd Proute change inet 85.197.112.0 tid=0 plen=20 type=user flags=0x0 nh=indr nhflags=0x4 nhidx=262147 filtidx=0 [17:30:31] rpd Proute change inet 195.225.208.0 tid=0 plen=22 type=user flags=0x0 nh=indr nhflags=0x4 nhidx=262147 filtidx=0 [17:30:31] rpd Proute change inet 195.158.54.0 tid=0 plen=24 type=user flags=0x0 nh=indr nhflags=0x4 nhidx=262147 filtidx=0 [17:30:31] rpd Proute change inet 195.158.54.0 tid=2 plen=24 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=573 filtidx=0 [17:30:31] rpd Proute change inet 85.197.112.0 tid=2 plen=20 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=573 filtidx=0 [17:30:31] rpd Proute change inet 195.140.208.0 tid=2 plen=22 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=573 filtidx=0 [17:30:31] rpd Proute change inet 195.225.208.0 tid=2 plen=22 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=573 filtidx=0 [17:30:31] rpd Proute change inet 148.247.205.0 tid=2 plen=24 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=583 filtidx=0 [17:30:31] rpd Proute change inet 148.247.22.0 tid=2 plen=24 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=583 filtidx=0 [..] The output is very long ( I had to stopped after 3 minutes) and we don't know if that is normal o no. What should we do? Is it possible to clean this routes? Thanks a lot for your help, Matthew El 04/05/2010 15:14, Ihsan Junaidi Ibrahim escribió: you can check for persistent routing updates i.e. flaps by running rtsockmon -t rpd on the shell. On 4 May 2010 22:04, Juniper juni...@iber-x.com mailto:juni...@iber-x.com wrote: Hello there, This message has appeared in the log of our M20. It is not the first time it occurs and we are quite worried. The average CPU consumption is 4% and just at the time the message appeared on the log, we found increases up to 100% and an increase in temperature of 6 º in the routing-engine 0. This router works with two logical routers and receive full-routing of three different providers. We also have configured and IS-IS and IBGP sessions. May 4 11:43:03 xxx01.yyy2.abc-d.net http://xxx01.yyy2.abc-d.net LEV[2625]: RPD_SCHED_SLIP: 7 sec scheduler slip, user: 3 sec 306043 usec, system: 0 sec, 5732 usec We do not know what could be the problem because we have not detected any event bgp, routing update, addition of new machines, etc. Do you have any idea what may be the reason for this high cpu usage? Thanks in advance, Matthew ___ juniper-nsp mailing list juniper-nsp@puck.nether.net mailto:juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Thank you for your time, Ihsan Junaidi Ibrahim ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Basic BGP Questions
Chris David... thank you VERY much - this is exactly the info I needed
I can start working on configuration migrations now..;)
Appreciate it... cheers...
Paul
-Original Message-
From: David Ball [mailto:davidtb...@gmail.com]
Sent: Tuesday, May 04, 2010 10:59 AM
To: Paul Stewart
Cc: jnsp
Subject: Re: [j-nsp] Basic BGP Questions
I tend to use groups (under [edit groups]) to create sections of
commonly-applied configurations. Very nice JUNOS feature. This might
be where you'd list elements that would apply to multiple BGP
neighbours (though groups can be used for ANY configuration elements
that you might want to reuse...not just BGP stuff). For example
(using arbitrary values, not necessarily yours):
[edit groups ebgp-peers]
protocols {
bgp {
group * {
type external;
log-updown;
import inbound-exchange;
export outbound-exchange;
family inet {
unicast {
prefix-limit {
maximum 128;
teardown idle-timeout 3;
}
}
}
remove-private;
}
}
}
The inbound-exchange and outbound-exchange are 'policy-statements',
defined at [edit policy-options policy-statement
your-policy-name-here] (as described here:
http://www.juniper.net/techpubs/en_US/junos9.6/information-products/topic-co
llections/config-guide-policy/frameset.html
)
so far though, nothing has been actually 'applied' to your bgp
neighbor. To apply the above config, list the above 'group' in the
neighbor configuration, something like:
[edit protocols bgp]
group arbitrary-name-here1 {
apply-groups ebgp-peers;
neighbour neighbour.ip.address
...
}
group arbitrary-name-here2 {
apply-groups ebgp-peers;
neighbour other.ip.address
...
...
}
and so on.
HTH,
DB
On 4 May 2010 08:16, Paul Stewart p...@paulstewart.org wrote:
Hi folks.
I'm having a hard time getting a 'stock configuration' done on JunOS for
eBGP peering.. Been reading Juniper docs and keep circling back with more
questions than answers ;)
Could someone get me pointed in the right direction? .
In Cisco, we do this:
neighbor xxx.32.235.39 remote-as 12345
neighbor xxx.32.235.39 peer-group peering-exchangename
neighbor xxx.32.235.39 description xx
neighbor xxx.32.235.39 activate
neighbor xxx.32.235.39 maximum-prefix 100 95
neighbor peering-exchangename peer-group
neighbor peering-exchangename send-community
neighbor peering-exchangename route-map inbound-exchangename in
neighbor peering-exchangename route-map outbound-exchangename out
route-map inbound-exchangename permit 10
set metric +110
set local-preference 200
set community 11666:2000 11666:2002 additive
route-map outbound-exchangename permit 10
match community 100
set metric 110
I realize that there's quite a bit going on here - just need some samples
of
folks doing similar and I'll be off to the races.
;)
Cheers,
Paul
___
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] RPD event M20
Hi, In this router, we have configured 2 logical router. In the 'physical' we have only one provider (one full-routing) and in the logical one we are connected to 2 providers (2 full-routing). Are these events for both logical routers? They are differents providers, why should I configure always-compare-med? Although we have a redundance session BGP with one of these provider in other router in our AS. Would you recommend us to use this sentence in the configurations? We are not sure because we have implemented to filter the routes 'communities' and 'local-preferences' but we don't use always-compare-med. These configuration is applied since a lot of years, almost 5 years and we never had these events in our log. My apologies about asking you so many questions but we never had these type of logs in our Juniper M20 and we have to understand first to apply this parameter in our configuration. Thanks a lot for your time, Matthew El 04/05/2010 17:10, Ihsan Junaidi Ibrahim escribió: Looks like there's a persistent oscillation in your routing topology. If you see routes i.e. 195.240.208.0 that comes from different peer ASes, you might want to configure always-compare-med in your bgp path-selection statement. By default, it will only compare routes that come from the same peer AS. On 4 May 2010 23:54, Juniper juni...@iber-x.com mailto:juni...@iber-x.com wrote: Hello, I've just executed this comand on the shell and it appeared a lot of routes: r...@eg01% rtsockmon -t rpd sender flagtype op [17:30:29] rpd Proute add inet6 2401:ee00:: tid=2 plen=32 type=user flags=0x10 nh=indr nhflags=0x4 nhidx=262144 filtidx=0 [17:30:29] rpd Proute add inet6 2401:ee00:1c1c::2001:668 tid=0 plen=32 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=591 filtidx=0 [17:30:29] rpd Proute change inet6 2401:ee00:1c1c::2001:668 tid=2 plen=32 type=user flags=0x10 nh=indr nhflags=0x4 nhidx=262151 filtidx=0 [17:30:29] rpd Proute add inet6 2400:6800:1c1c::2001:668 tid=0 plen=32 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=591 filtidx=0 [17:30:29] rpd Proute add inet6 2400:6800:1c1c::2001:668 tid=2 plen=32 type=user flags=0x10 nh=indr nhflags=0x4 nhidx=262151 filtidx=0 [17:30:29] rpd Proute add inet6 2404:8000:f:0:1c1c:: tid=0 plen=48 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=591 filtidx=0 [17:30:29] rpd Proute add inet6 2404:8000:5:0:1c1c:: tid=0 plen=48 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=591 filtidx=0 [17:30:29] rpd Proute add inet6 2404:8000:c:0:1c1c:: tid=0 plen=48 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=591 filtidx=0 [...] [17:30:31] rpd Proute change inet 195.140.208.0 tid=0 plen=22 type=user flags=0x0 nh=indr nhflags=0x4 nhidx=262147 filtidx=0 [17:30:31] rpd Proute change inet 85.197.112.0 tid=0 plen=20 type=user flags=0x0 nh=indr nhflags=0x4 nhidx=262147 filtidx=0 [17:30:31] rpd Proute change inet 195.225.208.0 tid=0 plen=22 type=user flags=0x0 nh=indr nhflags=0x4 nhidx=262147 filtidx=0 [17:30:31] rpd Proute change inet 195.158.54.0 tid=0 plen=24 type=user flags=0x0 nh=indr nhflags=0x4 nhidx=262147 filtidx=0 [17:30:31] rpd Proute change inet 195.158.54.0 tid=2 plen=24 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=573 filtidx=0 [17:30:31] rpd Proute change inet 85.197.112.0 tid=2 plen=20 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=573 filtidx=0 [17:30:31] rpd Proute change inet 195.140.208.0 tid=2 plen=22 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=573 filtidx=0 [17:30:31] rpd Proute change inet 195.225.208.0 tid=2 plen=22 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=573 filtidx=0 [17:30:31] rpd Proute change inet 148.247.205.0 tid=2 plen=24 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=583 filtidx=0 [17:30:31] rpd Proute change inet 148.247.22.0 tid=2 plen=24 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=583 filtidx=0 [..] The output is very long ( I had to stopped after 3 minutes) and we don't know if that is normal o no. What should we do? Is it possible to clean this routes? Thanks a lot for your help, Matthew El 04/05/2010 15:14, Ihsan Junaidi Ibrahim escribió: you can check for persistent routing updates i.e. flaps by running rtsockmon -t rpd on the shell. On 4 May 2010 22:04, Juniper juni...@iber-x.com mailto:juni...@iber-x.com wrote: Hello there, This message has appeared in the log of our M20. It is not the first time it occurs and we are quite worried. The
Re: [j-nsp] Understanding DPC Cards
I don't have time to get all of it but very quickly the command you mentioned:
set chassis network-services ip;
refers to if you want this MX to be a L2 or L3 box. Changing this
requires a reset AFAIK. When in network-services ethernet mode you
can only use the DPC-X cards which are priced cheaper and have limited
L3 functionality. Chances are you want to keep this in IP mode since
you are using an R card (I assume they are both R cards, and not X
cards).
Also, comparing EX vs MX configs should be viewed like comparing cisco
ios to ios-xr. AFAIK, these are separate codebases. You need to
compare to J, T, or M series configs.
-J Scott
On Tue, May 4, 2010 at 2:05 PM, Paul Stewart p...@paulstewart.org wrote:
Hi there..
I'm not sure if I'm asking this right . again, as I mentioned earlier - I'm
a Cisco guy jumping into the JunOS world so pardon me if I've missed this
somewhere in the docs. my translation between the two worlds is slow but
steady..
Working on an MX480 that has a pair of DPC cards (DPCE 20x 1GE + 2x 10GE R).
Some questions ;)
Can someone give me in simple terms what the differences are between
chassis network-services Ethernet and chassis network-services IP?
Secondly, on EX switches (which I'm just getting used too) we can do:
ge-0/0/12 {
description xxx;
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ ]
On the MX it seems this is quite different? I have the following:
ge-5/0/2 {
description ;
vlan-tagging;
encapsulation flexible-ethernet-services;
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list 61;
}
}
I'm sure this isn't correct J This is what I created after reading some of
the Juniper docs with a lack of understanding what
flexible-ethernet-services actually refers too..
My goal is to have a dot1q trunk come in with a dozen or so VLAN's on it and
then create layer3 RVI's for them. The RVI configuration I have is this
(which again I know is wrong):
vlan {
unit 61 {
family inet {
address xxx.xx.235.34/24;
}
family inet6 {
address xxx:xxx:235::34/64;
}
}
Any assistance is much appreciated - thanks again to those folks who helped
earlier with my BGP questions.
Paul
___
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] Understanding DPC Cards
I'll try to help... We also run MX and EX.
So, first off. MX and EX are not even remotely related in respect to
what they can and can not do. The MX is a L3 box with L2 capabilities,
the EX is a L2 box with L3 capabilities.
So, vlans in an MX are not global (at least not necessarily). This means
you can have the same vlan id on different ports without them being the
same service (this may be a bit unclear, I apologize if that is the case)
Encapsulation flexible-ethernet-services gives you the opportunity to
use different encapsulation on different units (i.e vlan, mpls, vpls and
so forth).
vlan-tagging enables support for reception of singel tagged ethernet
frames. If you want double-tagged it's stacked-vlan-tagging or if you
want the option of doing both on the same physical port it's
flexible-vlan-tagging.
If you intend solely to terminate a vlan in a L3 interface you would
simply state it like this.
ge-0/0/0 {
encapsulation flexible-ethernet-services;
vlan-tagging;
unit 0 {
vlan-id z;
family inet {
address xx.xx.xx.xx/yy;
}
}
If you want the option of bridging several interfaces together and
simultaneously have a routable interface enabled it get's a bit more
complicated. Basicly you have to set up a bridge-domain and then an
routing-interface (interface irb) on it.
//Martin
On 2010-05-04 23:05, Paul Stewart wrote:
Hi there..
I'm not sure if I'm asking this right . again, as I mentioned earlier - I'm
a Cisco guy jumping into the JunOS world so pardon me if I've missed this
somewhere in the docs. my translation between the two worlds is slow but
steady..
Working on an MX480 that has a pair of DPC cards (DPCE 20x 1GE + 2x 10GE R).
Some questions ;)
Can someone give me in simple terms what the differences are between
chassis network-services Ethernet and chassis network-services IP?
Secondly, on EX switches (which I'm just getting used too) we can do:
ge-0/0/12 {
description xxx;
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ ]
On the MX it seems this is quite different? I have the following:
ge-5/0/2 {
description ;
vlan-tagging;
encapsulation flexible-ethernet-services;
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list 61;
}
}
I'm sure this isn't correct J This is what I created after reading some of
the Juniper docs with a lack of understanding what
flexible-ethernet-services actually refers too..
My goal is to have a dot1q trunk come in with a dozen or so VLAN's on it and
then create layer3 RVI's for them. The RVI configuration I have is this
(which again I know is wrong):
vlan {
unit 61 {
family inet {
address xxx.xx.235.34/24;
}
family inet6 {
address xxx:xxx:235::34/64;
}
}
Any assistance is much appreciated - thanks again to those folks who helped
earlier with my BGP questions.
Paul
___
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] Understanding DPC Cards
On Tue, May 04, 2010 at 05:05:04PM -0400, Paul Stewart wrote: Can someone give me in simple terms what the differences are between chassis network-services Ethernet and chassis network-services IP? When Juniper came out with the MX they had two large potential customer bases with two different uses for the platform, and wanted to create a differentiated price point so they could compete with both groups. To do this, they made a chassis network-services mode, and sold a -X and -R version of the same card at different prices. If you configure network-services ethernet both -X and -R cards will work, but if you configure network-services ip any -X cards in the chassis will shut down. The ethernet mode lets you use the box for L2, or have just enough IP to use as a signaling for l3vpns, but not enough IP to do actual routing (i.e. bgp will not exchange inet/unicast afi/safi's, etc). If you want to do full routing, you need the -R cards, and you need to configure the chassis for network-services ip. On the MX it seems this is quite different? I have the following: IMHO using an MX for L2 is blasphemy, and you should have your head examined if you actually want to use it this way. This is the networking version of buying a GT-R and then only driving it on sundays down 25mph side streets. :) I'm sure this isn't correct J This is what I created after reading some of the Juniper docs with a lack of understanding what flexible-ethernet-services actually refers too.. Flexible ethernet services is a mode that lets you mix and match multiple types of L2 and L3 encapsulations under a single physical interface, in any way you'd like. This is different from earlier generations of Juniper hardware, which had very specific requirements and restricted ranges of what you could configure. For example, back in the day if you wanted to have one subinterface do family inet and another subinterface do vlan-ccc (say for example as an l2circuit endpoint), you had to do the ip on vlan IDs 512 and the vlan-ccc on vlan IDs 512-1024. With flexible ethernet services you can do it however you'd like. That it is even a configuration option at all and not just default is a holdover from the days when it wasn't supported on every kind of interface. All MX interfaces support it now, so it's probably what you want to use if for no other reason than it saves you a flap if you ever need to turn it on later. -- 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] Understanding DPC Cards
On MX, you can create access-ports connected to the hosts using
interface-mode access with a unique vlan id assigned to the port. This is
conceptually similar to switchport mode access on Cisco.
With either interface-mode access you do not need to explicitly assign the
logical unit to the bridge-domain. It automatically gets assigned to the
bridge-domain configured with same vlan-id. For.e.g.
[edit]
l...@re0-mx960# show interfaces ge-1/1/1
unit 0 {
family bridge {
interface-mode access;
vlan-id 61;
}
}
[edit]
l...@re0-mx960# show bridge-domains vlan-61
domain-type bridge;
vlan-id 61;
[edit]
l...@re0-mx960#
With this configuration, ge-1/1/1.0 is automatically part of bridge domain
vlan-61. Now if you want to enable routing on this bridge (RVI in Cisco),
you can configure IRB interface and assign this irb logical unit to this
bridge-domain.
[edit]
l...@re0-mx960# show interfaces irb unit 61
family inet {
address 1.2.3.4/24;
}
[edit]
l...@re0-mx960#
[edit]
l...@re0-mx960# show bridge-domains vlan-61
domain-type bridge;
vlan-id 61;
routing-interface irb.61;
[edit]
l...@re0-mx960#
[edit]
l...@re0-mx960# run show bridge domain bridge-domain vlan-61
Routing instanceBridge domainVLAN ID Interfaces
default-switch vlan-61 61
ge-1/1/1.0
[edit]
l...@re0-mx960#
If you add more interfaces to vlan 61 as access ports, they will get
assigned to the same bridge-domain. It will do a switching between the ports
in the same bridge-domain and will do routing to destinations outside
bridge-domain via irb interface.
When you create a trunk carrying the same vlan id 61, it will also become
part of the same bridge domain.
[edit]
l...@re0-mx960# show interfaces ge-1/1/2
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list [ 61 62 ];
}
}
[edit]
l...@re0-mx960#
[edit]
l...@re0-mx960# run show bridge domain bridge-domain vlan-61
Routing instanceBridge domainVLAN ID Interfaces
default-switch vlan-61 61
ge-1/1/1.0
ge-1/1/2.0
[edit]
l...@re0-mx960#
You will need a bridge-domain configuration for the vlan-ids configured on
the trunk port to instantiate the switching of that vlans in the forwarding
table. In the above configuration, vlan id 62 does not yet have the
bridge-domain associated with it, so the trunk is not yet enabled to carry
its traffic.
[edit]
l...@re0-mx960# run show bridge domain bridge-domain vlan-62
[edit]
l...@re0-mx960# set bridge-domains vlan-62 domain-type bridge
[edit]
l...@re0-mx960# set bridge-domains vlan-62 vlan-id 62
[edit]
l...@re0-mx960# commit
commit complete
[edit]
l...@re0-mx960# run show bridge domain bridge-domain vlan-62
Routing instanceBridge domainVLAN ID Interfaces
default-switch vlan-62 62
ge-1/1/2.0
[edit]
l...@re0-mx960#
An access port can technically receive both tagged and untagged packets from
the host but it will only send untagged packets to the host connected to
port. A tagged port can send and receive only tagged packets. You can
configure a tagged port with a native-vlan-id for it enable receiving
untagged packets. It is somewhat similar to Cisco, where all untagged
traffic is assigned to vlan 1 by default and can be configured to a
different vlan if needed. When you configure native-vlan-id, all the
untagged traffic is treated as being received over the vlan configured as
native vlan.
[edit]
l...@re0-mx960# show interfaces ge-1/1/2
native-vlan-id 62;
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list [ 61 62 ];
}
}
[edit]
l...@re0-mx960#
Hope this helps. I have seen other replies providing the information about
XDPC and RDPCs as well as flexible-ethernet-services so do not want to
repeat it here.
Thanks,
Nilesh.
On 5/4/10 4:01 PM, Martin Levin martin.le...@molndal.se wrote:
I'll try to help... We also run MX and EX.
So, first off. MX and EX are not even remotely related in respect to
what they can and can not do. The MX is a L3 box with L2 capabilities,
the EX is a L2 box with L3 capabilities.
So, vlans in an MX are not global (at least not necessarily). This means
you can have the same vlan id on different ports without them being the
same service (this may be a bit unclear, I apologize if that is the case)
Encapsulation flexible-ethernet-services gives you the opportunity to
use different encapsulation on different units (i.e vlan, mpls, vpls and
so forth).
vlan-tagging enables support for reception of singel tagged ethernet
frames. If you want double-tagged it's stacked-vlan-tagging or if you
want the option of doing both on the
