Re: [j-nsp] Link Utilization miss match between two MX boxes.
Hi David. we have got MX960 and MX480. we suspect MX960 showing traffic on CLI is correct. but not MX480. when we using 'moniter' command it shows the same data with 'show interface' @> show version Hostname: Model: mx480 JUNOS Base OS boot [10.0R3.10] JUNOS Base OS Software Suite [10.0R3.10] JUNOS Kernel Software Suite [10.0R3.10] JUNOS Crypto Software Suite [10.0R3.10] JUNOS Packet Forwarding Engine Support (M/T Common) [10.0R3.10] JUNOS Packet Forwarding Engine Support (MX Common) [10.0R3.10] JUNOS Online Documentation [10.0R3.10] JUNOS Voice Services Container package [10.0R3.10] JUNOS Border Gateway Function package [10.0R3.10] JUNOS Services AACL Container package [10.0R3.10] JUNOS Services LL-PDF Container package [10.0R3.10] JUNOS Services Stateful Firewall [10.0R3.10] JUNOS AppId Services [10.0R3.10] JUNOS IDP Services [10.0R3.10] JUNOS Routing Software Suite [10.0R3.10] JUNOS Web Management [10.0R3.10] @> show version Hostname: Model: mx960 JUNOS Base OS boot [10.0R3.10] JUNOS Base OS Software Suite [10.0R3.10] JUNOS Kernel Software Suite [10.0R3.10] JUNOS Crypto Software Suite [10.0R3.10] JUNOS Packet Forwarding Engine Support (M/T Common) [10.0R3.10] JUNOS Packet Forwarding Engine Support (MX Common) [10.0R3.10] JUNOS Online Documentation [10.0R3.10] JUNOS Voice Services Container package [10.0R3.10] JUNOS Border Gateway Function package [10.0R3.10] JUNOS Services AACL Container package [10.0R3.10] JUNOS Services LL-PDF Container package [10.0R3.10] JUNOS Services Stateful Firewall [10.0R3.10] JUNOS AppId Services [10.0R3.10] JUNOS IDP Services [10.0R3.10] JUNOS Routing Software Suite [10.0R3.10] JUNOS Web Management [10.0R3.10] *Soongoon Lee** /** CCIE #17724* On Thu, Sep 29, 2011 at 12:02 PM, David Ball wrote: > What MX platform and software version? And what's preventing the > 'monitor interface ge-0/0/6' command from being used ? Would be > interesting to see if its values matched. > > David > > > On 28 September 2011 21:36, Soon Lee wrote: > > HI experts! > > > > we are using MPLS + TE, VPLS and L3 VPN > > > > I found some interfaces miss match between two Juniper MX boxes as below. > > > > but, no traffic dropping. just cant do monitoring bandwidth on an > interface. > > > > > > anyone know? how to fix it? or any suggestion? > > > > > > > > > > x@> show interfaces ge-0/0/6 > > > > Physical interface: ge-0/0/6, Enabled, Physical link is Up > > > > Interface index: 138, SNMP ifIndex: 124 > > > > Description: *** *** > > > > Link-level type: Ethernet, MTU: 9192, Speed: 1000mbps, BPDU Error: None, > > MAC-REWRITE Error: None, Loopback: Disabled, > > > > Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: > > Disabled, Remote fault: Online, > > > > Speed-negotiation: Disabled, Auto-MDIX: Enabled > > > > Device flags : Present Running > > > > Interface flags: SNMP-Traps Internal: 0x4000 > > > > Link flags : None > > > > CoS queues : 8 supported, 8 maximum usable queues > > > > Current address: 00:23:9c:9d:58:06, Hardware address: 00:23:9c:9d:58:06 > > > > Last flapped : 2011-07-25 04:36:57 MYT (8w1d 10:39 ago) > > > > Input rate : 26208 bps (35 pps) > > > > Output rate: 69690096 bps (38377 pps) > > > > Active alarms : None > > > > Active defects : None > > > > > > > > Logical interface ge-0/0/6.0 (Index 73) (SNMP ifIndex 130) > > > >Flags: SNMP-Traps 0x400 Encapsulation: ENET2 > > > >Input packets : 98045344 > > > >Output packets: 172730795842 > > > >Protocol inet, MTU: 9178 > > > > Flags: Is-Primary > > > > Addresses, Flags: Is-Preferred Is-Primary > > > >Destination: x.x.x.x/x, Local: x.x.x.x, Broadcast: x.x.x.x > > > >Protocol mpls, MTU: 9166 > > > > Flags: Is-Primary > > > >Protocol multiservice, MTU: Unlimited > > > > Flags: Is-Primary > > > > > > > > > > @> show interfaces ge-0/0/6 > > > > Physical interface: ge-0/0/6, Enabled, Physical link is Up > > > > Interface index: 138, SNMP ifIndex: 155 > > > > Description: *** *** > > > > Link-level type: Ethernet, MTU: 9192, Speed: 1000mbps, BPDU Error: None, > > MAC-REWRITE Error: None, Loopback: Disabled, > > > > Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: > > Enabled, Remote fault: Online, Speed-negotiation: Disabled, > > > > Auto-MDIX: Enabled > > > > Device flags : Present Running > > > > Interface flags: SNMP-Traps Internal: 0x4000 > > > > Link flags : None > > > > CoS queues : 8 supported, 8 maximum usable queues > > > > Current address: 00:23:9c:5b:d0:06, Hardware address: 00:23:9c:5b:d0:06 > > > > Last flapped : 2011-07-21 06:45:45 MYT (8w5d 09:33 ago) > > > > Input rate : 78415320 bps (42143 pps) > > > > Output rate: 358686688 bps (47893 pps) > > > > Active alarms : None > > > > Active defects : None > > > > > > > > Logical interface ge-0/0/6.0 (Index 73) (SNMP ifIndex 217) > > > >Flags: SNMP-Tra
Re: [j-nsp] Link Utilization miss match between two MX boxes.
What MX platform and software version? And what's preventing the 'monitor interface ge-0/0/6' command from being used ? Would be interesting to see if its values matched. David On 28 September 2011 21:36, Soon Lee wrote: > HI experts! > > we are using MPLS + TE, VPLS and L3 VPN > > I found some interfaces miss match between two Juniper MX boxes as below. > > but, no traffic dropping. just cant do monitoring bandwidth on an interface. > > > anyone know? how to fix it? or any suggestion? > > > > > x@> show interfaces ge-0/0/6 > > Physical interface: ge-0/0/6, Enabled, Physical link is Up > > Interface index: 138, SNMP ifIndex: 124 > > Description: *** *** > > Link-level type: Ethernet, MTU: 9192, Speed: 1000mbps, BPDU Error: None, > MAC-REWRITE Error: None, Loopback: Disabled, > > Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: > Disabled, Remote fault: Online, > > Speed-negotiation: Disabled, Auto-MDIX: Enabled > > Device flags : Present Running > > Interface flags: SNMP-Traps Internal: 0x4000 > > Link flags : None > > CoS queues : 8 supported, 8 maximum usable queues > > Current address: 00:23:9c:9d:58:06, Hardware address: 00:23:9c:9d:58:06 > > Last flapped : 2011-07-25 04:36:57 MYT (8w1d 10:39 ago) > > Input rate : 26208 bps (35 pps) > > Output rate : 69690096 bps (38377 pps) > > Active alarms : None > > Active defects : None > > > > Logical interface ge-0/0/6.0 (Index 73) (SNMP ifIndex 130) > > Flags: SNMP-Traps 0x400 Encapsulation: ENET2 > > Input packets : 98045344 > > Output packets: 172730795842 > > Protocol inet, MTU: 9178 > > Flags: Is-Primary > > Addresses, Flags: Is-Preferred Is-Primary > > Destination: x.x.x.x/x, Local: x.x.x.x, Broadcast: x.x.x.x > > Protocol mpls, MTU: 9166 > > Flags: Is-Primary > > Protocol multiservice, MTU: Unlimited > > Flags: Is-Primary > > > > > @> show interfaces ge-0/0/6 > > Physical interface: ge-0/0/6, Enabled, Physical link is Up > > Interface index: 138, SNMP ifIndex: 155 > > Description: *** *** > > Link-level type: Ethernet, MTU: 9192, Speed: 1000mbps, BPDU Error: None, > MAC-REWRITE Error: None, Loopback: Disabled, > > Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: > Enabled, Remote fault: Online, Speed-negotiation: Disabled, > > Auto-MDIX: Enabled > > Device flags : Present Running > > Interface flags: SNMP-Traps Internal: 0x4000 > > Link flags : None > > CoS queues : 8 supported, 8 maximum usable queues > > Current address: 00:23:9c:5b:d0:06, Hardware address: 00:23:9c:5b:d0:06 > > Last flapped : 2011-07-21 06:45:45 MYT (8w5d 09:33 ago) > > Input rate : 78415320 bps (42143 pps) > > Output rate : 358686688 bps (47893 pps) > > Active alarms : None > > Active defects : None > > > > Logical interface ge-0/0/6.0 (Index 73) (SNMP ifIndex 217) > > Flags: SNMP-Traps 0x400 Encapsulation: ENET2 > > Input packets : 184759886380 > > Output packets: 212515900409 > > Protocol inet, MTU: 9178 > > Addresses, Flags: Is-Preferred Is-Primary > > Destination: x.x.x.x/x, Local: x.x.x.x, Broadcast: x.x.x.x > > Protocol mpls, MTU: 9166 > > Protocol multiservice, MTU: Unlimited > > > *Soongoon Lee** /** CCIE #17724* > ___ > 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] M10i JUNOS Upgrade
On Thursday, September 29, 2011 03:06:42 AM Jeff Wheeler wrote: > If you have DFZ routes you should upgrade the RAM to > 768MB, or alternatively, replace the router or buy more > modern routing engines. The new M7i/M10i RE-B-1800 should be dropping around Q1'12, along with Junos 11.4R3. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Issue with pseudo-wire attempting to establish across non LSP path
Hi Peter. If I understand correctly, you're expecting that the pseudowire connecting your J42 and J43 VPLS endpoints will re-establish itself using the LSPs that those routers have to J41...essentially transiting through J41 using 2 individual LSPs. Unfortunately that won't work by default, since the route from J43 to J42 can no longer be resolved to an LSP in inet.3 (check 'sh route table inet.3 72.22.160.240' from J43), which is a requirement for any VPN. Are you deactivating/deleting the LSP definitions between J42 and J43? If so, what are you trying to simulate? A failed LSP or link between J42 and J43? Depending on your configuration, if the link between 42 and 43 fails, the LSP should resignal through J41 on its own and while your VPNs may flap, they should restore fairly quickly (or if you use one of the fast reroute methods for your LSPs, they likely won't drop at all. David On 28 September 2011 20:01, Peter Kalogerakos wrote: > David, > Each of the routers are running RSVP as the core MPLS protocol on the core > facing interfaces in other words, we are not running LDP on the core. > > To clarify, these are VPLS connections. If you can visualize a ring type > configuration where the top node BOXLABJ41 has a connection to BOXLABJ42 and > BOXLABJ43. BOXLABJ42 and BOXLABJ43 also have a connection to each other. > I also created a pair of named LSP's between > - BOXLABJ41 and BOXLABJ42 (LSP2) > - BOXLABJ41 and BOXLABJ43 (LSP1 > - BOXLABJ42 and BOXLABJ43 (LSP_J42-43)\(LSP_J43-J42) > The issue exists when I remove the named LSP between BOXLABJ42 and > BOXLABJ43. The vpls session, using vpls and pseudo-wire interchangeably, > goes down when I disable the named LSP between J42 and J43. The VPLS session > goes back up when I cost the IGP metrics to force IGP (ISIS) to prefer > traffic across the links passing through BOXLABJ41 intermediate node. > Below is a series of outputs demonstrating the working and failed > conditions. > admin@boxlabj41> show mpls lsp > Ingress LSP: 2 sessions > To From State Rt P ActivePath LSPname > 72.22.160.205 72.22.160.241 Up 0 * LSP2 > 72.22.160.240 72.22.160.241 Up 0 * LSP1 > Total 2 displayed, Up 2, Down 0 > Egress LSP: 2 sessions > To From State Rt Style Labelin Labelout LSPname > 72.22.160.241 72.22.160.240 Up 0 1 FF 3 - LSP1 > 72.22.160.241 72.22.160.205 Up 0 1 FF 3 - LSP1 > Total 2 displayed, Up 2, Down 0 > *** > admin@boxlabj42>show vpls connections instance ri_j42-j43 //output from > router J43 Lo072.22.160.240 > Instance: ri_j42-j43 > Local site: boxlabj42.10002 (1) > connection-site Type St Time last up # Up trans > 2 rmt Up Sep 26 19:22:10 2011 2 > Remote PE: 72.22.160.205, Negotiated control-word: No > Incoming label: 262154, Outgoing label: 262145 > Local interface: lsi.1564161, Status: Up, Encapsulation: VPLS > Description: Intf - vpls ri_j42-j43 local site 1 remote site 2 > admin@boxlabj43> show vpls connections instance ri_j42-j43 //output from > router J42 Lo072.22.160.205 > Instance: ri_j42-j43 > Local site: boxlabj43.10002 (2) > connection-site Type St Time last up # Up trans > 1 rmt Up Sep 26 22:13:40 2011 2 > Remote PE: 72.22.160.240, Negotiated control-word: No > Incoming label: 262145, Outgoing label: 262154 > Local interface: lsi.1138567, Status: Up, Encapsulation: VPLS > Description: Intf - vpls ri_j42-j43 local site 2 remote site 1 > * > admin@boxlabj43> show mpls lsp > Ingress LSP: 2 sessions > To From State Rt P ActivePath LSPname > 72.22.160.240 72.22.160.205 Up 0 * LSP_J43-J42 > 72.22.160.241 72.22.160.205 Up 0 * LSP1 > Total 2 displayed, Up 2, Down 0 > Egress LSP: 2 sessions > To From State Rt Style Labelin Labelout LSPname > 72.22.160.205 72.22.160.240 Up 0 1 FF 3 - LSP_J42-43 > 72.22.160.205 72.22.160.241 Up 0 1 FF 3 - LSP2 > admin@boxlabj42> show mpls lsp > Ingress LSP: 2 sessions > To From State Rt P ActivePath LSPname > 72.22.160.205 72.22.160.240 Up 0 * LSP_J42-43 > 72.22.160.241 72.22.160.240 Up 0 * LSP1 > Total 2 displayed, Up 2, Down 0 > Egress LSP: 2 sessions > To From State Rt Style Labelin Labelout LSPname > 72.22.160.240 72.22.160.205 Up 0 1 FF 3 - > LSP_J43-J42 > 72.22.160.240 72.22.160.241 Up 0 1 FF 3 - LSP1 > > admin@boxlabj42>show route > *snip* > ri_j42-j43.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 > hi
[j-nsp] Link Utilization miss match between two MX boxes.
HI experts! we are using MPLS + TE, VPLS and L3 VPN I found some interfaces miss match between two Juniper MX boxes as below. but, no traffic dropping. just cant do monitoring bandwidth on an interface. anyone know? how to fix it? or any suggestion? x@> show interfaces ge-0/0/6 Physical interface: ge-0/0/6, Enabled, Physical link is Up Interface index: 138, SNMP ifIndex: 124 Description: *** *** Link-level type: Ethernet, MTU: 9192, Speed: 1000mbps, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Disabled, Remote fault: Online, Speed-negotiation: Disabled, Auto-MDIX: Enabled Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x4000 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Current address: 00:23:9c:9d:58:06, Hardware address: 00:23:9c:9d:58:06 Last flapped : 2011-07-25 04:36:57 MYT (8w1d 10:39 ago) Input rate : 26208 bps (35 pps) Output rate: 69690096 bps (38377 pps) Active alarms : None Active defects : None Logical interface ge-0/0/6.0 (Index 73) (SNMP ifIndex 130) Flags: SNMP-Traps 0x400 Encapsulation: ENET2 Input packets : 98045344 Output packets: 172730795842 Protocol inet, MTU: 9178 Flags: Is-Primary Addresses, Flags: Is-Preferred Is-Primary Destination: x.x.x.x/x, Local: x.x.x.x, Broadcast: x.x.x.x Protocol mpls, MTU: 9166 Flags: Is-Primary Protocol multiservice, MTU: Unlimited Flags: Is-Primary @> show interfaces ge-0/0/6 Physical interface: ge-0/0/6, Enabled, Physical link is Up Interface index: 138, SNMP ifIndex: 155 Description: *** *** Link-level type: Ethernet, MTU: 9192, Speed: 1000mbps, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online, Speed-negotiation: Disabled, Auto-MDIX: Enabled Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x4000 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Current address: 00:23:9c:5b:d0:06, Hardware address: 00:23:9c:5b:d0:06 Last flapped : 2011-07-21 06:45:45 MYT (8w5d 09:33 ago) Input rate : 78415320 bps (42143 pps) Output rate: 358686688 bps (47893 pps) Active alarms : None Active defects : None Logical interface ge-0/0/6.0 (Index 73) (SNMP ifIndex 217) Flags: SNMP-Traps 0x400 Encapsulation: ENET2 Input packets : 184759886380 Output packets: 212515900409 Protocol inet, MTU: 9178 Addresses, Flags: Is-Preferred Is-Primary Destination: x.x.x.x/x, Local: x.x.x.x, Broadcast: x.x.x.x Protocol mpls, MTU: 9166 Protocol multiservice, MTU: Unlimited *Soongoon Lee** /** CCIE #17724* ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Issue with pseudo-wire attempting to establish across non LSP path
David, Each of the routers are running RSVP as the core MPLS protocol on the core facing interfaces in other words, we are not running LDP on the core. To clarify, these are VPLS connections. If you can visualize a ring type configuration where the top node BOXLABJ41 has a connection to BOXLABJ42 and BOXLABJ43. BOXLABJ42 and BOXLABJ43 also have a connection to each other. I also created a pair of named LSP's between - BOXLABJ41 and BOXLABJ42 (LSP2) - BOXLABJ41 and BOXLABJ43 (LSP1 - BOXLABJ42 and BOXLABJ43 (LSP_J42-43)\(LSP_J43-J42) The issue exists when I remove the named LSP between BOXLABJ42 and BOXLABJ43. The vpls session, using vpls and pseudo-wire interchangeably, goes down when I disable the named LSP between J42 and J43. The VPLS session goes back up when I cost the IGP metrics to force IGP (ISIS) to prefer traffic across the links passing through BOXLABJ41 intermediate node. Below is a series of outputs demonstrating the working and failed conditions. admin@boxlabj41> show mpls lsp Ingress LSP: 2 sessions To FromState Rt P ActivePath LSPname 72.22.160.205 72.22.160.241 Up 0 * LSP2 72.22.160.240 72.22.160.241 Up 0 * LSP1 Total 2 displayed, Up 2, Down 0 Egress LSP: 2 sessions To FromState Rt Style Labelin Labelout LSPname 72.22.160.241 72.22.160.240 Up 0 1 FF 3- LSP1 72.22.160.241 72.22.160.205 Up 0 1 FF 3- LSP1 Total 2 displayed, Up 2, Down 0 *** admin@boxlabj42>show vpls connections instance ri_j42-j43 //output from router J43 Lo072.22.160.240 Instance: ri_j42-j43 Local site: boxlabj42.10002 (1) connection-site Type St Time last up # Up trans 2 rmt Up Sep 26 19:22:10 2011 2 Remote PE: 72.22.160.205, Negotiated control-word: No Incoming label: 262154, Outgoing label: 262145 Local interface: lsi.1564161, Status: Up, Encapsulation: VPLS Description: Intf - vpls ri_j42-j43 local site 1 remote site 2 admin@boxlabj43> show vpls connections instance ri_j42-j43 //output from router J42 Lo072.22.160.205 Instance: ri_j42-j43 Local site: boxlabj43.10002 (2) connection-site Type St Time last up # Up trans 1 rmt Up Sep 26 22:13:40 2011 2 Remote PE: 72.22.160.240, Negotiated control-word: No Incoming label: 262145, Outgoing label: 262154 Local interface: lsi.1138567, Status: Up, Encapsulation: VPLS Description: Intf - vpls ri_j42-j43 local site 2 remote site 1 * admin@boxlabj43> show mpls lsp Ingress LSP: 2 sessions To FromState Rt P ActivePath LSPname 72.22.160.240 72.22.160.205 Up 0 * LSP_J43-J42 72.22.160.241 72.22.160.205 Up 0 * LSP1 Total 2 displayed, Up 2, Down 0 Egress LSP: 2 sessions To FromState Rt Style Labelin Labelout LSPname 72.22.160.205 72.22.160.240 Up 0 1 FF 3- LSP_J42-43 72.22.160.205 72.22.160.241 Up 0 1 FF 3- LSP2 admin@boxlabj42> show mpls lsp Ingress LSP: 2 sessions To FromState Rt P ActivePath LSPname 72.22.160.205 72.22.160.240 Up 0 * LSP_J42-43 72.22.160.241 72.22.160.240 Up 0 * LSP1 Total 2 displayed, Up 2, Down 0 Egress LSP: 2 sessions To FromState Rt Style Labelin Labelout LSPname 72.22.160.240 72.22.160.205 Up 0 1 FF 3- LSP_J43-J42 72.22.160.240 72.22.160.241 Up 0 1 FF 3- LSP1 admin@boxlabj42>show route *snip* ri_j42-j43.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 72.22.160.205:10002:2:1/96 *[BGP/170] 2d 05:45:52, localpref 100, from 72.22.160.241 AS path: I > to 72.22.160.13 via ge-0/0/9.0, label-switched-path LSP_J42-43 72.22.160.240:10002:1:1/96 *[L2VPN/170/-101] 2w2d 01:50:03, metric2 1 Indirect admin@boxlabj43>show route *snip* ri_j42-j43.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 72.22.160.205:10002:2:1/96 *[L2VPN/170/-101] 2w2d 01:52:51, metric2 1 Indirect 72.22.160.240:10002:1:1/96 *[BGP/170] 2d 05:49:23, localpref 100, from 72.22.160.241 AS path: I > to 72.22.160.12 via ge-0/0/9.0, label-switched-path LSP_J43-J42 *** admin@boxlabj42> show configuration protocols mpls label-switched-path LSP
Re: [j-nsp] Issue with pseudo-wire attempting to establish across non LSP path
On 28 September 2011 14:27, Peter K wrote: > > Goal is to deploy label switch routers specifically functioning only as PE > (distribution) nodes with direct connectivity to the P\PE (core) nodes and > avoid the configuration required for a full mesh of LSP’s and l2vpn > signaling between the P\PE core nodes and the PE distribution nodes. Below > is an outline of requirements. Safe to assume you're running LDP on your LERs as well ? > > I am noticing the pseudo-wire is attempting to establish a session across a > routed link (with RSVP and MPLS enabled) without a defined LSP path causing > any pseudo-wires using that path to go down. The pseudo-wire > re-establishes its connection when the IGP metric is modified and reroutes > traffic or when then named LSP is created between the two PE nodes. > Although this appears to be an issue regarding order of operations when > deploying a new node(d) in this configuration, is there a mechanism in place > to restrict pseudo-wires from trying to establish connections across a path > without an established LSP path across the connection? Not sure I follow here. All your L2vpns traversing a given link from your LER to the LSR drop when a new one is being signalled? When they drop, what is the output of a 'show l2vpn connections' for them ? David ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Issue with pseudo-wire attempting to establish across non LSP path
I was wondering if anyone is out there with experience supporting a BGP based layer 2 VPLS\VPN environment using RSVP to signal pseudo-wire access. Below is an outline of the general P\PE core configuration. · The core network comprised of P\PE LSR’s · BGP based RSVP based l2vpn signaling is fully meshed between all P\PE core nodes · IGP is ISIS with wide-metrics and traffic engineering enabled · Named CSPF based mesh of LSPs exist between all P\PE core nodes Goal is to deploy label switch routers specifically functioning only as PE (distribution) nodes with direct connectivity to the P\PE (core) nodes and avoid the configuration required for a full mesh of LSP’s and l2vpn signaling between the P\PE core nodes and the PE distribution nodes. Below is an outline of requirements. · Leave current P\PE LSR RSVP l2vpn signaling and LSP full mesh configuration intact · PE (distribution) node will utilize BGP\l2vpn route reflector architecture with P\PE routers act as BGP l2vpn signal route reflectors · IGP configured as ISIS with wide-metrics and traffic engineering enabled · Configure named LSP’s between the directly attached P\PE and PE LSR’s · Avoid enabling RSVP auto-mesh feature I am noticing the pseudo-wire is attempting to establish a session across a routed link (with RSVP and MPLS enabled) without a defined LSP path causing any pseudo-wires using that path to go down. The pseudo-wire re-establishes its connection when the IGP metric is modified and reroutes traffic or when then named LSP is created between the two PE nodes. Although this appears to be an issue regarding order of operations when deploying a new node(d) in this configuration, is there a mechanism in place to restrict pseudo-wires from trying to establish connections across a path without an established LSP path across the connection? Regards, Peter Kalogerakos ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] M10i JUNOS Upgrade
> I do have 2 spare 256MB drams which would meet the requirement. But in most > of the documentation in Juniper they mention a mandatory requirement of 1G > compact flash. But currently I don't have a compact flash on the router. I > can see only ad1s1 . I guess this is the hard disk on the router. Will > upgrade be still possible without the compact flash. > > Further if a install media is used , how would it work with redundant > routing engine upgrades. > > Cheers > > On Wed, Sep 28, 2011 at 11:12 PM, Jonas Frey (Probe Networks) < > j...@probe-networks.de> wrote: > >> Jake, >> >> as far as i know you need more than 512MB dram to go past JunOS 10.x. >> (I know there was a limitation but i dont recall where in detail). >> Any way with less than 768MB Ram you are asking for trouble with any >> modern JunOS. >> Best would be to upgrade your RE-5 to 768 MB which is the max. >> >> The RE-5 only comes with 256MB sticks, so you would only need to buy 1 >> more. This will be fine if you buy them from juniper ($$$). >> If you are going the 3rd party route then it'll be better to buy 3x256MB >> sticks since otherwise the chip types wont match which could lead to >> problems. The cost for these is probably just a few dollars... >> >> 512MB sticks only work on the RE-5+ aka RE-850. >> >> As for the upgrade: Get yourself a install media (or create one) and >> save yourself the trouble of going via various intermediate versions >> (also this would be alot faster). >> >> -Jonas >> >> >> Am Mittwoch, den 28.09.2011, 21:43 +0300 schrieb Jake Jake: >> > Hi all, >> > >> > I am looking at upgrading the JUNOS on our M10i router. Current JUNOS >> > platform is 6.3R1.3 . The router has redundant routing Engine RE-5.0 >> with >> > 512MB DRAM . Also there is no compact flash on board only *ad1s1*. Can >> any >> > one suggest on if I can upgrade the router to 11.1R5.4 with the current >> > hardware specification . Please advise on if a direct upgrade can be >> done >> > as well from 6.3 to 11.1. >> > >> > Plus as I understand M10i has 3 DRAM slots. Is there any way of knowing >> the >> > combination of RAM used ..i.e 256+256MB or a single 512MB RAM. >> > >> > Cheers >> > ___ >> > 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] M10i JUNOS Upgrade
Jake, as far as i know you need more than 512MB dram to go past JunOS 10.x. (I know there was a limitation but i dont recall where in detail). Any way with less than 768MB Ram you are asking for trouble with any modern JunOS. Best would be to upgrade your RE-5 to 768 MB which is the max. The RE-5 only comes with 256MB sticks, so you would only need to buy 1 more. This will be fine if you buy them from juniper ($$$). If you are going the 3rd party route then it'll be better to buy 3x256MB sticks since otherwise the chip types wont match which could lead to problems. The cost for these is probably just a few dollars... 512MB sticks only work on the RE-5+ aka RE-850. As for the upgrade: Get yourself a install media (or create one) and save yourself the trouble of going via various intermediate versions (also this would be alot faster). -Jonas Am Mittwoch, den 28.09.2011, 15:27 -0400 schrieb James Jones: > Just a tip I have found it always easier to backup everything and use the > jinstall file. > > > > > > On Wed, Sep 28, 2011 at 3:06 PM, Jeff Wheeler wrote: > > > On Wed, Sep 28, 2011 at 2:43 PM, Jake Jake <2012j...@gmail.com> wrote: > > > I am looking at upgrading the JUNOS on our M10i router. Current JUNOS > > > platform is 6.3R1.3 . The router has redundant routing Engine RE-5.0 > > with > > > 512MB DRAM . Also there is no compact flash on board only *ad1s1*. Can > > any > > > one suggest on if I can upgrade the router to 11.1R5.4 with the current > > > hardware specification . Please advise on if a direct upgrade can be > > done > > > as well from 6.3 to 11.1. > > > > If you have DFZ routes you should upgrade the RAM to 768MB, or > > alternatively, replace the router or buy more modern routing engines. > > There is a big jump in memory usage in 8.x and if you have only 512MB > > and are carrying "Internet" BGP routes, you will be using the swap and > > the RE will perform badly. > > > > No, you cannot do a direct upgrade from 6.3 to 11.1. You'll be going > > through quite a few intermediate software versions to do that. It > > will be easier to simply reinstall Junos from an 11.1 install-media > > disk and then load your configuration. > > > > > Plus as I understand M10i has 3 DRAM slots. Is there any way of knowing > > the > > > combination of RAM used ..i.e 256+256MB or a single 512MB RAM. > > > > I don't think the RE-5.0 will recognize more than 256MB per slot. > > > > -- > > Jeff S Wheeler > > Sr Network Operator / Innovative Network Concepts > > > > ___ > > 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 signature.asc Description: This is a digitally signed message part ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] M10i JUNOS Upgrade
Just a tip I have found it always easier to backup everything and use the jinstall file. On Wed, Sep 28, 2011 at 3:06 PM, Jeff Wheeler wrote: > On Wed, Sep 28, 2011 at 2:43 PM, Jake Jake <2012j...@gmail.com> wrote: > > I am looking at upgrading the JUNOS on our M10i router. Current JUNOS > > platform is 6.3R1.3 . The router has redundant routing Engine RE-5.0 > with > > 512MB DRAM . Also there is no compact flash on board only *ad1s1*. Can > any > > one suggest on if I can upgrade the router to 11.1R5.4 with the current > > hardware specification . Please advise on if a direct upgrade can be > done > > as well from 6.3 to 11.1. > > If you have DFZ routes you should upgrade the RAM to 768MB, or > alternatively, replace the router or buy more modern routing engines. > There is a big jump in memory usage in 8.x and if you have only 512MB > and are carrying "Internet" BGP routes, you will be using the swap and > the RE will perform badly. > > No, you cannot do a direct upgrade from 6.3 to 11.1. You'll be going > through quite a few intermediate software versions to do that. It > will be easier to simply reinstall Junos from an 11.1 install-media > disk and then load your configuration. > > > Plus as I understand M10i has 3 DRAM slots. Is there any way of knowing > the > > combination of RAM used ..i.e 256+256MB or a single 512MB RAM. > > I don't think the RE-5.0 will recognize more than 256MB per slot. > > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > > ___ > 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] M10i JUNOS Upgrade
On Wed, Sep 28, 2011 at 2:43 PM, Jake Jake <2012j...@gmail.com> wrote: > I am looking at upgrading the JUNOS on our M10i router. Current JUNOS > platform is 6.3R1.3 . The router has redundant routing Engine RE-5.0 with > 512MB DRAM . Also there is no compact flash on board only *ad1s1*. Can any > one suggest on if I can upgrade the router to 11.1R5.4 with the current > hardware specification . Please advise on if a direct upgrade can be done > as well from 6.3 to 11.1. If you have DFZ routes you should upgrade the RAM to 768MB, or alternatively, replace the router or buy more modern routing engines. There is a big jump in memory usage in 8.x and if you have only 512MB and are carrying "Internet" BGP routes, you will be using the swap and the RE will perform badly. No, you cannot do a direct upgrade from 6.3 to 11.1. You'll be going through quite a few intermediate software versions to do that. It will be easier to simply reinstall Junos from an 11.1 install-media disk and then load your configuration. > Plus as I understand M10i has 3 DRAM slots. Is there any way of knowing the > combination of RAM used ..i.e 256+256MB or a single 512MB RAM. I don't think the RE-5.0 will recognize more than 256MB per slot. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] M10i JUNOS Upgrade
Hi all, I am looking at upgrading the JUNOS on our M10i router. Current JUNOS platform is 6.3R1.3 . The router has redundant routing Engine RE-5.0 with 512MB DRAM . Also there is no compact flash on board only *ad1s1*. Can any one suggest on if I can upgrade the router to 11.1R5.4 with the current hardware specification . Please advise on if a direct upgrade can be done as well from 6.3 to 11.1. Plus as I understand M10i has 3 DRAM slots. Is there any way of knowing the combination of RAM used ..i.e 256+256MB or a single 512MB RAM. Cheers ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] JUNOS 10.4R7
Anyone get a chance to run it through some tests? Put it in production yet? We've been busy here so I haven't had much time to play. Just got back from EBC and they talk a good game on this release and 10.4R8... Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Ethernet switching support across a chassis cluster for the SRX3000 series
On Wednesday, September 28, 2011 02:33:28 AM Morgan McLean wrote: > Thanks for the reply, it took JTAC like three days to > come up with that answer. Can you believe it? I've realized that the TAC team aren't as knowledgeable as you'd expect when it comes to the products they are supporting vis-a-vis their employer. This is true for most vendors, not just Juniper. They still do need to escalate to senior engineers and design engineers when the case goes into the realm of feature support, feature roadmaps, or very difficult operational situations. That's the bit I don't like; took me 1 year to resolve an issue a senior engineer identified and fixed in 5 minutes of talking to him once the case was escalated to him, after 12 months! Oh well... Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
