[j-nsp] vlan-ccc between ACX5048 and EX4500

[Jay Hanke]

I'm having an issue where I'm unable to pass traffic through a
vlan-ccc between an ACX5048 and an EX4500. Other circuits on same
boxes are working fine. The other circuits are ACX to ACX and EX to
EX.

PE1 (ex4500)


l2circuit {
neighbor 10.200.xx.xy {
interface xe-0/0/1.517 {
virtual-circuit-id 1171;
mtu 9000;
encapsulation-type ethernet-vlan;
}
}
}

xe-0/0/1 {
vlan-tagging;
mtu 9216;
encapsulation vlan-ccc;
unit 517 {
encapsulation vlan-ccc;
vlan-id 517;
}
}

PE2 (ACX5048):

l2circuit {
neighbor 10.200.xx.xx {
interface xe-0/0/46.517 {
virtual-circuit-id 1171;
mtu 9000;
encapsulation-type ethernet-vlan;
}
}
}

xe-0/0/46 {

vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;

unit 517 {
encapsulation vlan-ccc;
vlan-id 517;
}
}

I'm learning mac-addresses through the link on the PE2 side.

The interface connected on the PE1 side doesn't learn anything.

show l2circuit con shows the PW up on both PE devices.

I've reloaded software on the EX4500 with the same result. There is
one P router between the PE devices.

All my existing PW are between EX4500 or between ACX. We don't have
any working between systems with different models acting as PE
devices. But quite a few working where PE devices are the same type.

Any ideas?

Jay
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] traceroute in mpls vpn's not showing P hops

[Chris Burton]

The command you are looking for "set protocols mpls icmp-tunneling", 
also need to make sure you have LSP's in both directions.


-C


On 08/22/2017 06:39 PM, Aaron Gould wrote:

I know that this is a known thing with mpls networks, and there are a few
tricks with no decrement ttl or no propagate ttl to cause P cloud to be
completely invisible. but is there a way to do the opposite?...that is, is
there a way to cause the P routers to be seen on traceroute ?  I understand
that ttl expired in transit messages need to be able to be sent back to the
CE that sent the low-ttl packets to begin with and since p router probably
won't have the vrf-specific routes of that ce, then, well.. I guess I'm
wondering if there's some trick command that allows the p router to send
back the ttl-expired-in-transit messages simply via the same mpls label
values via the lsp that they arrived on. or whoever it would work. ?

  


- trace initiated be CE r1

  


r1@lab-mx104:r1> traceroute 1.1.10.2 wait 1

traceroute to 1.1.10.2 (1.1.10.2), 30 hops max, 40 byte packets

1  1.1.0.2 (1.1.0.2)  0.539 ms  0.646 ms  0.472 ms   < PE

  2  * * *
< P

3  * * *
< P

4  * * *
< P

5  * * *
< P

6  * * *
< P

7  1.1.10.1 (1.1.10.1)  0.611 ms  0.565 ms  0.534 ms   < PE

8  1.1.10.2 (1.1.10.2)  0.569 ms  0.616 ms  0.700 ms   < CE

  


- Aaron Gould

  


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp




___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] traceroute in mpls vpn's not showing P hops

[Skyler Blumer]

There's a knob called icmp tunneling. P routers push the TTL expired 
messages along the LSP to the egress PE, which has a route back to the 
source CE in its VRF.



On 8/22/17 9:39 PM, Aaron Gould wrote:

I know that this is a known thing with mpls networks, and there are a few
tricks with no decrement ttl or no propagate ttl to cause P cloud to be
completely invisible. but is there a way to do the opposite?...that is, is
there a way to cause the P routers to be seen on traceroute ?  I understand
that ttl expired in transit messages need to be able to be sent back to the
CE that sent the low-ttl packets to begin with and since p router probably
won't have the vrf-specific routes of that ce, then, well.. I guess I'm
wondering if there's some trick command that allows the p router to send
back the ttl-expired-in-transit messages simply via the same mpls label
values via the lsp that they arrived on. or whoever it would work. ?

  


- trace initiated be CE r1

  


r1@lab-mx104:r1> traceroute 1.1.10.2 wait 1

traceroute to 1.1.10.2 (1.1.10.2), 30 hops max, 40 byte packets

1  1.1.0.2 (1.1.0.2)  0.539 ms  0.646 ms  0.472 ms   < PE

  2  * * *
< P

3  * * *
< P

4  * * *
< P

5  * * *
< P

6  * * *
< P

7  1.1.10.1 (1.1.10.1)  0.611 ms  0.565 ms  0.534 ms   < PE

8  1.1.10.2 (1.1.10.2)  0.569 ms  0.616 ms  0.700 ms   < CE

  


- Aaron Gould

  


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] traceroute in mpls vpn's not showing P hops

[Aaron Gould]

I know that this is a known thing with mpls networks, and there are a few
tricks with no decrement ttl or no propagate ttl to cause P cloud to be
completely invisible. but is there a way to do the opposite?...that is, is
there a way to cause the P routers to be seen on traceroute ?  I understand
that ttl expired in transit messages need to be able to be sent back to the
CE that sent the low-ttl packets to begin with and since p router probably
won't have the vrf-specific routes of that ce, then, well.. I guess I'm
wondering if there's some trick command that allows the p router to send
back the ttl-expired-in-transit messages simply via the same mpls label
values via the lsp that they arrived on. or whoever it would work. ?

 

- trace initiated be CE r1

 

r1@lab-mx104:r1> traceroute 1.1.10.2 wait 1

traceroute to 1.1.10.2 (1.1.10.2), 30 hops max, 40 byte packets

1  1.1.0.2 (1.1.0.2)  0.539 ms  0.646 ms  0.472 ms   < PE 

 2  * * *
< P

3  * * *
< P

4  * * *
< P

5  * * *
< P

6  * * *
< P

7  1.1.10.1 (1.1.10.1)  0.611 ms  0.565 ms  0.534 ms   < PE

8  1.1.10.2 (1.1.10.2)  0.569 ms  0.616 ms  0.700 ms   < CE

 

- Aaron Gould

 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RE-S-X6 experience

[Rolf Hanßen]

Hello Andrey,

we use one pair since December for an new installation running 16.1R4-S2.2
currently.
The setup is quite basic stuff without curiosities (full table in inet.0,
3.6M routes in rib, ISIS+BGP, a few VPLS instances, a bit VRRP and a few
interface filters).
We hit one major bug (PR1240960, not RE specific, but annoying that
Juniper needed a month to identify an already known bug) and some minor
things, but nothing that would keep me away from using it again.

kind regards
Rolf

> Reviving old thread, has anybody already tried/tested new RE-S-X6 and
> can share an experience about it, any gotchas?
>
> Current recommended Junos version 15.1F6-S6/15.1R6 for MX already
> covers the first supported release 15.1F4,16.1. Is there something why
> we should stay aside from it?
>
> --
> Kind regards,
> Andrey Kostin

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] RE-S-X6 experience

[Andrey Kostin]

Reviving old thread, has anybody already tried/tested new RE-S-X6 and 
can share an experience about it, any gotchas?


Current recommended Junos version 15.1F6-S6/15.1R6 for MX already 
covers the first supported release 15.1F4,16.1. Is there something why 
we should stay aside from it?


--
Kind regards,
Andrey Kostin
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Zabbix

[Darren O'Connor]

We switched to Zabbix in a previous job I had. It was pretty good. We monitored 
Juniper SRX/MX/PTX, ScreenOS, IOS, IOS-XR, Brocade, and plenty of servers too. 
Never had an issue with it.


Darren O'Connor
www.mellowd.co.uk/ccie



From: juniper-nsp  on behalf of John Brown 

Sent: 19 August 2017 21:05
To: Aaron Gould
Cc: juniper-nsp
Subject: Re: [j-nsp] Zabbix

We use a combo of LibreNMS and Zabbix
Both work quite well and solve slightly different needs.
If Zabbix had the more free form search that LibreNMS has, we would
probably just use zabbix

Monitoring, Juniper, UBNT, Tik, Cisco, Servers, various PtP licensed
wireless, adtran gpon and other devices.



On Sat, Aug 19, 2017 at 10:42 AM, Aaron Gould  wrote:
> Is it better than solarwinds ?  Asking since the ISP I work for relies 
> heavily on solarwinds.
>
> -Aaron
>
> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
> Paul Stewart
> Sent: Friday, August 18, 2017 5:15 AM
> To: Matthew Taylor
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Zabbix
>
> How do you like Zabbix and what else do you monitor with it?  We are in midst 
> of considering it (along with others) to replace Solarwinds….
>
> Thanks,
> Paul
>
>> On Aug 18, 2017, at 2:04 AM, Matthew Taylor  wrote:
>>
>> Hi,
>>
>> Heavily use Zabbix with Juniper EX/MX and SRX devices.
>>
>> Most of our templates are customised, although you can find a lot from 
>> Zabbix Share.
>>
>> https://share.zabbix.com/search?searchword=Juniper&search_cat=1
>>
>> Cheers,
>> Matt.
>>
>> On 18/8/17 15:25, jayshankar nair via juniper-nsp wrote:
>>> Hi,I am currently using zabbix(www.zabbix.com) for 
>>> monitoring of routers. Has anybody on this forum use zabbix. In zabbix 
>>> there is a concept called template for integration of mibs.
>>> Please advise.
>>>
>>> Thanks,Jayshankar
>>> ___
>>> 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
___
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