[j-nsp] 1000Base-T SFP shows Link Up without cable inserted
I've just upgraded two of my MX5-T boxes to 11.4R7.5 and after that my 3rd party 1000Base-T SFP (Transmode originals based on Finisar) started to show Link Up as soon as the SFP is inserted (no cable inserted). On 11.2R5.4 it worked as it should. 11.4R1.14 that the boxes came with was also broken. Bug or feature? Has anyone used any Juniper original 1000Base-T SFPs on the MX-5/10/40/80-T platform with JunOS 11.4? masun@solir1 show version Hostname: solir1 Model: mx5-t JUNOS Base OS boot [11.4R7.5] JUNOS Base OS Software Suite [11.4R7.5] JUNOS Kernel Software Suite [11.4R7.5] JUNOS Crypto Software Suite [11.4R7.5] JUNOS Packet Forwarding Engine Support (MX80) [11.4R7.5] JUNOS Online Documentation [11.4R7.5] JUNOS Routing Software Suite [11.4R7.5] masun@solir1 show chassis pic fpc-slot 1 pic-slot 1 FPC slot 1, PIC slot 1 information: Type 10x 1GE(LAN) SFP StateOnline PIC version 2.26 Uptime 2 days, 23 hours, 7 minutes, 20 seconds PIC port information: FiberXcvr vendor Port Cable typetype Xcvr vendorpart number Wavelength 0 GIGE 1000Tn/a FINISAR CORP. FCLF8521P2BTL-TR n/a masun@solir1 show interfaces ge-1/1/0 Physical interface: ge-1/1/0, Enabled, Physical link is Up Interface index: 158, SNMP ifIndex: 526 Description: Link sthir2 for Logical Systems (VPLS Lab) Link-level type: Ethernet, MTU: 2000, Speed: 1000mbps, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x0 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Current address: 08:81:f4:81:26:68, Hardware address: 08:81:f4:81:26:68 Last flapped : 2013-03-31 15:11:42 EDT (00:04:46 ago) Input rate : 0 bps (0 pps) Output rate: 0 bps (0 pps) Active alarms : None Active defects : None Interface transmit statistics: Disabled ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX5-T VPLS fowarding problem
I've just built a new MPLS network consisting of 6 MX5-T routers using
RSVP signaled LSPs where all routers work a combined P/PE routers.
The core network has been running fine for several weeks. L3VPN works fine.
Now I try to establish a VPLS Point-to-Point tunnel between two adjacent
routers called solir1 and solir2. Outside of xe-0/0/3 of each router
there is access switch called solis1 and solis2, where I for the testing
purpose has configured an IP in the same subnet on each of the switches:
solis1 config:
interface Vlan1144
ip address 10.155.9.1 255.255.255.0
!
interface TenGigabitEthernet1/49
description type=core,subtype=isc,peer=solir1,peerint=xe-0/0/3
switchport mode trunk
!
solis2 config:
interface Vlan1244
ip address 10.155.9.2 255.255.255.0
!
interface TenGigabitEthernet1/49
description type=core,subtype=isc,peer=solir2,peerint=xe-0/0/3
switchport mode trunk
!
solir1 config:
masun@solir1 show configuration groups | find vpls70134
vpls70134 {
interfaces {
xe-0/0/3 {
unit 1144 {
description vpls70134 Test VPLS solir1-solir2;
encapsulation vlan-vpls;
vlan-id 1144;
family vpls {
policer {
input vpls70134-100m;
output vpls70134-100m;
}
}
}
}
}
firewall {
policer vpls70134-100m {
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 1m;
}
then discard;
}
}
routing-instances {
vpls70134 {
instance-type vpls;
interface xe-0/0/3.1144;
route-distinguisher 49079:70134;
vrf-target target:49079:70134;
protocols {
vpls {
site-range 10;
mac-table-size {
1024;
}
mac-statistics;
no-tunnel-services;
site solis1-vpls70134 {
site-identifier 1;
interface xe-0/0/3.1144;
}
}
}
}
}
}
masun@solir1 show configuration interfaces xe-0/0/3
description type=core,subtype=isc,peer=solis1,peerint=Te1/49;
enable;
traps;
vlan-tagging;
mtu 2000;
encapsulation flexible-ethernet-services;
masun@solir2 show configuration groups | find vpls70134
vpls70134 {
interfaces {
xe-0/0/3 {
unit 1244 {
description vpls70134 Test VPLS solir1-solir2;
encapsulation vlan-vpls;
vlan-id 1244;
family vpls {
policer {
input vpls70134-100m;
output vpls70134-100m;
}
}
}
}
}
firewall {
policer vpls70134-100m {
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 1m;
}
then discard;
}
}
routing-instances {
vpls70134 {
instance-type vpls;
interface xe-0/0/3.1244;
route-distinguisher 49079:70134;
vrf-target target:49079:70134;
protocols {
vpls {
site-range 10;
mac-table-size {
1024;
}
mac-statistics;
no-tunnel-services;
site solis2-vpls70134 {
site-identifier 2;
interface xe-0/0/3.1244;
}
}
}
}
}
}
masun@solir2 show configuration interfaces xe-0/0/3
description type=core,subtype=isc,peer=solis2,peerint=Te1/49;
enable;
traps;
vlan-tagging;
mtu 2000;
encapsulation flexible-ethernet-services;
The VPLS connection is up on each side:
masun@solir2 show vpls connections
...
Instance: vpls70134
Local site: solis2-vpls70134 (2)
connection-site Type St Time last up # Up trans
1 rmt Up Mar 28 16:11:30 2013 1
Remote PE: 89.107.216.238, Negotiated control-word: No
Incoming label: 262145, Outgoing label: 262146
Local interface: lsi.1048832, Status: Up, Encapsulation: VPLS
Description: Intf - vpls vpls70134 local site 2 remote site 1
And the MAC address of my test switches are learned by each PE router:
masun@solir2 show vpls mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE
MAC)
Routing instance : vpls70134
Bridging domain : __vpls70134__, VLAN : NA
MAC MAC Logical
address flagsinterface
e0:2f:6d:d4:75:70 D,SE xe-0/0/3.1244
Re: [j-nsp] MX5-T VPLS fowarding problem
Hi,
I got an off-list message from Diogo saying that the logical interface
(VLAN ID) on each side must be the same, unless you do some
pop/push/swap magic. Changing that did solve the problem! I still don't
see why though. I only use the VLAN locally on each site to separate the
traffic between multiple customers in the access switches, so the VLAN
tag should never be included in the actual frames forwarded between the
routers.
With that solved, yes, I could then put the chassis fpc 0 pic 0
tunnel-services back and remove no-tunnel-services from the vpls config
and it still rocks :)
If I have a 10G backbone, and would like to able to transport a number
of 1G VPLS circuits, should I set tunnel-services bandwidth to 10G, or
does that have a big negative performance impact on something else?
Thanks both to Diogo and Caillin for your replies.
On 03/29/2013 12:40 PM, Caillin Bathern wrote:
Hi Mathias,
First try adding set chassis fpc XX pic XX tunnel-services
bandwidth 1g|10G. You then have tunnel services on the MX80. Can't
remember if this has any caveats on being done to a live system though..
Also check show route forwarding-table table vpls70134 extensive to
check for forwarding entries.
Cheers,
Caillin
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mathias
Sundman
Sent: Friday, 29 March 2013 9:11 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] MX5-T VPLS fowarding problem
I've just built a new MPLS network consisting of 6 MX5-T routers using
RSVP signaled LSPs where all routers work a combined P/PE routers.
The core network has been running fine for several weeks. L3VPN works
fine.
Now I try to establish a VPLS Point-to-Point tunnel between two adjacent
routers called solir1 and solir2. Outside of xe-0/0/3 of each router
there is access switch called solis1 and solis2, where I for the testing
purpose has configured an IP in the same subnet on each of the switches:
solis1 config:
interface Vlan1144
ip address 10.155.9.1 255.255.255.0
!
interface TenGigabitEthernet1/49
description type=core,subtype=isc,peer=solir1,peerint=xe-0/0/3
switchport mode trunk
!
solis2 config:
interface Vlan1244
ip address 10.155.9.2 255.255.255.0
!
interface TenGigabitEthernet1/49
description type=core,subtype=isc,peer=solir2,peerint=xe-0/0/3
switchport mode trunk
!
solir1 config:
masun@solir1 show configuration groups | find vpls70134
vpls70134 {
interfaces {
xe-0/0/3 {
unit 1144 {
description vpls70134 Test VPLS solir1-solir2;
encapsulation vlan-vpls;
vlan-id 1144;
family vpls {
policer {
input vpls70134-100m;
output vpls70134-100m;
}
}
}
}
}
firewall {
policer vpls70134-100m {
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 1m;
}
then discard;
}
}
routing-instances {
vpls70134 {
instance-type vpls;
interface xe-0/0/3.1144;
route-distinguisher 49079:70134;
vrf-target target:49079:70134;
protocols {
vpls {
site-range 10;
mac-table-size {
1024;
}
mac-statistics;
no-tunnel-services;
site solis1-vpls70134 {
site-identifier 1;
interface xe-0/0/3.1144;
}
}
}
}
}
}
masun@solir1 show configuration interfaces xe-0/0/3 description
type=core,subtype=isc,peer=solis1,peerint=Te1/49;
enable;
traps;
vlan-tagging;
mtu 2000;
encapsulation flexible-ethernet-services;
masun@solir2 show configuration groups | find vpls70134
vpls70134 {
interfaces {
xe-0/0/3 {
unit 1244 {
description vpls70134 Test VPLS solir1-solir2;
encapsulation vlan-vpls;
vlan-id 1244;
family vpls {
policer {
input vpls70134-100m;
output vpls70134-100m;
}
}
}
}
}
firewall {
policer vpls70134-100m {
if-exceeding {
bandwidth-limit 100m;
burst-size-limit 1m;
}
then discard;
}
}
routing-instances {
vpls70134 {
instance-type vpls;
interface xe-0/0/3.1244;
route-distinguisher 49079:70134;
vrf
Re: [j-nsp] MX5-T VPLS fowarding problem
On 03/29/2013 02:36 PM, sth...@nethelp.no wrote: I got an off-list message from Diogo saying that the logical interface (VLAN ID) on each side must be the same, unless you do some pop/push/swap magic. Changing that did solve the problem! I still don't see why though. I only use the VLAN locally on each site to separate the traffic between multiple customers in the access switches, so the VLAN tag should never be included in the actual frames forwarded between the routers. The BGP-based VPLS RFC (RFC 4761) specifies in section 4.1: Ethernet frames received from CE devices are encapsulated for transmission over the packet switched network connecting the PEs. The encapsulation is as in [7]. OK, then I understand. I consider the customer switch/router that they attach outside my access-switch the CE Device, while the RFC consider the first device connected to the PE router the CE device regardless of how it's used, and I guess that's where the confusion is created. where reference 7 is RFC 4448, which in its turn says: In Ethernet PW operates in one of two modes: raw mode or tagged mode. In tagged mode, each frame MUST contain at least one 802.1Q [802.1Q] VLAN tag, and the tag value is meaningful to the NSPs at the two PW termination points. Tagged mode is what you get if you have a VLAN subinterface and you don't do anything specific to remove the tag. Thus you should *expect* the VLAN tag to be included. It would have been possible for Juniper to automatically translate VLAN IDs on output - this is what for instance Cisco does on single- tagged pseudowires. Such automatic translation means that the VLAN IDs don't have to match. However, Juniper has chosen not to do such automatic translation. My goal is to use Q-in-Q on the trunk between my PE router and my access-switch, and then q-tunnel mode on the customer port to allow him to transport any VLANs he want inside the VPLS tunnel. So, if I want to achieve that without having to use the same outer VLAN ID between my PE and access-switch on each side, what do I have todo? Can I just pop the ingress outer tag (my S-VLAN) and consider it a RAW mode PW, or will it not allow the customer VLANs to be transported then? or would I have to swap in incoming S-VLAN to a common VLAN between my PEs and then swap it back to the locally unique S-VLAN used at each site? Thx ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX5-T VPLS fowarding problem
On 03/29/2013 12:40 PM, Caillin Bathern wrote: First try adding set chassis fpc XX pic XX tunnel-services bandwidth 1g|10G. You then have tunnel services on the MX80. Can't remember if this has any caveats on being done to a live system though.. Can someone explain the benefits of using tunnel-services vs no-tunnel-services on the MX80 platform for VPLS services? With a 10G backbone using 3-4 of the built-in 10G interfaces, and an expected VPLS use of 1-4G of bandwidth, what would be the recommended config? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
