[j-nsp] VLAN aware EVPN service
Hi all, Is it possible to send untagged frames across MPLS backbone while using VLAN aware EVPN service? I could not find any command such as pop/push while using family bridge which is required to configure since I use instance-type virtual-switch due to the type of EVPN service? If there is no option, do I have to use instance-type evpn then? And do VLAN-aware and VLAN-aware bundle definitions in Juniper have different meanings? Thanks in advance. Gokhan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper BFD session with Huawei
Hi Krzysztof,
I am using MX router with version 15.1F6-S5.6 and the options you referred
are not existing in the software :(
[edit protocols mpls label-switched-path Juniper-Huawei]
Juniper# set oam bfd-liveness-detection ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> detection-time Detection-time options
> failure-action Action to take when BFD session goes down
minimum-interval Minimum transmit and receive interval (1..255000
milliseconds)
minimum-receive-interval Minimum receive interval (1..255000
milliseconds)
multiplier Detection time multiplier (1..255)
no-adaptationDisable adaptation
> transmit-intervalTransmit-interval options
version BFD protocol version number
Regards,
Gokhan
On Sun, May 28, 2017 at 8:21 AM, Krzysztof Grzegorz Szarkowicz <
kszarkow...@gmail.com> wrote:
> Hi,
>
> Please check following knobs:
>
> *no-router-alert-option*
> *use-ip-ttl-1*
> *bfd-port*
>
> root@PE1# set protocols mpls label-switched-path PE1-->PE4 primary PATH-1
> oam bfd-liveness-detection ?
> W21: Sat 2017-05-27T10:12:07 PDT (UTC-0700)
> Possible completions:
> + apply-groups Groups from which to inherit configuration data
> + apply-groups-except Don't inherit configuration data from these groups
> > detection-time Detection-time options
> > failure-action Action to take when BFD session goes down
> minimum-interval Minimum transmit and receive interval (1..255000
> milliseconds)
> minimum-receive-interval Minimum receive interval (1..255000
> milliseconds)
> multiplier Detection time multiplier (1..255)
> no-adaptationDisable adaptation
> * no-router-alert-option Do not set Router-Alert options in IP header
> for MPLS-BFD. <=*
> > transmit-intervalTransmit-interval options
> *use-ip-ttl-1 Set TTL value to 1 in IP header for MPLS-BFD
><=*
> version BFD protocol version number
>
> root@PE1# set protocols mpls label-switched-path PE1-->PE4 primary PATH-1
> oam bfd-port ?
> W21: Sat 2017-05-27T10:30:34 PDT (UTC-0700)
> Possible completions:
> + apply-groups Groups from which to inherit configuration data
> + apply-groups-except Don't inherit configuration data from these groups
> + import Import policy
>
> — Krzysztof
>
> On 2017-May-26, at 16:52, Gökhan Gümüş wrote:
>
> Hi Steinar,
>
> Thanks for reply. Actually, i have been looking for BFD at MPLS LSP level
> instead of ISIS level.
> Are you using BFD at LSP level between Juniper and Huawei?
>
> Kind regards,
> Gokhan
>
> On Fri, May 26, 2017 at 2:39 PM, wrote:
>
> I am trying to establish a RSVP-OAM between a Juniper and Huawei device.
>
>
> Possibly not directly relevant to your case - but we have lots of BFD
> sessions for IS-IS between Juniper and Huawei. Nothing special, it
> just works. Lightly edited example below.
>
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
>
> --
>
> ar1.xxx> show configuration interfaces xe-10/0/2
> mtu 9114;
> unit 0 {
>family inet {
>address 10.1.1.87/31;
>}
>family iso;
>family mpls;
> }
>
> ar1.xxx> show configuration protocols isis interface xe-10/0/2.0
> ldp-synchronization {
>hold-time 600;
> }
> point-to-point;
> bfd-liveness-detection {
>minimum-interval 50;
>multiplier 3;
> }
>
> interface GigabitEthernet0/1/0
> mtu 9100
> undo shutdown
> ip address 10.1.1.86 255.255.255.254
> isis enable 1
> isis circuit-type p2p
> isis circuit-level level-2
> isis ldp-sync
> isis bfd enable
> isis bfd min-tx-interval 50 min-rx-interval 50
> mpls
> mpls te
> mpls rsvp-te
> mpls ldp
>
> ___
> 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 BFD session with Huawei
Hi Steinar,
Thanks for reply. Actually, i have been looking for BFD at MPLS LSP level
instead of ISIS level.
Are you using BFD at LSP level between Juniper and Huawei?
Kind regards,
Gokhan
On Fri, May 26, 2017 at 2:39 PM, wrote:
> > I am trying to establish a RSVP-OAM between a Juniper and Huawei device.
>
> Possibly not directly relevant to your case - but we have lots of BFD
> sessions for IS-IS between Juniper and Huawei. Nothing special, it
> just works. Lightly edited example below.
>
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
>
> --
>
> ar1.xxx> show configuration interfaces xe-10/0/2
> mtu 9114;
> unit 0 {
> family inet {
> address 10.1.1.87/31;
> }
> family iso;
> family mpls;
> }
>
> ar1.xxx> show configuration protocols isis interface xe-10/0/2.0
> ldp-synchronization {
> hold-time 600;
> }
> point-to-point;
> bfd-liveness-detection {
> minimum-interval 50;
> multiplier 3;
> }
>
> interface GigabitEthernet0/1/0
> mtu 9100
> undo shutdown
> ip address 10.1.1.86 255.255.255.254
> isis enable 1
> isis circuit-type p2p
> isis circuit-level level-2
> isis ldp-sync
> isis bfd enable
> isis bfd min-tx-interval 50 min-rx-interval 50
> mpls
> mpls te
> mpls rsvp-te
> mpls ldp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Juniper BFD session with Huawei
Dear group, I am trying to establish a RSVP-OAM between a Juniper and Huawei device. set protocols mpls label-switched-path Juniper-Huawei oam bfd-liveness-detection minimum-interval 100 set protocols mpls label-switched-path Juniper-Huawei oam bfd-liveness-detection multiplier 3 set protocols mpls label-switched-path Juniper-Huawei oam bfd-liveness-detection failure-action make-before-break teardown-timeout 10 set protocols mpls label-switched-path Juniper-Huawei link-protection set protocols mpls label-switched-path Juniper-Huawei adaptive set protocols mpls label-switched-path Juniper-Huawei to 1.1.1.2 Address State Interface Time Interval Multiplier 127.0.0.1Down ae9.0 0.000 2.0003 Client RSVP-OAM, TX interval 0.100, RX interval 0.100 Local diagnostic None, remote diagnostic None Remote state AdminDown, version 1 Session type: Multi hop BFD Min async interval 0.100, min slow interval 2.000 Adaptive async TX interval 2.000, RX interval 2.000 Local min TX interval 2.000, minimum RX interval 0.100, multiplier 3 Remote min TX interval 0.000, min RX interval 0.000, multiplier 0 Local discriminator 29, remote discriminator 0 Echo mode disabled/inactive, no-absorb, no-refresh LSP-Name Juniper-Huawei Session ID: 0x0 As Juniper is using 127.0.0.1 as a source address, it is not possible Huawei to understand this. Is there anyone who has an experience with MPLS OAM configuration between Juniper and other vendors like Cisco and Huawei? Is it possible to bring the session up from Juniper towards other vendors? Kind regards, Gokhan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interface
Thanks for the replies. I do not have any CoS configuration on my router. There is no Spanning-Tree is running between my device and customer device. I have no idea what is causing an increment in the network-control queue. Any ideas would be appreciated. Thanks and regards, Gokhan On Thu, Jan 26, 2012 at 4:52 PM, Keegan Holley wrote: > Well NC (network control) is a completely different queue than EF > (expedited forwarding). This could be normal. Several things such as > routing protocol updates are set to NC by default because it is > network control traffic or part of the network control plane. Such > traffic should be prioritized during congestion to keep the paths > stable. I wouldn't use the NC queue for other traffic if you can > avoid it and I wouldn't make this traffic best effort without figuring > out what it is. Is it possible that it's just a control protocol? I > know most routing protocols mark their hello's as NC. Spanning tree > BPDU's might do the same but I can't remember off the top of my head. > > > 2012/1/26 Gökhan Gümüş : > > Dear Saku, > > > > Thanks for the reply. > > > > I checked the queues on the interface as seen below; > > > > LON> show class-of-service interface ge-2/0/4 > > Physical interface: ge-2/0/4, Index: 158 > > Queues supported: 8, Queues in use: 4 > > Scheduler map: , Index: 2 > > > > Logical interface: ge-2/0/4.0, Index: 216 > > > > How can i use %100 BE by changing my config in Juniper? > > > > Thanks and regards, > > Gokhan > > ___ > > 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] Network-control queue counter increases on ccc-configured interface
Dear Saku, For note, i have not got any qos configuration on my router. Kind regards, Gokhan On Thu, Jan 26, 2012 at 4:15 PM, Gökhan Gümüş wrote: > Dear Saku, > > Thanks for the reply. > > I checked the queues on the interface as seen below; > > LON> show class-of-service interface ge-2/0/4 > Physical interface: ge-2/0/4, Index: 158 > Queues supported: 8, Queues in use: 4 > Scheduler map: , Index: 2 > > Logical interface: ge-2/0/4.0, Index: 216 > > How can i use %100 BE by changing my config in Juniper? > > Thanks and regards, > Gokhan > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Network-control queue counter increases on ccc-configured interface
Dear Saku, Thanks for the reply. I checked the queues on the interface as seen below; LON> show class-of-service interface ge-2/0/4 Physical interface: ge-2/0/4, Index: 158 Queues supported: 8, Queues in use: 4 Scheduler map: , Index: 2 Logical interface: ge-2/0/4.0, Index: 216 How can i use %100 BE by changing my config in Juniper? Thanks and regards, Gokhan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Network-control queue counter increases on ccc-configured interface
Dear all,
I have detected a strange behaviour on one of our ccc-configured gigabit
ethernet interface.
I have a P2P ccc service and at one end strangely network-control queue
counter is increasing as seen below.
There is no other ccc-configured service on the router is getting increment
on their network-control queue.
LON> show configuration interfaces ge-2/0/4
apply-groups customer-template;
description "Customer-A";
gigether-options {
no-flow-control;
}
unit 0 {
family ccc {
policer {
input 200m-bw-limit;
output 200m-bw-limit;
}
LON> show configuration groups customer-template
interfaces {
<*> {
mtu 9188;
encapsulation ethernet-ccc;
unit 0 {
family ccc;
}
}
Queue counters: Queued packets Transmitted packets Dropped
packets
0 best-effort 2674026389
26740263910
1 expedited-fo 0
00
2 assured-forw 0
00
3 network-cont 832
8320
Is there anybody has such experience on Juniper MX switches?
Thanks and regards,
Gokhan Gumus
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Frame loss during Ethernet test
Dear Tim, Thanks for the information. Routers are MX and software version is same at both end which is 10.0R4.7 I also checked the syslog messages and saw only repeated cosmetic messages as follows; Jan 24 12:18:12 lon01 /kernel: PCF8584(WR): busy at start, attempting to clear Jan 24 12:18:12 lon01 /kernel: PCF8584(WR): (i2c_s1=0x08, group=0xf, device=0x54) Jan 24 12:26:02 lon01 /kernel: PCF8584(WR): transmit failure on byte 1 Jan 24 12:26:02 lon01 /kernel: PCF8584(WR): (i2c_s1=0x00, group=0xf, device=0x54) Jan 24 12:32:33 lon01 /kernel: PCF8584(RD): ack failure on 2nd last byte Jan 24 12:32:33 lon01 /kernel: PCF8584(RD): (i2c_s1=0x80, group=0xe, device=0x54) Jan 24 12:32:33 lon01 /kernel: PCF8584(WR): busy at start, attempting to clear Could there be a bug also in this software which causes those frame loss? Also, i have one question. Even if we see frame loss during test, could it be possible to use the circuit in production without any problem? Thanks and regards, Gokhan Gumus On Tue, Jan 24, 2012 at 2:13 PM, Tim Jackson wrote: > This isn't running on an MPC carded MX running 10.2 code is it? > > There was a bug that bit us that had some random small bits of frame > loss on CCC circuits on MX80 on 10.2.. I can't recall the bug ID, but > it was fixed in 10.4R6.. If I remember right, check your logs and > you'll see some parity errors scrolling through when there is frame > loss. > > -- > Tim > > On Tue, Jan 24, 2012 at 4:03 AM, Gökhan Gümüş wrote: > > Dear all, > > > > One of our customer complaining a small amount of frame loss on their > > service. > > I see that lost packets when i compare input and output statistics on the > > interface. > > We are terminating service with ccc configuration. > > At remote end, we have a hardware loop and customer connects its tester > to > > A-end sends traffic. > > When we run the test for 2-3 mins, we have no frame loss but at longer > test > > we start to see 10-20 frame loss. > > Frames are lost when our PE puts sent test traffic into corrresponding > LSP > > but there is no issue in our LSP. > > > > I do not know the exact principle of these testers but i checked all the > > possible reasons which may cause frame loss > > Delay, errors on the line, oversubscription, etc...None of them is an > issue > > during test. > > > > Is there anybody who has such an experience with Ethernet testers? > > > > Thanks and regards, > > Gokhan > > ___ > > 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] Frame loss during Ethernet test
Dear all, One of our customer complaining a small amount of frame loss on their service. I see that lost packets when i compare input and output statistics on the interface. We are terminating service with ccc configuration. At remote end, we have a hardware loop and customer connects its tester to A-end sends traffic. When we run the test for 2-3 mins, we have no frame loss but at longer test we start to see 10-20 frame loss. Frames are lost when our PE puts sent test traffic into corrresponding LSP but there is no issue in our LSP. I do not know the exact principle of these testers but i checked all the possible reasons which may cause frame loss Delay, errors on the line, oversubscription, etc...None of them is an issue during test. Is there anybody who has such an experience with Ethernet testers? Thanks and regards, Gokhan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Tagged frames can not be tranmistted
Dear community,
I need your assistance on one case.
We deliver a Layer 2 service to one of our customer within our MPLS
backbone by configuring it dot1q tunnel.
Customer wants to use this service as a trunk between between their HP
Procurve switches to tranmit multiple VLANs over it and across our MPLS
backbone.
The problem is customer can only transmit multiple VLAN traffic when they
use "native-vlan".
Consequently, customer can not send any VLAN traffic when they tag the
frame.With native-vlan, they can.
I think that i should change configuration on Juniper MX routers by
enabling VLAN stacking but i do not know what i should do exactly.
Is there anybody who can help me? If there is a sample config, that would
be great.
Please see the topology and configs below;
Customer
Switch
Customer Switch
|
|
|
|
|Fa3/13
| Gi0/5
Service Provider Switch-A
Service Provider Switch-B
| gi5/13
| gi0/27
|
|
| ge-2/3/3
| ge-2/2/2
Juniper MX Router-A
-MPLS cloud
Juniper Mx Router-B
*Configs are;*
Juniper MX-A router
Juniper MX-A router> show configuration interfaces ge-2/3/3
flexible-vlan-tagging;
mtu 1998;
encapsulation flexible-ethernet-services;
gigether-options {
no-auto-negotiation;
unit 1106 {
description "[Customer-VLAN1106]";
encapsulation vlan-ccc;
vlan-id 1106;
family ccc;
Service Provider Switch-A#sh run interface gi5/13
Building configuration...
Current configuration : 298 bytes
!
interface GigabitEthernet5/13
mtu 2000
load-interval 30
speed nonegotiate
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1101,1102,1106
switchport mode trunk
no cdp enable
end
Service Provider Switch-A#sh run interface fa3/13
Building configuration...
Current configuration : 366 bytes
!
interface FastEthernet3/13
description[Customer-VLAN1106]
mtu 2000
load-interval 60
switchport
switchport access vlan 1106
switchport mode dot1q-tunnel
switchport nonegotiate
l2protocol-tunnel cdp
l2protocol-tunnel stp
l2protocol-tunnel vtp
no cdp enable
spanning-tree bpdufilter enable
end
Juniper MX-Router-B> show configuration interfaces ge-2/2/2
flexible-vlan-tagging;
mtu 1998;
encapsulation flexible-ethernet-services;
gigether-options {
no-auto-negotiation;
unit 1106 {
description "[Customer VLAN-1106]";
encapsulation vlan-ccc;
vlan-id 1106;
family ccc;
Service Provider Switch-B #sh running-config interface gi0/27
Building configuration...
Current configuration : 251 bytes
!
interface GigabitEthernet0/27
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,9,1101,1102,1106
switchport mode trunk
switchport nonegotiate
end
Service Provider Switch-B#sh running-config interface gi0/5
Building configuration...
Current configuration : 337 bytes
!
interface GigabitEthernet0/5
description [Customer VLAN-1106]
switchport access vlan 1106
switchport mode dot1q-tunnel
switchport nonegotiate
load-interval 60
speed 100
duplex full
l2protocol-tunnel cdp
l2protocol-tunnel stp
l2protocol-tunnel vtp
no cdp enable
end
Thanks and regards,
Gokhan
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Regarding JUNOS SPACE
Dear Diogo, Service Now.. We have demo version without additional features. Honestly, i do not see any beneficial point inside of it. Am i missing something ? Thanks and regards, Gokhan 2011/11/28 Diogo Montagner > Hi Gokhan, > > Which application of Junos Space are you referring ? > > For example, the Service Now has a very good eLearning available on > Juniper website. > > For Junos Space itself, I don't think there is. But you probably will > find some eLearnings related to the Junos Space SDK. > > Thanks > > On 11/29/11, Gökhan Gümüş wrote: > > Dear Community, > > > > We have recently installed Junos Space with version 11.2. > > I have had a chance to have a look at Junos Space Web Gui to give some > > briefing to our NOC. > > But i could not find any documentation which explains Junos Space basicly > > and simply.( Power point presentation would be great ) > > > > Is there anybody who can provide a good document which explains Junos > space > > basically? > > > > Thanks and regards, > > Gokhan Gumus > > ___ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > -- > Sent from my mobile device > > ./diogo -montagner > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Regarding JUNOS SPACE
Dear Community, We have recently installed Junos Space with version 11.2. I have had a chance to have a look at Junos Space Web Gui to give some briefing to our NOC. But i could not find any documentation which explains Junos Space basicly and simply.( Power point presentation would be great ) Is there anybody who can provide a good document which explains Junos space basically? Thanks and regards, Gokhan Gumus ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IPv6 MTU issue
Thanks Alex.
Let me give a shot on this.
Gokhan
On Fri, Oct 21, 2011 at 2:00 PM, Alex wrote:
> **
> It should, in my view.
> Rgds
> Alex
>
> - Original Message -
> *From:* Gökhan Gümüş
> *To:* Alex
> *Cc:* juniper-nsp@puck.nether.net
> *Sent:* Friday, October 21, 2011 12:57 PM
> *Subject:* Re: [j-nsp] IPv6 MTU issue
>
> Dear Alex,
>
> Thanks for the response.
> Yes, you are right.
> This service is configured on MX on logical router.
> There is an aggregated interface is trunked to a switch as seen below,
>
> abc> show configuration logical-systems tcr1 interfaces ae2.39
> vlan-id 39;
> family inet {
> address a.b.c.d/30;
> }
> family inet6 {
> address /124;
>
> Do you think that just to increase INET6 MTU to 1504 bytes resolves this
> issue?
>
> Thanks,
> Gokhan
>
>
> On Fri, Oct 21, 2011 at 1:51 PM, Alex wrote:
>
>> My wild guess is that you are hitting a network of FreBSD/Olive/Linux IPv6
>> routers with certain cards where when 802.1Q is enabled, MTU is
>> automatically reduced by 4 bytes.
>> You can simulate it with Olive by enabling "vlan-tagging" on Intel PRO/100
>> card.
>> My $0.02
>> Thanks
>> Alex
>>
>>
>> - Original Message - From: "Gökhan Gümüs"
>> To:
>> Sent: Friday, October 21, 2011 11:25 AM
>> Subject: [j-nsp] IPv6 MTU issue
>>
>>
>> Dear all,
>>>
>>> I have an issue with IPv6 MTU.
>>>
>>> When i make a traceroute to one destination, the MTU size is reduced from
>>> 1500 to 1496, somehow...?
>>>
>>> What makes it worse is that hop which drops the MTU does not send ICMP
>>> "packet too long" message back..
>>>
>>> gg# scamper -I "trace -P udp -M abc
>>> traceroute from xxx to abc
>>> 1 s 0.192 ms [mtu: 1500]
>>> 2 d 0.356 ms [mtu: 1500]
>>> *3 f 1.422 ms [mtu: 1500]*
>>> * 4 g 1.107 ms [*mtu: 1496]*
>>>
>>> 5 h 1.145 ms [*mtu: 1496]
>>>
>>>
>>> On the link where MTU drops, output is as follows,
>>>
>>> Protocol inet, MTU: 1500
>>>
>>> Protocol inet6, MTU: 1500
>>>
>>>
>>>
>>> Software version is 10.0R4.7.
>>>
>>>
>>>
>>> Anybody has an experience on this behaviour before.
>>>
>>>
>>>
>>> Thanks and regards,
>>>
>>> Gokhan
>>> __**_
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/**mailman/listinfo/juniper-nsp<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] IPv6 MTU issue
Dear Alex,
Thanks for the response.
Yes, you are right.
This service is configured on MX on logical router.
There is an aggregated interface is trunked to a switch as seen below,
abc> show configuration logical-systems tcr1 interfaces ae2.39
vlan-id 39;
family inet {
address a.b.c.d/30;
}
family inet6 {
address /124;
Do you think that just to increase INET6 MTU to 1504 bytes resolves this
issue?
Thanks,
Gokhan
On Fri, Oct 21, 2011 at 1:51 PM, Alex wrote:
> My wild guess is that you are hitting a network of FreBSD/Olive/Linux IPv6
> routers with certain cards where when 802.1Q is enabled, MTU is
> automatically reduced by 4 bytes.
> You can simulate it with Olive by enabling "vlan-tagging" on Intel PRO/100
> card.
> My $0.02
> Thanks
> Alex
>
>
> - Original Message - From: "Gökhan Gümüs"
> To:
> Sent: Friday, October 21, 2011 11:25 AM
> Subject: [j-nsp] IPv6 MTU issue
>
>
> Dear all,
>>
>> I have an issue with IPv6 MTU.
>>
>> When i make a traceroute to one destination, the MTU size is reduced from
>> 1500 to 1496, somehow...?
>>
>> What makes it worse is that hop which drops the MTU does not send ICMP
>> "packet too long" message back..
>>
>> gg# scamper -I "trace -P udp -M abc
>> traceroute from xxx to abc
>> 1 s 0.192 ms [mtu: 1500]
>> 2 d 0.356 ms [mtu: 1500]
>> *3 f 1.422 ms [mtu: 1500]*
>> * 4 g 1.107 ms [*mtu: 1496]*
>>
>> 5 h 1.145 ms [*mtu: 1496]
>>
>>
>> On the link where MTU drops, output is as follows,
>>
>> Protocol inet, MTU: 1500
>>
>> Protocol inet6, MTU: 1500
>>
>>
>>
>> Software version is 10.0R4.7.
>>
>>
>>
>> Anybody has an experience on this behaviour before.
>>
>>
>>
>> Thanks and regards,
>>
>> Gokhan
>> __**_
>> 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] IPv6 MTU issue
Dear all, I have an issue with IPv6 MTU. When i make a traceroute to one destination, the MTU size is reduced from 1500 to 1496, somehow...? What makes it worse is that hop which drops the MTU does not send ICMP "packet too long" message back.. gg# scamper -I "trace -P udp -M abc traceroute from xxx to abc 1 s 0.192 ms [mtu: 1500] 2 d 0.356 ms [mtu: 1500] *3 f 1.422 ms [mtu: 1500]* * 4 g 1.107 ms [*mtu: 1496]* 5 h 1.145 ms [*mtu: 1496] On the link where MTU drops, output is as follows, Protocol inet, MTU: 1500 Protocol inet6, MTU: 1500 Software version is 10.0R4.7. Anybody has an experience on this behaviour before. Thanks and regards, Gokhan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unable to transmit traffic after software upgrade
Hi George, Actually my problem is how to identify it rather than looking at " monitor interface ge-x/x/x " output for every single interface. Because shut/ no shut is fixing my problem without changing vlan on customer end. Thanks and regards, Gokhan Gumus 2011/4/7 George Vlachos > Hello Gokhan, > > We had a similar case, and this happened when different vlan had been > configured on the ends of the cirtuit. > > -Original Message- > From: juniper-nsp-boun...@puck.nether.net > [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Gokhan Gumus > Sent: Thursday, April 07, 2011 2:28 PM > To: juniper-nsp@puck.nether.net > Subject: [j-nsp] Unable to transmit traffic after software upgrade > > Hi all, > > I need some advice. > We are currently in a process of upgrading our Juniper MX960 series > routers. > > Some of our customers are not able to transmit traffic after we performed > maintenance. > Circuits are connected as Layer2 circuit with ethernet-ccc configuration. > It seems circuits are hanging off. It is not a negotiation issue first of > all. > After we shut/ no shut interfaces, customers are able to transmit traffic. > This issue is not occuring on all Layer 2 ccc circuits.In order to > determine > which customer is not able to transmit traffic, either we need to monitor > traffic on all interfaces or wait for customer complaints. > > My question is, > > Is there any other way to determine this situation? > > Thanks and regards, > Gokhan Gumus > ___ > 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] Unable to transmit traffic after software upgrade
Hi all, I need some advice. We are currently in a process of upgrading our Juniper MX960 series routers. Some of our customers are not able to transmit traffic after we performed maintenance. Circuits are connected as Layer2 circuit with ethernet-ccc configuration. It seems circuits are hanging off. It is not a negotiation issue first of all. After we shut/ no shut interfaces, customers are able to transmit traffic. This issue is not occuring on all Layer 2 ccc circuits.In order to determine which customer is not able to transmit traffic, either we need to monitor traffic on all interfaces or wait for customer complaints. My question is, Is there any other way to determine this situation? Thanks and regards, Gokhan Gumus ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Too much packet loss during switchover on MPLS network
It might make sense...I have been always thinking on it. Which way would be useful to test such behaviour? To disable circuit or? Thanks, Gokhan On Mon, Mar 14, 2011 at 10:15 PM, Amos Rosenboim wrote: > As far as I remember deactivating the interface will not take the link > down, so we are relying on igp hold times to detect the failure. > If so, does the 45 seconds make any sense ? > Can you correlate igp adjacency loss to lsp switchover to customer pings ? > > Amos > > Sent from my iPhone > > On 14 Mar 2011, at 21:55, "Doug Hanks" wrote: > > > If it’s VPLS, the customer wouldn’t be using BGP though. That’s why I > mentioned STP. > > > > From: Keegan Holley [mailto:keegan.hol...@sungard.com] > > Sent: Monday, March 14, 2011 12:47 PM > > To: Gökhan Gümüş > > Cc: Doug Hanks; Diogo Montagner; juniper-nsp@puck.nether.net > > Subject: Re: [j-nsp] Too much packet loss during switchover on MPLS > network > > > > Another to way to check would be to figure out when you start seeing > mac-addresses from the customer in the vpls tables. That will mean the > network has failed over properly. Do you know what the customer topology > looks like? They could be waiting for BGP to fail over or something else > that inherently slow. I doubt this is a problem with your mpls config, > especially if you see your lsp switch. It's hard to guess without knowing > your's or the customer's topology though. > > On Mon, Mar 14, 2011 at 3:42 PM, Gökhan Gümüş ggu...@gmail.com>> wrote: > > No, they are not using rapid ping, i can confirm it. > > > > I do not agree with Spanning tree issue. > > Just for note, i am just de-activating one circuit via CLI to trigger > transition from primary to secondary. > > > > Gokhan > > > > > > 2011/3/14 Doug Hanks mailto:dha...@juniper.net>> > > I'm sure they were using a rapid ping, so it didn't take anywhere near 45 > seconds. If they were using a regular ping, however, it maybe a STP issue. > > > > Also are you using pre-signaled LSPs? > > > > -Original Message- > > From: juniper-nsp-boun...@puck.nether.net juniper-nsp-boun...@puck.nether.net> [mailto: > juniper-nsp-boun...@puck.nether.net juniper-nsp-boun...@puck.nether.net>] On Behalf Of Keegan Holley > > Sent: Monday, March 14, 2011 11:15 AM > > To: Diogo Montagner > > Cc: juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>; > Gökhan Gümüş > > Subject: Re: [j-nsp] Too much packet loss during switchover on MPLS > network > > > > On Mon, Mar 14, 2011 at 1:25 PM, Diogo Montagner > > mailto:diogo.montag...@gmail.com>>wrote: > > > >> Do you have FRR enabled on the LSPs ? > >> > > > > Node protection and link-protection is the same thing as fast re-route. > > > > Is it configured correctly though? You have to configure a secondary > path > > under protocols mpls and then enable it for FRR/node protection. You > can't > > just enable it and have it work. > > Also, what does the topology look like? Could you just be waiting for > > customer routing/spanning tree? Even without FRR your lsp's failover at > the > > speed of your IGP when a link is shut down. None of them take 41 > seconds. > > > >> > >> > >> On Tue, Mar 15, 2011 at 12:46 AM, Gökhan Gümüş <mailto:ggu...@gmail.com>> wrote: > >>> Dear all, > >>> > >>> I have a problem with one of our customer. > >>> > >>> Customer has been deployed with VPLS. We are using primary path and > >>> secondary path ( standby ) to handle VPLS traffic between sites. > >>> > >>> Within a maintenance window, we made a failover test. Customer was > >> pinging > >>> remote site continuosly and we would like to test how many packets are > >> being > >>> lost during switchover. When i triggered transition from primary to > >>> secondary, customer lost 41 packets during ping test. Then i > implemented > >>> node-link-protection and link protection in case they help but customer > >>> experienced same amount of packet loss during transition. > >>> > >>> My question, is it a normal behaviour? From my perspective it is not a > >>> normal behaviour. > >>> > >>> Has anybody such an experince? > >>> > >>> Thanks and regards, > >>> > >>> Gokhan > >>> ___ > >>> juniper-nsp mailin
Re: [j-nsp] Too much packet loss during switchover on MPLS network
Hi, I will tell you tomorrow as i have currently no access to the routers. My secondary path is in standby mode and always up. I will arrange a new maintenance window with customer to test those all recommendations. Btw, could it be a rellay software problem? Gokhan 2011/3/14 > Sorry, > > Which release ? > > Your secondary path is well in Standby mode ? > > Could you enable traffic stat for LSP with a short interval ? And check > during the blackholing where the LSP is broken on the path (by checking LSP > stat on nodes before and after the failure ) ? > > > > thks > regards > David > > > David Roy > Orange - IP Domestic Backbone - TAC > *Tel.* +33(0)299876472 > *Mob.* +33(0)685522213 > *Email.* david@orange-ftgroup.com > JNCIE-M/T #703 ; JNCIS-ENT > > > -- > *De :* Gökhan Gümüş [mailto:ggu...@gmail.com] > *Envoyé :* lundi 14 mars 2011 21:11 > *À :* ROY David DTF/DERX > *Cc :* Keegan Holley; juniper-nsp@puck.nether.net > > *Objet :* Re: [j-nsp] Too much packet loss during switchover on MPLS > network > > Actually i am using MX960 routers. > > Did you monitor forwarding database on each PE to check if there is any > change (MAC address refresh) after your 41 sec of outage ? > > - I need to re-test it. Currently i can not say it. > > Did you experience the same issue when your primary LSP comes up (and after > the revert timout) ? > > No there is no packet loss during transition from secondary to primary. > > Thanks and regards, > Gokhan > > > 2011/3/14 > >> Hi, >> >> Which version and HW do you use ? >> >> Did you monitor forwarding database on each PE to check if there is any >> change (MAC address refresh) after your 41 sec of outage ? >> >> Did you experience the same issue when your primary LSP comes up (and >> after the revert timout) ? >> >> Regards >> David >> >> >> David Roy >> Orange - IP Domestic Backbone - TAC >> Tel. <%2B33%280%29299876472>+33(0)299876472 >> Mob. <%2B33%280%29685522213>+33(0)685522213 >> Email. david@orange-ftgroup.com >> JNCIE-M/T #703 ; JNCIS-ENT >> >> -Message d'origine- >> De : juniper-nsp-boun...@puck.nether.net [mailto: >> juniper-nsp-boun...@puck.nether.net] De la part de Gökhan Gümüs >> Envoyé : lundi 14 mars 2011 20:52 >> À : Keegan Holley >> Cc : juniper-nsp@puck.nether.net >> Objet : Re: [j-nsp] Too much packet loss during switchover on MPLS network >> >> Hi, >> >> Actually customer BGP session is always up. I requested them to ping from >> different servers to the same destination when i shut the interface down.All >> of them had no reachability to the remote destinations. >> Could it be possible to fix it with BFD? >> >> Thanks, >> Gokhan >> >> On Mon, Mar 14, 2011 at 8:46 PM, Keegan Holley > >wrote: >> >> > Another to way to check would be to figure out when you start seeing >> > mac-addresses from the customer in the vpls tables. That will mean >> > the network has failed over properly. Do you know what the customer >> > topology looks like? They could be waiting for BGP to fail over or >> > something else that inherently slow. I doubt this is a problem with >> > your mpls config, especially if you see your lsp switch. It's hard to >> > guess without knowing your's or the customer's topology though. >> > >> > >> > On Mon, Mar 14, 2011 at 3:42 PM, Gökhan Gümüş wrote: >> > >> >> No, they are not using rapid ping, i can confirm it. >> >> >> >> I do not agree with Spanning tree issue. >> >> Just for note, i am just de-activating one circuit via CLI to trigger >> >> transition from primary to secondary. >> >> >> >> Gokhan >> >> >> >> >> >> >> >> 2011/3/14 Doug Hanks >> >> >> >>> I'm sure they were using a rapid ping, so it didn't take anywhere >> >>> near 45 seconds. If they were using a regular ping, however, it maybe >> a STP issue. >> >>> >> >>> Also are you using pre-signaled LSPs? >> >>> >> >>> -Original Message- >> >>> From: juniper-nsp-boun...@puck.nether.net [mailto: >> >>> juniper-nsp-boun...@puck.nether.net] On Behalf Of Keegan Holley >> >>> Sent: Monday, March 14, 2011 11:15 AM >> >>> To: Diogo Montagner >> >>> Cc: juniper-nsp@puck.net
Re: [j-nsp] Too much packet loss during switchover on MPLS network
Actually i am using MX960 routers. Did you monitor forwarding database on each PE to check if there is any change (MAC address refresh) after your 41 sec of outage ? - I need to re-test it. Currently i can not say it. Did you experience the same issue when your primary LSP comes up (and after the revert timout) ? No there is no packet loss during transition from secondary to primary. Thanks and regards, Gokhan 2011/3/14 > Hi, > > Which version and HW do you use ? > > Did you monitor forwarding database on each PE to check if there is any > change (MAC address refresh) after your 41 sec of outage ? > > Did you experience the same issue when your primary LSP comes up (and after > the revert timout) ? > > Regards > David > > > David Roy > Orange - IP Domestic Backbone - TAC > Tel. +33(0)299876472 > Mob. +33(0)685522213 > Email. david@orange-ftgroup.com > JNCIE-M/T #703 ; JNCIS-ENT > > -Message d'origine- > De : juniper-nsp-boun...@puck.nether.net [mailto: > juniper-nsp-boun...@puck.nether.net] De la part de Gökhan Gümüs > Envoyé : lundi 14 mars 2011 20:52 > À : Keegan Holley > Cc : juniper-nsp@puck.nether.net > Objet : Re: [j-nsp] Too much packet loss during switchover on MPLS network > > Hi, > > Actually customer BGP session is always up. I requested them to ping from > different servers to the same destination when i shut the interface down.All > of them had no reachability to the remote destinations. > Could it be possible to fix it with BFD? > > Thanks, > Gokhan > > On Mon, Mar 14, 2011 at 8:46 PM, Keegan Holley >wrote: > > > Another to way to check would be to figure out when you start seeing > > mac-addresses from the customer in the vpls tables. That will mean > > the network has failed over properly. Do you know what the customer > > topology looks like? They could be waiting for BGP to fail over or > > something else that inherently slow. I doubt this is a problem with > > your mpls config, especially if you see your lsp switch. It's hard to > > guess without knowing your's or the customer's topology though. > > > > > > On Mon, Mar 14, 2011 at 3:42 PM, Gökhan Gümüş wrote: > > > >> No, they are not using rapid ping, i can confirm it. > >> > >> I do not agree with Spanning tree issue. > >> Just for note, i am just de-activating one circuit via CLI to trigger > >> transition from primary to secondary. > >> > >> Gokhan > >> > >> > >> > >> 2011/3/14 Doug Hanks > >> > >>> I'm sure they were using a rapid ping, so it didn't take anywhere > >>> near 45 seconds. If they were using a regular ping, however, it maybe > a STP issue. > >>> > >>> Also are you using pre-signaled LSPs? > >>> > >>> -Original Message- > >>> From: juniper-nsp-boun...@puck.nether.net [mailto: > >>> juniper-nsp-boun...@puck.nether.net] On Behalf Of Keegan Holley > >>> Sent: Monday, March 14, 2011 11:15 AM > >>> To: Diogo Montagner > >>> Cc: juniper-nsp@puck.nether.net; Gökhan Gümüş > >>> Subject: Re: [j-nsp] Too much packet loss during switchover on MPLS > >>> network > >>> > >>> On Mon, Mar 14, 2011 at 1:25 PM, Diogo Montagner > >>> wrote: > >>> > >>> > Do you have FRR enabled on the LSPs ? > >>> > > >>> > >>> Node protection and link-protection is the same thing as fast re-route. > >>> > >>> Is it configured correctly though? You have to configure a > >>> secondary path under protocols mpls and then enable it for FRR/node > >>> protection. You can't just enable it and have it work. > >>> Also, what does the topology look like? Could you just be waiting > >>> for customer routing/spanning tree? Even without FRR your lsp's > >>> failover at the speed of your IGP when a link is shut down. None of > >>> them take 41 seconds. > >>> > >>> > > >>> > > >>> > On Tue, Mar 15, 2011 at 12:46 AM, Gökhan Gümüş > >>> wrote: > >>> > > Dear all, > >>> > > > >>> > > I have a problem with one of our customer. > >>> > > > >>> > > Customer has been deployed with VPLS. We are using primary path > >>> > > and secondary path ( standby ) to handle VPLS traffic between > sites. > >>> > > > >>> > > Within a maintenance
Re: [j-nsp] Too much packet loss during switchover on MPLS network
No, they are using BGP... But BGP is always up during transition.. Gokhan 2011/3/14 Doug Hanks > If it’s VPLS, the customer wouldn’t be using BGP though. That’s why I > mentioned STP. > > > > *From:* Keegan Holley [mailto:keegan.hol...@sungard.com] > *Sent:* Monday, March 14, 2011 12:47 PM > *To:* Gökhan Gümüş > *Cc:* Doug Hanks; Diogo Montagner; juniper-nsp@puck.nether.net > > *Subject:* Re: [j-nsp] Too much packet loss during switchover on MPLS > network > > > > Another to way to check would be to figure out when you start seeing > mac-addresses from the customer in the vpls tables. That will mean the > network has failed over properly. Do you know what the customer topology > looks like? They could be waiting for BGP to fail over or something else > that inherently slow. I doubt this is a problem with your mpls config, > especially if you see your lsp switch. It's hard to guess without knowing > your's or the customer's topology though. > > On Mon, Mar 14, 2011 at 3:42 PM, Gökhan Gümüş wrote: > > No, they are not using rapid ping, i can confirm it. > > I do not agree with Spanning tree issue. > Just for note, i am just de-activating one circuit via CLI to trigger > transition from primary to secondary. > > Gokhan > > > > 2011/3/14 Doug Hanks > > I'm sure they were using a rapid ping, so it didn't take anywhere near 45 > seconds. If they were using a regular ping, however, it maybe a STP issue. > > Also are you using pre-signaled LSPs? > > > -Original Message- > From: juniper-nsp-boun...@puck.nether.net [mailto: > juniper-nsp-boun...@puck.nether.net] On Behalf Of Keegan Holley > Sent: Monday, March 14, 2011 11:15 AM > To: Diogo Montagner > Cc: juniper-nsp@puck.nether.net; Gökhan Gümüş > Subject: Re: [j-nsp] Too much packet loss during switchover on MPLS network > > On Mon, Mar 14, 2011 at 1:25 PM, Diogo Montagner > wrote: > > > Do you have FRR enabled on the LSPs ? > > > > Node protection and link-protection is the same thing as fast re-route. > > Is it configured correctly though? You have to configure a secondary path > under protocols mpls and then enable it for FRR/node protection. You can't > just enable it and have it work. > Also, what does the topology look like? Could you just be waiting for > customer routing/spanning tree? Even without FRR your lsp's failover at > the > speed of your IGP when a link is shut down. None of them take 41 seconds. > > > > > > > On Tue, Mar 15, 2011 at 12:46 AM, Gökhan Gümüş wrote: > > > Dear all, > > > > > > I have a problem with one of our customer. > > > > > > Customer has been deployed with VPLS. We are using primary path and > > > secondary path ( standby ) to handle VPLS traffic between sites. > > > > > > Within a maintenance window, we made a failover test. Customer was > > pinging > > > remote site continuosly and we would like to test how many packets are > > being > > > lost during switchover. When i triggered transition from primary to > > > secondary, customer lost 41 packets during ping test. Then i > implemented > > > node-link-protection and link protection in case they help but customer > > > experienced same amount of packet loss during transition. > > > > > > My question, is it a normal behaviour? From my perspective it is not a > > > normal behaviour. > > > > > > Has anybody such an experince? > > > > > > Thanks and regards, > > > > > > Gokhan > > > ___ > > > 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] Too much packet loss during switchover on MPLS network
Hi, Actually customer BGP session is always up. I requested them to ping from different servers to the same destination when i shut the interface down.All of them had no reachability to the remote destinations. Could it be possible to fix it with BFD? Thanks, Gokhan On Mon, Mar 14, 2011 at 8:46 PM, Keegan Holley wrote: > Another to way to check would be to figure out when you start seeing > mac-addresses from the customer in the vpls tables. That will mean the > network has failed over properly. Do you know what the customer topology > looks like? They could be waiting for BGP to fail over or something else > that inherently slow. I doubt this is a problem with your mpls config, > especially if you see your lsp switch. It's hard to guess without knowing > your's or the customer's topology though. > > > On Mon, Mar 14, 2011 at 3:42 PM, Gökhan Gümüş wrote: > >> No, they are not using rapid ping, i can confirm it. >> >> I do not agree with Spanning tree issue. >> Just for note, i am just de-activating one circuit via CLI to trigger >> transition from primary to secondary. >> >> Gokhan >> >> >> >> 2011/3/14 Doug Hanks >> >>> I'm sure they were using a rapid ping, so it didn't take anywhere near 45 >>> seconds. If they were using a regular ping, however, it maybe a STP issue. >>> >>> Also are you using pre-signaled LSPs? >>> >>> -Original Message- >>> From: juniper-nsp-boun...@puck.nether.net [mailto: >>> juniper-nsp-boun...@puck.nether.net] On Behalf Of Keegan Holley >>> Sent: Monday, March 14, 2011 11:15 AM >>> To: Diogo Montagner >>> Cc: juniper-nsp@puck.nether.net; Gökhan Gümüş >>> Subject: Re: [j-nsp] Too much packet loss during switchover on MPLS >>> network >>> >>> On Mon, Mar 14, 2011 at 1:25 PM, Diogo Montagner >>> wrote: >>> >>> > Do you have FRR enabled on the LSPs ? >>> > >>> >>> Node protection and link-protection is the same thing as fast re-route. >>> >>> Is it configured correctly though? You have to configure a secondary >>> path >>> under protocols mpls and then enable it for FRR/node protection. You >>> can't >>> just enable it and have it work. >>> Also, what does the topology look like? Could you just be waiting for >>> customer routing/spanning tree? Even without FRR your lsp's failover at >>> the >>> speed of your IGP when a link is shut down. None of them take 41 >>> seconds. >>> >>> > >>> > >>> > On Tue, Mar 15, 2011 at 12:46 AM, Gökhan Gümüş >>> wrote: >>> > > Dear all, >>> > > >>> > > I have a problem with one of our customer. >>> > > >>> > > Customer has been deployed with VPLS. We are using primary path and >>> > > secondary path ( standby ) to handle VPLS traffic between sites. >>> > > >>> > > Within a maintenance window, we made a failover test. Customer was >>> > pinging >>> > > remote site continuosly and we would like to test how many packets >>> are >>> > being >>> > > lost during switchover. When i triggered transition from primary to >>> > > secondary, customer lost 41 packets during ping test. Then i >>> implemented >>> > > node-link-protection and link protection in case they help but >>> customer >>> > > experienced same amount of packet loss during transition. >>> > > >>> > > My question, is it a normal behaviour? From my perspective it is not >>> a >>> > > normal behaviour. >>> > > >>> > > Has anybody such an experince? >>> > > >>> > > Thanks and regards, >>> > > >>> > > Gokhan >>> > > ___ >>> > > 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] Too much packet loss during switchover on MPLS network
No, they are not using rapid ping, i can confirm it. I do not agree with Spanning tree issue. Just for note, i am just de-activating one circuit via CLI to trigger transition from primary to secondary. Gokhan 2011/3/14 Doug Hanks > I'm sure they were using a rapid ping, so it didn't take anywhere near 45 > seconds. If they were using a regular ping, however, it maybe a STP issue. > > Also are you using pre-signaled LSPs? > > -Original Message- > From: juniper-nsp-boun...@puck.nether.net [mailto: > juniper-nsp-boun...@puck.nether.net] On Behalf Of Keegan Holley > Sent: Monday, March 14, 2011 11:15 AM > To: Diogo Montagner > Cc: juniper-nsp@puck.nether.net; Gökhan Gümüş > Subject: Re: [j-nsp] Too much packet loss during switchover on MPLS network > > On Mon, Mar 14, 2011 at 1:25 PM, Diogo Montagner > wrote: > > > Do you have FRR enabled on the LSPs ? > > > > Node protection and link-protection is the same thing as fast re-route. > > Is it configured correctly though? You have to configure a secondary path > under protocols mpls and then enable it for FRR/node protection. You can't > just enable it and have it work. > Also, what does the topology look like? Could you just be waiting for > customer routing/spanning tree? Even without FRR your lsp's failover at > the > speed of your IGP when a link is shut down. None of them take 41 seconds. > > > > > > > On Tue, Mar 15, 2011 at 12:46 AM, Gökhan Gümüş wrote: > > > Dear all, > > > > > > I have a problem with one of our customer. > > > > > > Customer has been deployed with VPLS. We are using primary path and > > > secondary path ( standby ) to handle VPLS traffic between sites. > > > > > > Within a maintenance window, we made a failover test. Customer was > > pinging > > > remote site continuosly and we would like to test how many packets are > > being > > > lost during switchover. When i triggered transition from primary to > > > secondary, customer lost 41 packets during ping test. Then i > implemented > > > node-link-protection and link protection in case they help but customer > > > experienced same amount of packet loss during transition. > > > > > > My question, is it a normal behaviour? From my perspective it is not a > > > normal behaviour. > > > > > > Has anybody such an experince? > > > > > > Thanks and regards, > > > > > > Gokhan > > > ___ > > > 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] Too much packet loss during switchover on MPLS network
Thanks for the updates... Yes i enabled node-link-protection and link protection respectively. Results are same. LSP change from primary to secondary occurs immediately as i can see it from mpls logs. I have no problem on it. I am talking about customer traffic. Customer is sending ping packets continuosly and during that time i shut one interface down which is triggering a transition from primary to secondary.After that customer experienced packet loss for 41 seconds. MPLS LSPs are being used for VPLS traffic. I have no visibility on Layer 3 side on customer. Kind regards, Gokhan Gumus 2011/3/14 Keegan Holley > > On Mon, Mar 14, 2011 at 1:25 PM, Diogo Montagner < > diogo.montag...@gmail.com> wrote: > >> Do you have FRR enabled on the LSPs ? >> > > Node protection and link-protection is the same thing as fast re-route. > > Is it configured correctly though? You have to configure a secondary path > under protocols mpls and then enable it for FRR/node protection. You can't > just enable it and have it work. > Also, what does the topology look like? Could you just be waiting for > customer routing/spanning tree? Even without FRR your lsp's failover at the > speed of your IGP when a link is shut down. None of them take 41 seconds. > >> >> >> On Tue, Mar 15, 2011 at 12:46 AM, Gökhan Gümüş wrote: >> > Dear all, >> > >> > I have a problem with one of our customer. >> > >> > Customer has been deployed with VPLS. We are using primary path and >> > secondary path ( standby ) to handle VPLS traffic between sites. >> > >> > Within a maintenance window, we made a failover test. Customer was >> pinging >> > remote site continuosly and we would like to test how many packets are >> being >> > lost during switchover. When i triggered transition from primary to >> > secondary, customer lost 41 packets during ping test. Then i implemented >> > node-link-protection and link protection in case they help but customer >> > experienced same amount of packet loss during transition. >> > >> > My question, is it a normal behaviour? From my perspective it is not a >> > normal behaviour. >> > >> > Has anybody such an experince? >> > >> > Thanks and regards, >> > >> > Gokhan >> > ___ >> > 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
[j-nsp] Too much packet loss during switchover on MPLS network
Dear all, I have a problem with one of our customer. Customer has been deployed with VPLS. We are using primary path and secondary path ( standby ) to handle VPLS traffic between sites. Within a maintenance window, we made a failover test. Customer was pinging remote site continuosly and we would like to test how many packets are being lost during switchover. When i triggered transition from primary to secondary, customer lost 41 packets during ping test. Then i implemented node-link-protection and link protection in case they help but customer experienced same amount of packet loss during transition. My question, is it a normal behaviour? From my perspective it is not a normal behaviour. Has anybody such an experince? Thanks and regards, Gokhan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Dedicated LSP for VPLS traffic
Hi all, It might be a silly question but i have a problem with mapping an LSP for specific VPN traffic. We have 3 PE routers and running Layer3 VPN between them by using RSVP LSPs. We have also one VPLS customer between those routers. What i want to achieve is to map that VPLS traffic on a specific LSP and to prevent other L3 VPN traffic to use it. Firstly i created a dedicated LSPs with higher preference which make them not active for all other L3 VPN traffic. And then i configured a policy with install next-hop lsp config with matching VPLS community. So far so good...But my VPLS traffic is still choosing other LSPs because of lower preference values. Question 1: Is this really required to keep preference values identical? Question 2: If it is really required, how can i prevent other L3 VPN traffic to use my VPLS dedicated MPLS LSP? Thanks and regards, Gokhan Gumus ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Site-2-Site VPN problem between Netscreen and PIX
Hi all, I am tring to establish a VPN between Netscreen and PIX. I am doing route-based VPN on my side and administrator of only Netscreen. I ca prove that VPN is working fine when i define local address of remote sides. 192.168.1.0/24-INTERNET----172.16.1.0/24 But our customer does not want to provide their Local ip addresses because they want to NAT all IP addresses behind the firewall to the Public IP address that i used as `Remote Gateway IP`. So in this case i am not able to define a policy or if i can how? If someone has an experience on this,could you please help me? Thanks and regards, Gokhan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] NAT Redundancy on Juniper routers
Actually i am doing Static-Nat 1:1 :( Rgds, Gokhan On Mon, Jan 10, 2011 at 1:55 PM, Alex wrote: > Actually on a second thought I reckon You might be able to achieve > physical-box NAT redundancy using static NAT and IP-ALG but: > 1/ it is not scalable (static NAT is 1:1) > 2/ I never tried this myself :-) > Where the port translation is involved the sequence of events is as I > described below. > Rgds > Alex > > > - Original Message - > *From:* Gökhan Gümüş > *To:* Alex > *Cc:* juniper-nsp@puck.nether.net > *Sent:* Monday, January 10, 2011 12:46 PM > *Subject:* Re: [j-nsp] NAT Redundancy on Juniper routers > > Hi Alex, > > Thanks for the response. > So there is nothing i can do at this moment :( > > Regards, > Gokhan > > On Mon, Jan 10, 2011 at 1:43 PM, Alex wrote: > >> Hello Gokhan Gumus, >> AFAIK this is not possible at the moment since flows are not shared >> between MSDPCs even inside same MX box let alone different physical boxes. >> So if R1 goes down the: >> 1/ TCP flows need to reestablish starting from 3-way handshake >> 2/ UDP flows with ALG need to reestablish starting from scratch (every ALG >> has different procedures) >> 3/ non-ALG UDP flows _can_ continue as if nothing happened depending on >> protocol, e.g. p2p UDP flows will resume from last xferred piece >> 4/ ICMP flows continue as if nothing happened >> If you need physical-box-redundant NAT I'd suggest to use SRX cluster. >> HTH >> Rgds >> Alex >> >> - Original Message - From: "Gökhan Gümüs" >> To: >> Sent: Monday, January 10, 2011 12:15 PM >> Subject: [j-nsp] NAT Redundancy on Juniper routers >> >> >> Hi all, >>> >>> I am trying to achieve redundancy on Juniper routers while performing >>> NAT. >>> >>> I have two Juniper MX960 router on the backbone with VRRP setup.I am >>> configuring NAT on R1 successfull.Same NAT rules are existing on the >>> other >>> router but on R2,static route which is pointing sp interface is >>> deactivated.Is there anyway to achieve automatic failover capability on >>> NAT?In other words if something happened on R1, can R2 handle all NAT >>> process without doing anything? >>> >>> Kind regards, >>> Gokhan Gumus >>> ___ >>> 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] NAT Redundancy on Juniper routers
Hi Alex, Thanks for the response. So there is nothing i can do at this moment :( Regards, Gokhan On Mon, Jan 10, 2011 at 1:43 PM, Alex wrote: > Hello Gokhan Gumus, > AFAIK this is not possible at the moment since flows are not shared between > MSDPCs even inside same MX box let alone different physical boxes. > So if R1 goes down the: > 1/ TCP flows need to reestablish starting from 3-way handshake > 2/ UDP flows with ALG need to reestablish starting from scratch (every ALG > has different procedures) > 3/ non-ALG UDP flows _can_ continue as if nothing happened depending on > protocol, e.g. p2p UDP flows will resume from last xferred piece > 4/ ICMP flows continue as if nothing happened > If you need physical-box-redundant NAT I'd suggest to use SRX cluster. > HTH > Rgds > Alex > > - Original Message - From: "Gökhan Gümüs" > To: > Sent: Monday, January 10, 2011 12:15 PM > Subject: [j-nsp] NAT Redundancy on Juniper routers > > > Hi all, >> >> I am trying to achieve redundancy on Juniper routers while performing NAT. >> >> I have two Juniper MX960 router on the backbone with VRRP setup.I am >> configuring NAT on R1 successfull.Same NAT rules are existing on the other >> router but on R2,static route which is pointing sp interface is >> deactivated.Is there anyway to achieve automatic failover capability on >> NAT?In other words if something happened on R1, can R2 handle all NAT >> process without doing anything? >> >> Kind regards, >> Gokhan Gumus >> ___ >> 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] NAT Redundancy on Juniper routers
Hi all, I am trying to achieve redundancy on Juniper routers while performing NAT. I have two Juniper MX960 router on the backbone with VRRP setup.I am configuring NAT on R1 successfull.Same NAT rules are existing on the other router but on R2,static route which is pointing sp interface is deactivated.Is there anyway to achieve automatic failover capability on NAT?In other words if something happened on R1, can R2 handle all NAT process without doing anything? Kind regards, Gokhan Gumus ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Required books/resources to pass Juniper exams
Hi all, Since my JNCIS certificate expired, i have to re-take that in order to attend JNCIP exam. I checked Juniper official web site and saw that there are many changes on certification tracks. Firstly i have to pass JNCIA-JUNOS as it is pre-requisite for JNCIS-SP. And also there are some changes on exam topics.So as these updates are new to me could you please give me some advices on how to study those certifications? I need to know which books should i read to pass JNCIA-JUNOS and JNCIS-SP? Thanks, Gokhan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX-OSPF problem
Hi ,
Pls see my policies on both routers,
R1,
R1> show configuration policy-options
policy-statement static-direct-to-ospf {
term 10 {
from protocol [ static direct ];
then accept;
R2,
R2> show configuration policy-options
policy-statement static-direct-to-ospf {
term 10 {
from protocol [ static direct ];
then accept;
Thanks and regards,
Gokhan
2010/12/27 Cristian Frizziero
> Could you copy the detail of the policy you are applying?
>
> Thanks
>
> [image: Logo]
>
> Ing. Cristian Frizziero
> Honorio Pueyrredon 1475
> Buenos Aires - Argentina
>
> Tel. +54.11.4855.6041 (Ext. 517)
> Cel. +54.11.6811.7562
>
> [image: dd] cristian.frizziero
>
> [image: m]Mailcristian.frizzi...@iquall.net
> Webwww.iquall.net
>
>
>
>
>
>
> El 27/12/2010 13:15, Smith W. Stacy escribió:
>
> Thanks, but we need the 'show ospf database exensive' output as well.
>
> --Stacy
>
>
> On Dec 27, 2010, at 9:11 AM, Gökhan Gümüş wrote:
>
>
> Hi all,
>
> Also please see the show ospf route detail output from boh routers,
>
> R1,
> the...@dcn.lon10.uk> show ospf route detail
> Topology default Route Table:
>
> Prefix Path Route NH Metric NextHop Nexthop
>Type Type TypeInterface
> Address/LSP10.100.9.16/32 Intra NetworkIP0 lo0.0
> area 0.0.0.0, origin 10.100.9.16, priority low
>
>
> R2,
>
> R2> show ospf route detail
> Topology default Route Table:
>
> Prefix Path Route NH Metric NextHop Nexthop
>Type Type TypeInterface Address/LSP
> 10.100.9.1 Intra AS BR IP1 ge-0/0/0.50 10.100.0.241
> area 0.0.0.0, origin 10.100.9.1, optional-capability 0x2
> 10.100.9.2 Intra AS BR IP2 ge-0/0/0.50 10.100.0.241
> area 0.0.0.0, origin 10.100.9.2, optional-capability 0x2
> 10.100.9.4 Intra AS BR IP2 ge-0/0/0.50 10.100.0.241
> area 0.0.0.0, origin 10.100.9.4, optional-capability 0x2
> 10.100.9.5 Intra AS BR IP2 ge-0/0/0.50 10.100.0.241
> area 0.0.0.0, origin 10.100.9.5, optional-capability 0x2
> 10.100.9.13Intra AS BR IP1 ge-0/0/0.55 10.100.0.35
> area 0.0.0.0, origin 10.100.9.13, optional-capability 0x2
> 10.100.9.18Intra AS BR IP1 ge-0/0/0.55 10.100.0.40
> area 0.0.0.0, origin 10.100.9.18, optional-capability 0x2
> 10.100.9.20Intra AS BR IP1 ge-0/0/0.55 10.100.0.42
> area 0.0.0.0, origin 10.100.9.20, optional-capability 0x2
> 10.100.9.25Intra AS BR IP1 ge-0/0/0.55 10.100.0.47
> area 0.0.0.0, origin 10.100.9.25, optional-capability 0x2
> 10.100.9.39Intra Router IP1 ge-0/0/0.50 10.100.0.245
> area 0.0.0.0, origin 10.100.9.39, optional-capability 0x0
> 10.100.9.41Intra AS BR IP1 ge-0/0/0.50 10.100.0.246
> area 0.0.0.0, origin 10.100.9.41, optional-capability 0x20.0.0.0/0
> Ext2 NetworkIP0 ge-0/0/0.50 10.100.0.241
> area 0.0.0.0, origin 10.100.9.1, priority medium10.100.0.0/27 Intra
> NetworkIP2 ge-0/0/0.50 10.100.0.241
> area 0.0.0.0, origin 10.100.9.5, priority medium10.100.0.32/27 Intra
> NetworkIP1 ge-0/0/0.55
> area 0.0.0.0, origin 10.100.9.25, priority low10.100.0.128/27Intra
> NetworkIP2 ge-0/0/0.50 10.100.0.245
> area 0.0.0.0, origin 10.100.9.39, priority medium10.100.0.160/27Ext2
> NetworkIP0 ge-0/0/0.50 10.100.0.246
> area 0.0.0.0, origin 10.100.9.41, priority medium10.100.0.240/28Intra
> NetworkIP1 ge-0/0/0.50
> area 0.0.0.0, origin 10.100.9.1, priority low10.100.1.0/28 Ext2
> NetworkIP0 ge-0/0/0.50 10.100.0.241
> area 0.0.0.0, origin 10.100.9.4, priority medium10.100.1.16/28 Intra
> NetworkIP2 ge-0/0/0.50 10.100.0.241
> area 0.0.0.0, origin 10.100.9.1, priority medium10.100.1.32/28 Ext2
> NetworkIP0 ge-0/0/0.50 10.100.0.241
> area 0.0.0.0, origin 10.100.9.2, priority medium10.100.1.64/28 Ext2
> NetworkIP0 ge-0/0/0.50 10.100.0.241
> area 0.0.0.0, origin 10.100.9.5, priority medium10.100.1.176/28Intra
> NetworkIP2 ge-0/0/0.50 10.100.0.241
> area 0.0.0.0, origin 10.100.9.1, priority medium10.100.2.16/28 Intra
> NetworkIP2 ge-0/0/0.55 10.100.0.40
> area 0.0.0.0, origin 10.100.9.18, priority medium10.100.2.19/32
Re: [j-nsp] SRX-OSPF problem
.0.0.0, origin 10.100.9.2, priority medium
10.100.9.4/32 Ext2 NetworkIP0 ge-0/0/0.50
10.100.0.241
area 0.0.0.0, origin 10.100.9.4, priority medium
10.100.9.5/32 Ext2 NetworkIP0 ge-0/0/0.50
10.100.0.241
area 0.0.0.0, origin 10.100.9.5, priority medium
10.100.9.13/32 Intra NetworkIP1 ge-0/0/0.55
10.100.0.35
area 0.0.0.0, origin 10.100.9.13, priority medium
10.100.9.18/32 Intra NetworkIP1 ge-0/0/0.55
10.100.0.40
area 0.0.0.0, origin 10.100.9.18, priority medium
10.100.9.20/32 Intra NetworkIP1 ge-0/0/0.55
10.100.0.42
area 0.0.0.0, origin 10.100.9.20, priority medium
10.100.9.25/32 Intra NetworkIP1 ge-0/0/0.55
10.100.0.47
area 0.0.0.0, origin 10.100.9.25, priority medium
10.100.9.39/32 Intra NetworkIP1 ge-0/0/0.50
10.100.0.245
area 0.0.0.0, origin 10.100.9.39, priority medium
10.100.9.41/32 Ext2 NetworkIP0 ge-0/0/0.50
10.100.0.246
area 0.0.0.0, origin 10.100.9.41, priority medium
10.111.1.0/30 Ext2 NetworkIP0 ge-0/0/0.55
10.100.0.40
area 0.0.0.0, origin 10.100.9.18, priority medium
82.98.222.32/27Intra NetworkIP2 ge-0/0/0.50
10.100.0.241
area 0.0.0.0, origin 10.100.9.1, priority medium
192.168.0.24/30Ext2 NetworkIP0 ge-0/0/0.50
10.100.0.241
area 0.0.0.0, origin 10.100.9.1, priority medium
192.168.0.28/30Ext2 NetworkIP0 ge-0/0/0.50
10.100.0.241
area 0.0.0.0, origin 10.100.9.1, priority medium
192.168.1.0/24 Ext2 NetworkIP0 ge-0/0/0.50
10.100.0.246
area 0.0.0.0, origin 10.100.9.41, priority medium
Thanks,
Gokhan
On Mon, Dec 27, 2010 at 5:00 PM, Smith W. Stacy wrote:
> Can you provide the output of 'show ospf database extensive' and 'show ospf
> route detail' from both routers?
>
> --Stacy
>
>
> On Dec 27, 2010, at 8:48 AM, Gökhan Gümüş wrote:
>
> > Hi all,
> >
> > I have two Juniper SRX 210 router which are connected via VPLS.
> > VPLS is up and running.
> > I am using 10.1R1.8 version on both boxes.
> > My question is even if OSPF is up and running, routes are not being
> > exchanged each other.
> > I am accepting all OSPF traffic on security zones.
> >
> > R1> show configuration protocols ospf
> >
> > export static-direct-to-ospf;
> > area 0.0.0.0 {
> >interface ge-0/0/0.55;
> >interface lo0.0;
> >
> > R1> show configuration interfaces ge-0/0/0.55
> > vlan-id 55;
> > family inet {
> >address 10.100.0.38/27;
> > }
> >
> > R1> show configuration interfaces lo0
> > unit 0 {
> >family inet {
> >address 10.100.9.16/32;
> >
> >
> >
> >
> > R2> show configuration protocols ospf
> >
> > export static-direct-to-ospf;
> > area 0.0.0.0 {
> >interface ge-0/0/0.50 {
> >priority 128;
> >}
> >interface ge-0/0/0.55 {
> >priority 255;
> >
> > R2> show configuration interfaces ge-0/0/0.55
> > description "[DCN-UK]";
> > vlan-id 55;
> > family inet {
> >address 10.100.0.34/27;
> > }
> >
> > R2> show configuration interfaces lo0
> > unit 0 {
> >family inet {
> >address 10.100.9.12/32 {
> >primary;
> >preferred;
> >}
> >address 127.0.0.1/32;
> >
> > R1> show ospf neighbor
> > Address Interface State ID Pri
> Dead
> > 10.100.0.34 ge-0/0/0.55Full 10.100.9.12 255
> 36
> >
> > R1> show route
> >
> > inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
> > + = Active Route, - = Last Active, * = Both
> >
> > 10.100.0.32/27 *[Direct/0] 16:20:03
> >> via ge-0/0/0.55
> > 10.100.0.38/32 *[Local/0] 16:20:08
> > Local via ge-0/0/0.55
> > 10.100.2.96/28 *[Direct/0] 16:18:41
> >> via vlan.0
> > 10.100.2.110/32*[Local/0] 16:21:05
> > Local via vlan.0
> > 10.100.9.16/32 *[Direct/0] 16:21:20
> >> via lo0.0
> > 224.0.0.5/32 *[OSPF/10] 16:21:21, metric 1
> > MultiRecv
> >
> >
> >
> >
> > R2> show ospf neighbor
> > Address Interface State ID Pri
> Dead
> > 10.100.0.38 ge-0/0/0.55Full 10.100.9.16 128
> 3
[j-nsp] SRX-OSPF problem
Hi all,
I have two Juniper SRX 210 router which are connected via VPLS.
VPLS is up and running.
I am using 10.1R1.8 version on both boxes.
My question is even if OSPF is up and running, routes are not being
exchanged each other.
I am accepting all OSPF traffic on security zones.
R1> show configuration protocols ospf
export static-direct-to-ospf;
area 0.0.0.0 {
interface ge-0/0/0.55;
interface lo0.0;
R1> show configuration interfaces ge-0/0/0.55
vlan-id 55;
family inet {
address 10.100.0.38/27;
}
R1> show configuration interfaces lo0
unit 0 {
family inet {
address 10.100.9.16/32;
R2> show configuration protocols ospf
export static-direct-to-ospf;
area 0.0.0.0 {
interface ge-0/0/0.50 {
priority 128;
}
interface ge-0/0/0.55 {
priority 255;
R2> show configuration interfaces ge-0/0/0.55
description "[DCN-UK]";
vlan-id 55;
family inet {
address 10.100.0.34/27;
}
R2> show configuration interfaces lo0
unit 0 {
family inet {
address 10.100.9.12/32 {
primary;
preferred;
}
address 127.0.0.1/32;
R1> show ospf neighbor
Address Interface State ID Pri Dead
10.100.0.34 ge-0/0/0.55Full 10.100.9.12 25536
R1> show route
inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.100.0.32/27 *[Direct/0] 16:20:03
> via ge-0/0/0.55
10.100.0.38/32 *[Local/0] 16:20:08
Local via ge-0/0/0.55
10.100.2.96/28 *[Direct/0] 16:18:41
> via vlan.0
10.100.2.110/32*[Local/0] 16:21:05
Local via vlan.0
10.100.9.16/32 *[Direct/0] 16:21:20
> via lo0.0
224.0.0.5/32 *[OSPF/10] 16:21:21, metric 1
MultiRecv
R2> show ospf neighbor
Address Interface State ID Pri Dead
10.100.0.38 ge-0/0/0.55Full 10.100.9.16 12831
R2> show route
10.100.2.19/32 *[OSPF/150] 16:30:39, metric 0, tag 0
> to 10.100.0.40 via ge-0/0/0.55
10.100.2.32/28 *[OSPF/10] 16:30:39, metric 2
> to 10.100.0.47 via ge-0/0/0.55
10.100.2.48/28 *[OSPF/10] 16:17:38, metric 2
> to 10.100.0.42 via ge-0/0/0.55
10.100.2.55/32 *[OSPF/150] 16:17:38, metric 0, tag 0
> to 10.100.0.42 via ge-0/0/0.55
Is there anyone who might explain that strange behaviour?
Thanks,
Gokhan
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] JNCIP lab exam
Hi all, I have recently decided to prepare for JNCIP lab exam. Since real hardwares are pretty expensive,i would like to build up a home lab with OLIVE on Windows/Ubuntu. Could anyone help me how to install it? What are the hardware requirement? ( RAM,HD,Ethernet card...etc) Basically how many ethernet card do i need to simulate/connect seven juniper router as basically shown in the JNCIP lab topology in JNCIP book? Thanks, Gokhan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Multicast issue
Dear all,
I have a problem with counting multicast packets sending out to Receiver
Site.
Source--PE-PEReceiver
PE-Receiver connection is IRB interface.
I have put an output filter facing Receiver site with destination-MAC (
converted MAC address from Group Address) but it did not work.
Here is my filter below:
abc> show configuration firewall family bridge filter xxx
term 01 {
from {
destination-mac-address {
01:00:5e:00:35:06/48;
}
}
then {
count mcast_count;
accept;
}
}
term 02 {
then accept;
Is there any way how to count multicast packet sent by PE router to the
receiver?
Thanks,
Gokhan
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Multilink connection between Frame Relay and ATM
Hi guys, I have two Juniper router and both of them have AS PIC card.AS PIC cards are working for L2 services. I have two links between these M10i and M7i and i want to bundle these two link to a one multilink interface.Problem is one side of my link is configured with encapsulation frame-relay and one side of link is terminated on my ATM card. Is there way to configure these two links as a one multilink interface? Thanks, Gokhan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Strange error on AS PIC
Hi Dan, Thanks for your update. Now case is in JTAC.I havent got one more AS PIC :( Kind regards, Gokhan On 5/31/07, Dan Rautio <[EMAIL PROTECTED]> wrote: > > Hi Gokhan, > > I think opening a jtac case is an excellent idea. This doesn't look like > any bad hardware. It looks more like over-loading the as-pic with too many > services. Of course, this would need to be investigated by looking at your > config, number of flows, etc that can be done when you open the support > case. > > Do you have another as-pic you could try to move some service-sets to? > > - Dan > > > -Original Message- > From: Gökhan Gümüs [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 31, 2007 1:56 AM > To: Dan Rautio > Subject: Re: [j-nsp] Strange error on AS PIC > > > Hi Dan, > > Thanks for reply first of all. > > No,i havent made any config changes lately.Just adding 3-4 more > service-set for NAT operations for our customers.Also i always see this > memory loading but in these days when i got that strange error message,i > understand that situation will be critical in next days. > > Have you any recommendation about that issue?Also i want to open a case to > JTAC and maybe it needs to making a RMA for this card... > > Kind regards, > > Gokhan > > > On 5/31/07, Dan Rautio <[EMAIL PROTECTED]> wrote: > Hi Gokhan, > > It appears your as pic is running out of memory. Have you made any config > changes lately that would increase the load on the pic? > > - Dan > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto: [EMAIL PROTECTED] On Behalf Of G?n G?r>> > Sent: Wednesday, May 30, 2007 9:48 AM > > To: juniper-nsp@puck.nether.net > > Subject: [j-nsp] Strange error on AS PIC > > > > > > Hi guys, > > > > I have a strange problem with our AS PIC.We are using that AS > > PIC card for > > NAT operation for our L3 VPN customers.In these days NAT > > operation is not > > working on some specific customers.I am using JUNOS 7.6 R4.3. > > > > When NAT doesnt work,i get this output. > > > > [EMAIL PROTECTED]> show services stateful-firewall flows > > service-set ABC > > > > *error: libservicesui: ipc_pipe_read() failed - Unknown error: 0 > > -> ?* > > ** > > ** > > Also i get these outputs from my syslog messages when i got > > these error. > > > > May 30 17:39:08 (FPC Slot 0, PIC Slot 2) Entered orange > > memory zone 300 ms > > ago > > May 30 17:39:17 (FPC Slot 0, PIC Slot 2) Entered yellow > > memory zone 800 ms > > ago > > May 30 17:39:24 (FPC Slot 0, PIC Slot 2) Entered orange > > memory zone 800 ms > > ago > > May 30 17:39:25 (FPC Slot 0, PIC Slot 2) Entered yellow > > memory zone 300 ms > > ago > > May 30 17:39:27 (FPC Slot 0, PIC Slot 2) Entered yellow > > memory zone 300 ms > > ago > > May 30 17:39:27 (FPC Slot 0, PIC Slot 2) Entered green > > memory zone 300 ms > > ago > > May 30 17:39:28 (FPC Slot 0, PIC Slot 2) Entered yellow > > memory zone 500 ms > > ago > > May 30 17:39:28 (FPC Slot 0, PIC Slot 2) Entered green > > memory zone 500 ms > > ago > > May 30 17:39:29 (FPC Slot 0, PIC Slot 2) Entered yellow > > memory zone 500 ms > > ago > > May 30 17:39:29 (FPC Slot 0, PIC Slot 2) Entered green > > memory zone 500 ms > > ago > > May 30 17:39:33 (FPC Slot 0, PIC Slot 2) Entered yellow > > memory zone 900 ms > > ago > > May 30 17:39:34 (FPC Slot 0, PIC Slot 2) Entered yellow > > memory zone 900 ms > > ago > > May 30 17:39:34 (FPC Slot 0, PIC Slot 2) CPU utilization > > (86.59 percent) > > exceeded threshold > > May 30 17:39:35 (FPC Slot 0, PIC Slot 2) Entered yellow > > memory zone 800 ms > > ago > > May 30 17:39:36 (FPC Slot 0, PIC Slot 2) Entered yellow > > memory zone 800 ms > > ago > > May 30 17:39:36 (FPC Slot 0, PIC Slot 2) CPU utilization > > (83.15 percent) ok > > May 30 17:39:37 (FPC Slot 0, PIC Slot 2) Entered yellow > > memory zone 300 ms > > ago > > May 30 17:39:37 (FPC Slot 0, PIC Slot 2) Entered green > > memory zone 300 ms > > ago > > May 30 17:39:41 (FPC Slot 0, PIC Slot 2) CPU utilization > > (88.63 percent) > > exceeded threshold > > May 30 17:39:44 (FPC Slot 0, PIC Slot 2) CPU utilization > > (81.04 percent) ok > > > > > > Has anyone any experience about that messages? > > > > > > Thanks, > > > > > > Gokhan > > ___ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > > > > -- > Gokhan Gumus JNCIS #1255 > -- Gokhan Gumus JNCIS #1255 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Strange error on AS PIC
Hi guys, I have a strange problem with our AS PIC.We are using that AS PIC card for NAT operation for our L3 VPN customers.In these days NAT operation is not working on some specific customers.I am using JUNOS 7.6 R4.3. When NAT doesnt work,i get this output. [EMAIL PROTECTED]> show services stateful-firewall flows service-set ABC *error: libservicesui: ipc_pipe_read() failed - Unknown error: 0 -> ?* ** ** Also i get these outputs from my syslog messages when i got these error. May 30 17:39:08 (FPC Slot 0, PIC Slot 2) Entered orange memory zone 300 ms ago May 30 17:39:17 (FPC Slot 0, PIC Slot 2) Entered yellow memory zone 800 ms ago May 30 17:39:24 (FPC Slot 0, PIC Slot 2) Entered orange memory zone 800 ms ago May 30 17:39:25 (FPC Slot 0, PIC Slot 2) Entered yellow memory zone 300 ms ago May 30 17:39:27 (FPC Slot 0, PIC Slot 2) Entered yellow memory zone 300 ms ago May 30 17:39:27 (FPC Slot 0, PIC Slot 2) Entered green memory zone 300 ms ago May 30 17:39:28 (FPC Slot 0, PIC Slot 2) Entered yellow memory zone 500 ms ago May 30 17:39:28 (FPC Slot 0, PIC Slot 2) Entered green memory zone 500 ms ago May 30 17:39:29 (FPC Slot 0, PIC Slot 2) Entered yellow memory zone 500 ms ago May 30 17:39:29 (FPC Slot 0, PIC Slot 2) Entered green memory zone 500 ms ago May 30 17:39:33 (FPC Slot 0, PIC Slot 2) Entered yellow memory zone 900 ms ago May 30 17:39:34 (FPC Slot 0, PIC Slot 2) Entered yellow memory zone 900 ms ago May 30 17:39:34 (FPC Slot 0, PIC Slot 2) CPU utilization (86.59 percent) exceeded threshold May 30 17:39:35 (FPC Slot 0, PIC Slot 2) Entered yellow memory zone 800 ms ago May 30 17:39:36 (FPC Slot 0, PIC Slot 2) Entered yellow memory zone 800 ms ago May 30 17:39:36 (FPC Slot 0, PIC Slot 2) CPU utilization (83.15 percent) ok May 30 17:39:37 (FPC Slot 0, PIC Slot 2) Entered yellow memory zone 300 ms ago May 30 17:39:37 (FPC Slot 0, PIC Slot 2) Entered green memory zone 300 ms ago May 30 17:39:41 (FPC Slot 0, PIC Slot 2) CPU utilization (88.63 percent) exceeded threshold May 30 17:39:44 (FPC Slot 0, PIC Slot 2) CPU utilization (81.04 percent) ok Has anyone any experience about that messages? Thanks, Gokhan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Virtual Router
Hi Nancy, You can find some information in there. http://www.juniper.net/techpubs/software/junos/junos73/swconfig73-routing/html/logical-router-overview.html Gokhan On 5/29/07, [EMAIL PROTECTED] < [EMAIL PROTECTED]> 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 >[EMAIL PROTECTED] > > You can reach the person managing the list at >[EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of juniper-nsp digest..." > > > Today's Topics: > > 1. as4byte and JunOS (Sergey) > 2. Re: as4byte and JunOS (Erdem Sener) > 3. Virtual Router (Kucinskas, Nancy (Nancy)) > > > -- > > Message: 1 > Date: Tue, 29 May 2007 17:41:28 +0500 > From: Sergey <[EMAIL PROTECTED]> > Subject: [j-nsp] as4byte and JunOS > To: juniper-nsp@puck.nether.net > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > Hello. > > Has JunOS supported as4byte now ? Which version can I need ? > > -- > Regards, > Sergey > > > -- > > Message: 2 > Date: Tue, 29 May 2007 16:01:17 +0200 > From: "Erdem Sener" <[EMAIL PROTECTED]> > Subject: Re: [j-nsp] as4byte and JunOS > To: Sergey <[EMAIL PROTECTED]> > Cc: juniper-nsp@puck.nether.net > Message-ID: ><[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Sergey, > > 4 byte ASN is currently no supported in JUNOS. > > HTH > Erdem > > On 5/29/07, Sergey <[EMAIL PROTECTED]> wrote: > > Hello. > > > > Has JunOS supported as4byte now ? Which version can I need ? > > > > -- > > Regards, > > Sergey > > ___ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > > -- > > Message: 3 > Date: Tue, 29 May 2007 10:16:50 -0500 > From: "Kucinskas, Nancy \(Nancy\)" <[EMAIL PROTECTED]> > Subject: [j-nsp] Virtual Router > To: > Message-ID: ><[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > Hello, > Does anybody know how to configure virtual routers on Juniper M320? Or > where can I find information about that? > > Thanks in advance. > Nancy > > > > -- > > ___ > juniper-nsp mailing list > juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > End of juniper-nsp Digest, Vol 54, Issue 37 > *** > -- Gokhan Gumus JNCIS #1255 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] juniper-nsp Digest, Vol 54, Issue 20
Hi all, We have a MPLS backbone for L3 VPN customers.Our some customers take redundant links for in case of any failure.We use static routing for PE-CE connectivity.When one of CE facing link fails,we are configuring a new static routes for that specific destinations that is pointing redundant link manually.But customer requests to want this operations automatically.I know that can be when using dynamic routing protocols on PE-CE connectivity.But i dont know how can i implement that request when using static routing on PE-CE connectivity. Thanks, Gokhan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Filter-Based Forwarding issue
Hi Gniewko
Here is a sample config what should you do...
R1-R2
.110.0.0.0/24
.2
For example your source based traffic's direction is from R2 to
R1.Youshould add that kind of config on your router.
xxx <[EMAIL PROTECTED]>> show configuration
routing-instances INSTANCE_C
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 10.0.0.1;
And then you must make an MPLS LSP like that;
xxx <[EMAIL PROTECTED]>> show configuration protocols mpls
label-switched-path R2-to-R1 {
from 10.0.0.2;
to 10.0.0.1;
Gokhan Gumus
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] AS PIC CPU usage problem
Hi all, We have a M10i router that running on 7.3 R2.7 version.Also we have an ASPIC card installed on.We use this card for L3 services packages.That card is used for using NAT services to the L3 VPN customers.In these days when i check AS CPU usage with " *show services service-sets summary* " , i always see CPU usage %90-91 percent. Also we have always problems with natted customer and i think that this problem is regarding that cpu usage.Is there any opinion about that high CPU usage? Thanks, Gokhan Gumus ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] bandwidth limiting on 4 port Fast Ethernet
Hi all,
We have 4-port Fast Ethernet PIC on our M-series router.I am trying to
limit a certain customer on Fast Ethernet PIC to (for example) 6
Mbps.Iconfigured a policer like that:
filter test {
policer p1 {
if-exceeding {
bandwidth-limit 6m;
burst-size-limit 1m;
}
then discard;
But it is not working and then i see some options on juniper web
site.Underfasthether-options there is a command
"ingress-rate-limit".But it is working
on 12-port,48-port,etc PICs.We have 4-port Fast Ethernet.
Is anybody can help me about how can i limit traffic on 4-port Fast
Ethernet?
Thanks and best regards,
Gokhan Gumus
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] L3 VPN load balancing problem
Hi all, I have a problem with configuring load-balancing on L3 VPN.Topology like that; 2 links Juniper M10i router(PE-A)Juniper M10i router(PE-B)|-| | |-| Cisco (CE router)-->customer local | network A || Customer local network(B) When any customer on local network B want to reach to customer local network A,i want to make load-balancing on links between Juniper M10i PE-B router and Cisco CE router without running any dynamic routing protocols.I want to make load-balancing when traffic goes from Juniper M10i PE-B router to Cisco router on my two links. Is there any sample configuration about that issue? King regards, Gokhan Gumus ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
