Re: [j-nsp] Config archive subtleties
On (2013-08-08 02:38 -0400), Phil Shafer wrote: > What I'd like to see is support for posting the data to https URLs > and some plumbing on a remote web site that makes it trivial to > drop in your repo of choice. Posting as JSON to arbitrary https URL would be have some appealing advantages. You could include in the JSON meta information, for example who commit author, commit message, commit time etc. You could then in the backend use the commit author, so 'git blame' or 'cvs annotate' would show for each line of config who made it and when. If you want this today, you need to monitor syslog for commits and then do triggered pull of config and use the syslog pointed account as commit author. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Config archive subtleties
On Wednesday, 7 August 2013 3:25:57 PM Phil Shafer wrote: > What else can we do to make this more worthwhile? Put the .gz at the end of the filename (or make the name configurable, as Ben Dale suggested) so that this'll work: $ gunzip foo_juniper.conf.gz_20130806_180633 gzip: foo_juniper.conf.gz_20130806_180633: unknown suffix -- ignored Just something that bugged me when I wanted to uncompress a directory full of them -- David Siebörger d...@sieborger.nom.za ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Config archive subtleties
Ben Dale writes: >- checking it into git/subversion rather than just copying it to upstream >folder (hey, a > guy can dream) The issue would have been the need to ship all the various repo technologies. What I'd like to see is support for posting the data to https URLs and some plumbing on a remote web site that makes it trivial to drop in your repo of choice. Thanks, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Config archive subtleties
I haven't use this in anger for a while, so apologies if some of this functionality is already available, but how about: - an option to disable compression of the config file - an option to specify the naming convention used - eg: always back up to a single file-name rather than appending the date and let your existing version control handle the diffs - checking it into git/subversion rather than just copying it to upstream folder (hey, a guy can dream) On 08/08/2013, at 5:25 AM, Phil Shafer wrote: >> 7 aug 2013 kl. 18:03 skrev Phil Mayers : >> Recently this fell apart on us, as the SSH key on the server changed and the >> archival >> transfers started to silently[1] fail. > > Ick. Silence is deadly. This (and the other issues) is now PR 910647. > >> All of which has me wondering if the feature is more trouble than it's worth. > > We definitely should be making it more robust and stable, but to > me the value of catching each commit as a distinct delta is a win. > It should also have the commit time, user, and commit comment, if > given. Having this in a repo means one can ask questions like "who > has changed config in my network since last Friday?" or "when did > this statement get added in the first place?". > > What else can we do to make this more worthwhile? > > Thanks, > Phil > > ___ > 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] family inet6 on st0.x
I think you would need to run GRE over ipsec for ipv6 support. On Aug 6, 2013 3:06 AM, "Mike Williams" wrote: > Hey all, > > Am I being dense, or now that 'family inet6' can be configured on an st0.x > interface, does it not actually work? > > > I've configured the following on a pair of J6350 clusters; > > set interfaces st0 unit 634 description rmdcccjs-dwdcccjs > set interfaces st0 unit 634 family inet mtu 1500 > set interfaces st0 unit 634 family inet address 10.xxx.xxx.135/31 > set interfaces st0 unit 634 family inet6 mtu 1500 > set interfaces st0 unit 634 family inet6 address 2a02::87/64 > set security ike gateway rmdcccjs-dwdcccjs ike-policy tunnel-pol > set security ike gateway rmdcccjs-dwdcccjs address 178.xxx.xxx.251 > set security ike gateway rmdcccjs-dwdcccjs external-interface reth1.500 > set security ike gateway rmdcccjs-dwdcccjs version v2-only > set security ipsec vpn rmdcccjs-dwdcccjs bind-interface st0.634 > set security ipsec vpn rmdcccjs-dwdcccjs ike gateway rmdcccjs-dwdcccjs > set security ipsec vpn rmdcccjs-dwdcccjs ike proxy-identity local > 10.xxx.xxx.135/31 > set security ipsec vpn rmdcccjs-dwdcccjs ike proxy-identity remote > 10.xxx.xxx.134/31 > set security ipsec vpn rmdcccjs-dwdcccjs ike proxy-identity service any > set security ipsec vpn rmdcccjs-dwdcccjs ike ipsec-policy tunnel-pol > set security ipsec vpn rmdcccjs-dwdcccjs establish-tunnels immediately > set security zones security-zone ipsec_vpn interfaces st0.634 > set routing-instances ipsec interface st0.634 > set routing-instances ipsec protocols ospf area 0.0.0.0 interface st0.634 > set routing-instances ipsec protocols ospf3 area 0.0.0.0 interface st0.634 > > > Where 10.xxx.xxx.134/31 and 2a02::87/64 are appropriately swapped/changed > at the other end. > The devices are entirely flow-mode (security forwarding-options family > inet6 mode flow-based). > One cluster is 12.1X45-D10, the other 12.1X44-D15.5. > The MTU between the devices is at least 1800 bytes all the way through. > reth1.500 is also in the ipsec_vpn zone, and all intra-zone traffic is > permitted. > I've even had host-inbound-traffic set to all all. > > > IPv4 works fine, but IPv6 just, well, doesn't. > > Can't ping the link-local or global addresses across the tunnel, OSPF3 > hellos are being being sent but not received. > 'monitor traffic interface st0.634' says OSPFv2 hellos are coming In and > Out, and "unknown protocol (0x006c)" is going Out only. > > > Pretty much the only documentation I can find is for IPSec over IPv6 (as > in, v6 gateway addresses). > Nowt about configuring IPv6 on the tunnel interface. > > > I don't mind if anyone does prove I'm being dense! > > Thanks > > -- > Mike Williams > ___ > 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] 答复: 答复: SRX650 full-mesh vpn, ssh not passed
so your valid path was actually invalid? On 2013-08-06 6:43 PM, 徐见 wrote: > Thx for you attention, I have found out the reason, it’s ospf issue, > because ospf generate two next-hop for NET A on node 2. > > > > 发件人: Muhammad Atif Jauhar [mailto:atif.jau...@gmail.com] > 发送时间: 2013年8月5日 21:36 > 收件人: 徐见 > 抄送: juniper-nsp@puck.nether.net > 主题: Re: [j-nsp] 答复: SRX650 full-mesh vpn, ssh not passed > > > > Hi, > > Is it possible to share configuration of Node 1, Node 2 and Node 3. and also > output of Show route of Network behind Node 1 and Node 2 and Node 3 at all > Nodes (1, 2, and 3). > > > > Regards, > Atif. > > > > On Mon, Aug 5, 2013 at 10:58 AM, 徐见 wrote: > > Actually, when I disable the first link of node 1, all nodes could pass > every kind of traffic well, except node 2. > And I build an same lab system, the issue not happen. > > > -邮件原件- > 发件人: Ojamo, V. [mailto:lists.vi...@ojamo.eu] > 发送时间: 2013年8月5日 15:02 > 收件人: '徐见'; juniper-nsp@puck.nether.net > 主题: RE: [j-nsp] SRX650 full-mesh vpn, ssh not passed > > The pictures cannot be viewed without Weibo account? > > > -V > > >> -Original Message- >> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] >> On Behalf Of ?? >> Sent: Monday, August 05, 2013 1:18 PM >> To: juniper-nsp@puck.nether.net >> Subject: [j-nsp] SRX650 full-mesh vpn, ssh not passed >> >> Hi all: >> >> As the theme said, I have a route-based vpn, > full-mesh >> topology, >> and run ospf protocol. >> >> Physical link topology is here: >> >> http://photo.weibo.com/2110817105/photos/detail/photo_id/3607 >> 937263216169#36 >> 07937263216169 >> >> logical link topology is here: >> >> >> http://photo.weibo.com/2110817105/photos/detail/photo_id/3607 >> 931668041778#36 >> 07926685185940 >> >> the issue just between node 1 and node 2. >> >> As you can see, there are four links on node 1, and one link > on node >> 2, and >> 2 vpn tunnel have been built between both,(st0.0, st0.1) >> >> And the two tunnel works as primary(st0.0) and backup(st0.1). >> >> The problem is, when primary down, ssh traffic from NET A to > NET >> B, can’t >> passed, but from NET B to NET A is ok, >> >> Show route “NET B”, show route “NET A” commands show both > of >> them have >> learned route from right tunnel (st0.1), ping command in > bidirection >> is ok >> too. >> >> Anyone could give any idea? >> >> >> >> ___ >> 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] Config archive subtleties
I would recommend NOC project, an open source OSS/BSS. It has many goodies, works with lot of hardware. http://www.nocproject.org I use it for bunch of Cisco's, Juniper's and D-Link switches for config archivation, as IP address management with integrated DNS support and lot of other stuff. Sent from my iPad On Օգս 7, 2013, at 20:03, Phil Mayers wrote: > All, > > For several years, we've used "system archival configuration" in "on-commit" > mode, to backup each commit to a separate file on an sftp/scp server, then > check them individually into subversion. > > Recently this fell apart on us, as the SSH key on the server changed and the > archival transfers started to silently[1] fail. > > While trying to write a nagios check for outstanding archive transfers, I > then discovered that in some circumstances, the archival config will give up > and discard a file - I had assumed it would queue them forever, but > apparently not in some cases (e.g. 3 successive failures with bad > username/password). > > All of which has me wondering if the feature is more trouble than it's worth. > > What do other people do? It seems like it would be a nice feature to preserve > the commits and so forth, but if it's not robust, maybe it's just misleading. > > Cheers, > Phil > > [1] It did log en entry into /var/log/messages, but TBH JunOS logs so much > crap there, we don't do anything with those logs... > ___ > 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] Config archive subtleties
>7 aug 2013 kl. 18:03 skrev Phil Mayers : > Recently this fell apart on us, as the SSH key on the server changed and the > archival >transfers started to silently[1] fail. Ick. Silence is deadly. This (and the other issues) is now PR 910647. > All of which has me wondering if the feature is more trouble than it's worth. We definitely should be making it more robust and stable, but to me the value of catching each commit as a distinct delta is a win. It should also have the commit time, user, and commit comment, if given. Having this in a repo means one can ask questions like "who has changed config in my network since last Friday?" or "when did this statement get added in the first place?". What else can we do to make this more worthwhile? Thanks, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Config archive subtleties
Another cisco bug is the npe/rsp crashes when it polls just be aware there's gotchas Sent from my iPhone On Aug 7, 2013, at 11:25, Mark Felder wrote: > On Wed, Aug 7, 2013, at 11:32, Jensen Tyler wrote: >> RANCID? - http://www.shrubbery.net/rancid/ >> >> Works for us and you can monitor multiple vendors gear. > > Put everything in RANCID you will never regret it. > > Beware of a Cisco/ASA bug that you may run across in existing > deployments that don't get upgrades very often. It's not harmful, just > annoying -- every time RANCID checks it commits an update to the > repository because it detects nonexistent changes -- a coredump.cfg that > keeps getting its timestamp updated. The result is a ridiculously long > revision history :) > ___ > 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] Config archive subtleties
RANCID! If you then augment the basic timed polling setup with SNMP-triggered polling, you can have every committed config backed up, and have a timed poll as backup in case there is some problems with the SNMP traps. /Per Sent from my iPad, please ignore stupid spelling corrections! 7 aug 2013 kl. 18:03 skrev Phil Mayers : > All, > > For several years, we've used "system archival configuration" in "on-commit" > mode, to backup each commit to a separate file on an sftp/scp server, then > check them individually into subversion. > > Recently this fell apart on us, as the SSH key on the server changed and the > archival transfers started to silently[1] fail. > > While trying to write a nagios check for outstanding archive transfers, I > then discovered that in some circumstances, the archival config will give up > and discard a file - I had assumed it would queue them forever, but > apparently not in some cases (e.g. 3 successive failures with bad > username/password). > > All of which has me wondering if the feature is more trouble than it's worth. > > What do other people do? It seems like it would be a nice feature to preserve > the commits and so forth, but if it's not robust, maybe it's just misleading. > > Cheers, > Phil > > [1] It did log en entry into /var/log/messages, but TBH JunOS logs so much > crap there, we don't do anything with those logs... > ___ > 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] Config archive subtleties
On Wed, Aug 7, 2013, at 11:32, Jensen Tyler wrote: > RANCID? - http://www.shrubbery.net/rancid/ > > Works for us and you can monitor multiple vendors gear. > Put everything in RANCID you will never regret it. Beware of a Cisco/ASA bug that you may run across in existing deployments that don't get upgrades very often. It's not harmful, just annoying -- every time RANCID checks it commits an update to the repository because it detects nonexistent changes -- a coredump.cfg that keeps getting its timestamp updated. The result is a ridiculously long revision history :) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Config archive subtleties
RANCID? - http://www.shrubbery.net/rancid/ Works for us and you can monitor multiple vendors gear. Jensen Tyler Sr Engineering Manager Fiberutilities Group, LLC This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers Sent: Wednesday, August 07, 2013 11:03 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Config archive subtleties All, For several years, we've used "system archival configuration" in "on-commit" mode, to backup each commit to a separate file on an sftp/scp server, then check them individually into subversion. Recently this fell apart on us, as the SSH key on the server changed and the archival transfers started to silently[1] fail. While trying to write a nagios check for outstanding archive transfers, I then discovered that in some circumstances, the archival config will give up and discard a file - I had assumed it would queue them forever, but apparently not in some cases (e.g. 3 successive failures with bad username/password). All of which has me wondering if the feature is more trouble than it's worth. What do other people do? It seems like it would be a nice feature to preserve the commits and so forth, but if it's not robust, maybe it's just misleading. Cheers, Phil [1] It did log en entry into /var/log/messages, but TBH JunOS logs so much crap there, we don't do anything with those logs... ___ 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] VPN tunnel between OpenSwan and SRX220
try turning up your IKE debug on the SRX to help expose more: >request security ike debug-enable local remote level 15 On Tue, Aug 6, 2013 at 9:55 AM, Laurent CARON wrote: > Hi, > > I'm trying to establish a VPN tunnel between a SRX220 and an OpenSwan box. > > SRX is: > Model: srx220h > JUNOS Software Release [12.1X44-D20.3] > > OpenSwan: 2.6.37 > > Both are currently hooked on a test LAN. > > 192.168.0.18 = openswan box on lan > 192.168.0.120 = juniper box on lan > > 172.31.254.41 = ipsec on juniper box > 172.31.254.27 = ipsec on openswan box > > 172.31.255.27 = loopback on juniper box > > Not relevant for now: > 10.254.2.33 = gre tunnel on openswan side > 10.254.2.34 = gre tunnel on juniper side > > Here is the config on the Juniper side: > > set interfaces ge-0/0/0 mtu 1514 > set interfaces ge-0/0/0 unit 0 family inet address 192.168.0.120/24 > > set interfaces gr-0/0/0 unit 0 tunnel source 172.31.254.41 > set interfaces gr-0/0/0 unit 0 tunnel destination 172.31.254.27 > set interfaces gr-0/0/0 unit 0 family inet address 10.254.2.34/32 > > set interfaces lo0 unit 0 family inet address 172.31.255.41/32 > > set interfaces st0 unit 0 family inet address 172.31.254.41/32 > > set interfaces vlan unit 0 family inet address 192.168.123.1/24 > > set routing-options static route 172.31.254.27/32 next-hop st0.0 > > set security ike traceoptions file vpn-debug-ike > set security ike traceoptions flag all > > set security ike proposal ike_aes_128 authentication-method pre-shared-keys > > set security ike proposal ike_aes_128 dh-group group2 > set security ike proposal ike_aes_128 authentication-algorithm sha1 > set security ike proposal ike_aes_128 encryption-algorithm 3des-cbc > set security ike proposal ike_aes_128 lifetime-seconds 3600 > > set security ike policy phase1_aes_128 mode main > set security ike policy phase1_aes_128 proposals ike_aes_128 > set security ike policy phase1_aes_128 pre-shared-key ascii-text "pwd" > > set security ike gateway RTR-SIEGE-001 ike-policy phase1_aes_128 > set security ike gateway RTR-SIEGE-001 address 192.168.0.18 > set security ike gateway RTR-SIEGE-001 no-nat-traversal > set security ike gateway RTR-SIEGE-001 external-interface ge-0/0/0.0 > > set security ipsec proposal ipsec_aes_128 protocol esp > set security ipsec proposal ipsec_aes_128 authentication-algorithm > hmac-sha1-96 > > set security ipsec proposal ipsec_aes_128 encryption-algorithm 3des-cbc > set security ipsec proposal ipsec_aes_128 lifetime-seconds 3600 > > set security ipsec policy phase2_aes_128 proposals ipsec_aes_128 > > set security ipsec vpn VPN_TO_SIEGE-001 bind-interface st0.0 > set security ipsec vpn VPN_TO_SIEGE-001 ike gateway RTR-SIEGE-001 > set security ipsec vpn VPN_TO_SIEGE-001 ike proxy-identity local > 172.31.254.41/32 > set security ipsec vpn VPN_TO_SIEGE-001 ike proxy-identity remote > 172.31.254.27/32 > set security ipsec vpn VPN_TO_SIEGE-001 ike proxy-identity service any > set security ipsec vpn VPN_TO_SIEGE-001 ike ipsec-policy phase2_aes_128 > set security ipsec vpn VPN_TO_SIEGE-001 establish-tunnels immediately > > set security flow traceoptions file vpn-debug > set security flow traceoptions flag basic-datapath > set security flow traceoptions flag packet-drops > > set security flow tcp-mss ipsec-vpn mss 1412 > > > Here is the config on the OpenSwan side: > > conn rtr-siege-001_TO_jun-noi-001 > left=192.168.0.18 > leftsubnet=172.31.254.27/32 > leftsourceip=172.31.254.27 > right=192.168.0.120 > rightsubnet=172.31.254.41/32 > rightsourceip=172.31.254.41 > ike=3des-sha1 > auth=esp > keyingtries=0 > keyexchange=ike > authby=secret > compress=no > auto=start > pfs=no > mtu=1412 > > The connection establishes fine but drops 10 seconds after and is > renegociated, then drops again, endlessly. > > I do have those logs on the openswan side): > Aug 6 17:42:42 rtr-siege-001 pluto[28569]: added connection description > "rtr-siege-001_TO_jun-noi-001" > Aug 6 17:42:43 rtr-siege-001 pluto[28569]: "rtr-siege-001_TO_jun-noi-001" > #6: initiating Main Mode > Aug 6 17:42:43 rtr-siege-001 pluto[28569]: "rtr-siege-001_TO_jun-noi-001" > #6: received Vendor ID payload [Dead Peer Detection] > Aug 6 17:42:43 rtr-siege-001 pluto[28569]: "rtr-siege-001_TO_jun-noi-001" > #6: ignoring unknown Vendor ID payload [**699369228741c6d4ca094c93e242c9** > de19e7b7c600050500] > Aug 6 17:42:43 rtr-siege-001 pluto[28569]: "rtr-siege-001_TO_jun-noi-001" > #6: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2 > Aug 6 17:42:43 rtr-siege-001 pluto[28569]: "rtr-siege-001_TO_jun-noi-001" > #6: STATE_MAIN_I2: sent MI2, expecting MR2 > Aug 6 17:42:43 rtr-siege-001 pluto[28569]: "rtr-siege-001_TO_jun-noi-001" > #6: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3 > Aug 6 17:42:43 rtr-siege-001 pluto[28569]: "rtr-siege-001_TO_jun-noi-001" > #6: STATE_MAIN_I3: sent MI3, expecting MR3 > Aug 6 17:42:43 rtr-siege-001 pluto[28569]: "rtr-s
Re: [j-nsp] Juniper MX240 to Alcatel SAS-M epipe
On (2013-08-07 17:43 +0200), Mark Tinka wrote: > True, but the OP suggested that some of the web sites he's > browsing don't load correctly, which could allude to an MTU > issue in the data plane. Mea culpa, luckily point remains it does not matter what the eline MTU is. Fully agreed on your suggestion that just guarantee core is large enough, no point doing 'exactly the right size' but large enough. For sake of argument 'exactly the right size' in untagged ethernet core 6B DMAC (not calculated by IOS) 6B SMAC (not calculated by IOS) 2B type (not calculated by IOS) 4B IGP label 4B VPN label 4B control word (maybe, maybe not) 6B inner DMAC 6B inner SMAC 2B inner type xB payload 4B FCS (not calculated by IOS or JunOS) It might be prudent to figure out customer experienced MTU by doing over the l2circuit: a) ping with 1500B DF set b) ping with 1501B DF not set -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Config archive subtleties
All, For several years, we've used "system archival configuration" in "on-commit" mode, to backup each commit to a separate file on an sftp/scp server, then check them individually into subversion. Recently this fell apart on us, as the SSH key on the server changed and the archival transfers started to silently[1] fail. While trying to write a nagios check for outstanding archive transfers, I then discovered that in some circumstances, the archival config will give up and discard a file - I had assumed it would queue them forever, but apparently not in some cases (e.g. 3 successive failures with bad username/password). All of which has me wondering if the feature is more trouble than it's worth. What do other people do? It seems like it would be a nice feature to preserve the commits and so forth, but if it's not robust, maybe it's just misleading. Cheers, Phil [1] It did log en entry into /var/log/messages, but TBH JunOS logs so much crap there, we don't do anything with those logs... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX240 to Alcatel SAS-M epipe
On Wednesday, August 07, 2013 04:22:26 PM Eduardo Barrios wrote: > It's a mixture of Alcatel and Juniper, we always use the > lowest MTU 2102 (this is the MAX MTU on a 7705). Our > M10s do 9192. Even though we might have a primary path > that was discovered @ 9192 we still have to take into > account detours and secondary paths that might be 2102. Well, there you go. If the ALU can only do 2,102 bytes (really?), then running the lowest common denominator across the link is the safest bet. That said, this should be sufficient for web browsing. 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] Juniper MX240 to Alcatel SAS-M epipe
On Wednesday, August 07, 2013 04:24:04 PM Saku Ytti wrote: > MTU in martini is carried in LDP and in kompella in BGP > NLRI as extended community. > In both case it has no effect to actual forwarding nor is > it enforced by padding signaling. > In JunOS martini/l2circuit you can configure arbitrary > MTU to be signalled in the LDP, so just configure on the > JunOS end what ever MTU you need to get the signaling > up. True, but the OP suggested that some of the web sites he's browsing don't load correctly, which could allude to an MTU issue in the data plane. 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] Juniper MX240 to Alcatel SAS-M epipe
It's a mixture of Alcatel and Juniper, we always use the lowest MTU 2102 (this is the MAX MTU on a 7705). Our M10s do 9192. Even though we might have a primary path that was discovered @ 9192 we still have to take into account detours and secondary paths that might be 2102. Eduardo -Original Message- From: Mark Tinka [mailto:mark.ti...@seacom.mu] Sent: Wednesday, August 07, 2013 9:14 AM To: juniper-nsp@puck.nether.net Cc: Eduardo Barrios; Tomasz Mikołajek Subject: Re: [j-nsp] Juniper MX240 to Alcatel SAS-M epipe On Wednesday, August 07, 2013 04:01:46 PM Eduardo Barrios wrote: > We have a couple of VPLS instances b/t a Juniper M10i and > an Alcatel7705. The difference seems to be 14. > Unfortunately Alcatel does not have an > "ignore-mtu-mismatch" switch. Not sure what ALU do, but if it's anything like IOS, it'll be a 14-byte difference from Junos. If you own the backhaul (or have some measure of control over it), just run 9,000 bytes or more and be done with it. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX240 to Alcatel SAS-M epipe
On (2013-08-07 11:06 +0200), Tomasz Mikołajek wrote: > Internet but not every webpage work. I think the problem is in MTU in > epipe. Alcatel has MTU 1522. How to calculate MTU size for MX? Thanks for > help in advance. MTU in martini is carried in LDP and in kompella in BGP NLRI as extended community. In both case it has no effect to actual forwarding nor is it enforced by padding signaling. In JunOS martini/l2circuit you can configure arbitrary MTU to be signalled in the LDP, so just configure on the JunOS end what ever MTU you need to get the signaling up. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX240 to Alcatel SAS-M epipe
On Wednesday, August 07, 2013 04:01:46 PM Eduardo Barrios wrote: > We have a couple of VPLS instances b/t a Juniper M10i and > an Alcatel7705. The difference seems to be 14. > Unfortunately Alcatel does not have an > "ignore-mtu-mismatch" switch. Not sure what ALU do, but if it's anything like IOS, it'll be a 14-byte difference from Junos. If you own the backhaul (or have some measure of control over it), just run 9,000 bytes or more and be done with it. 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] Juniper MX240 to Alcatel SAS-M epipe
Tom,
We have a couple of VPLS instances b/t a Juniper M10i and an Alcatel7705. The
difference seems to be 14. Unfortunately Alcatel does not have an
"ignore-mtu-mismatch" switch.
We also turn on RSVP mtu path discovery (adspec and flowspec TLVs - records
MTUs and reports back the lowest MTU found) on both Juniper and Alcatel, just
to make sure our transport pipe will be big enough to handle layer2 vpn service
mtu.
## Juniper
ebarrios@XX.re0> show configuration routing-instances VPLS-CDP-1
instance-type vpls;
interface ae0.1;
protocols {
vpls {
encapsulation-type ethernet-vlan;
no-tunnel-services;
vpls-id 981;
mtu 2034;
ignore-mtu-mismatch;
neighbor x.x.x.x;
}
}
## Alcatel
vpls 981 customer 7 create
service-mtu 2048
stp
shutdown
exit
sap 1/1/7:1 create
ingress
qos 70
exit
egress
qos 70
exit
exit
mesh-sdp 3:981 vc-type vlan create
exit
no shutdown
exit
Good Luck,
Eduardo
Eduardo Barrios, EIT, JNCIS-SP
IP/MPLS Telecommunications Specialist
Lower Colorado River Authority | 3505 Montopolis Dr. | Austin, TX 78744
-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
Tomasz Mikolajek
Sent: Wednesday, August 07, 2013 4:06 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Juniper MX240 to Alcatel SAS-M epipe
Hi All
I am triing to configure link between MX240 and SAS-M. I want to terminate
Alcatel epipe on MX. I used l2circuit to do this. I can ping address in the
Internet but not every webpage work. I think the problem is in MTU in
epipe. Alcatel has MTU 1522. How to calculate MTU size for MX? Thanks for
help in advance.
Current configuration:
show protocols l2circuit
traceoptions {
file debug-l2circuit size 1m files 5;
}
neighbor 10.250.0.9 {
interface ge-2/1/9.0 {
virtual-circuit-id 11;
ignore-mtu-mismatch;
}
interface ge-2/1/1.0 {
virtual-circuit-id 12;
mtu 1522;
ignore-mtu-mismatch;
}
}
___
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] Juniper MX240 to Alcatel SAS-M epipe
Hi All
I am triing to configure link between MX240 and SAS-M. I want to terminate
Alcatel epipe on MX. I used l2circuit to do this. I can ping address in the
Internet but not every webpage work. I think the problem is in MTU in
epipe. Alcatel has MTU 1522. How to calculate MTU size for MX? Thanks for
help in advance.
Current configuration:
show protocols l2circuit
traceoptions {
file debug-l2circuit size 1m files 5;
}
neighbor 10.250.0.9 {
interface ge-2/1/9.0 {
virtual-circuit-id 11;
ignore-mtu-mismatch;
}
interface ge-2/1/1.0 {
virtual-circuit-id 12;
mtu 1522;
ignore-mtu-mismatch;
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
