Re: [j-nsp] Olive Qemu/GNS3 networking issue on Snow Leopard
Hi Tommy, Giany, Stefan I manage to find the problem. I created a qemu base image with Junos 10.2R1.8, but instead of using the 182559er NIC I used the e1000 for my JUNOS Routers. I reconfigured all interfaces for JUNOS Routers 1 to 4. I got this error when committing my configs: ! root# commit Interrupt storm detected on irq11:; throttling interrupt source ! I also got this error after all my configs where done and I started testing connectivity with pings: ! r...@r1# em2: watchdog timeout -- resetting ! I googled the above error and found the solution to my problem on this page http://www.gns3.net/phpBB/topic2147.html?sid=0a8b808d046a2697efc844a92cd1e45a The problem seems to be with fxp3,em2,etc... So I just adjust my Router connectivity to not use Interface 2 and my LAB is working. According to Nacho ( who posted 19:13, 28 April 2010 on http://blog.gns3.net/2009/10/olive-juniper/) IPv6 and multicast (PIM) is not supported on the e1000 but on the i82559er interfaces. I have a MBPro with 4Gig RAM, so I'll be setting up my LAB with the 182559er interfaces and see if my qemu instance crashes when running the EBGP case study on my machine. Kind Regards Deon Vermeulen On Jun 16, 2010, at 7:34 AM, Deon Vermeulen wrote: Hi Tommy, Perhaps we can work on this together. I used the below ink to get GNS3 and qemu working on my Machine. http://www.networkfoo.org/cisco-articles/running-cisco-asa-firewall-gns3-os-x I used this site only to help with the creating/installing of the JUNOS Olive Base Image and the networking part. http://blog.gns3.net/2009/10/olive-juniper/ I really need to get this working specifically as I want to use this to Lab real life scenarios where I use a mix of Cisco and Juniper Equipment. I really have limited OS X cli (BSD) experience which makes it a bit challenging for me. Kind Regards Deon On Jun 15, 2010, at 6:30 PM, Tommy Perniciaro wrote: If you get that working let me know :) That would be awesome -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Deon Vermeulen Sent: Tuesday, June 15, 2010 5:24 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Olive Qemu/GNS3 networking issue on Snow Leopard Hi Forum, I have been trying to get the JNCIP LAB (www.juniper.net/training/certification/JNCIP_studyguide.pdf) up and running on my MacBook Pro running Snow Leopard 10.6.3. I've manage to get it working with qemu using UNIX sockets and UDP tunnels, but only 2 Juniper routers (R1 R2) could network with each other. After 5 months of back and forth I eventually got GNS3 running for Juniper under Snow Leopard 10.6.3. I manage to get the JNCIP LAB setup and start all routers just as with qemu, but still experience the same networking issues. I can only ping between R1 and R2. I see the arp entry on R1 and R2 for R3 but can not ping to R3 from R1 or R2. On R3, I can ping the local address of the interface connecting to R1 and R2, but cannot ping to R1 or R2 from R3. I disabled my MAC Firewall, but still no luck. My LAB Topology is based on the Official JNCIP Study Guide from Juniper. www.juniper.net/training/certification/JNCIP_studyguide.pdf Any help/guidance will really be appreciated. Thank you in advance Kind Regards Deon Vermeulen Fax2Email: 088628731 email: vermeulen.d...@gmail.com ___ 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] ISIS Routing Problem
-Original Message- From: Felix Schueren [mailto:felix.schue...@hosteurope.de] Sent: Wednesday, June 16, 2010 10:16 PM To: Eric Van Tol Cc: juniper-nsp Subject: Re: [j-nsp] ISIS Routing Problem Eric, IS-IS always prefers routes reachable via L1 over those reachable via L2, and in this case the IS-IS route selection will only ever export the L1 version of the route to the main junos kernel, and _after_ the IS-IS decision (use L1 over L2) was made junos will apply the global route preference mapping, then put the IS-IS route into it's routing tables. Kind regards, Felix Thanks, that clears it up for me. Just tried the static route solution and now it looks like I'll be headed over to cisco-nsp because neither my route-maps for ISIS or BGP are working properly on the 6509s. -evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS label allocation
The formula used in junos for label allocation is : VPN label = label-base-remote + local-site-id – label-offset-remote Regds, Anand On Thu, Jun 17, 2010 at 6:22 AM, David water dwater2...@gmail.com wrote: Can some one point me to the easy calculation document for RFC4761 label allocation technique? its very confusing. To my understanding site-offset + label-range should cover the remote site id So if remote site id is 30 then site-offset should be 24 and range should be 8 which covers the range from 24 to 31 where this range does cover the remote site id of 30. And label value will be label-base + offset - remote site id. For remote site id of 4 offset should be 1 and range should be 8. -- David W. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Thanks Muruganandham M ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS label allocation
Need to be careful when describing the formula. local/remote site id means varies depending on perspective. for example: PE-A, (connected to customer site id 1), advertises a label base of 1000, range of 4 and offset of 1 This route is received by remote PE-B that has another sight in the same VPN. The site connected to PE-B is site id 3. Traffic forward from site 3 to site 1 will arrive at PE-A with a label 1002 label base + remote sight id - offset ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS label allocation
I suppose for your case i.e. site-id 30, site-offset is 25. For more information on JUNOS vpls label allocation refer below link. http://kb.juniper.net/library/CUSTOMERSERVICE/technotes/Understanding_VPLS_Label_Blocks_Operation.pdf In summary site-offset = site-id (site-offset + label-range) where site-offset and label-range are as advertised by the remote peer the end site-offset is a multiple of the label-range, which is by default 8. Label for remote-site = (label base + (site ID − site-offset)) where label base and site-offset are as advertised by the remote peer. HTH, --Vijay ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Netscreen firewalls multicast replication
All, Just a quick question... We run a pair of Netscreen 5400s with M2 management boards and 10gig modules, running ScreenOS 6.3, in routed mode. A while back we discovered a documented limitation, specifically that these firewalls don't have multicast replication hardware. You can run them in one of two modes: 1. Multicast is done in hardware. In this mode, receivers must all be on one outbound interface, and multicast is faked, I guess by adding /32 routes for the group pointing out of the output interface (as opposed to a proper 64-bit (s,g) lookup) - this is set flow multicast install-hw-session. 2. Multicast is done in software. In this mode, things work as normal but very high bit rates (e.g. a 20Mbit stream) can load the CPUs. This is the default. So, this is unfortunate but fine - I can live with that. Question: do any later models of Juniper/Netscreen have multicast replication hardware? Do any other *vendors* have it? Obviously transparent / layer2 mode doesn't have this issue, but we don't want to run that for many reasons. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS label allocation
Now, how the label base, offset is calculated, we can configure the site id so how does the router calculate the other values? On Thu, Jun 17, 2010 at 8:30 AM, Phill Jolliffe ph...@twine-networks.comwrote: Need to be careful when describing the formula. local/remote site id means varies depending on perspective. for example: PE-A, (connected to customer site id 1), advertises a label base of 1000, range of 4 and offset of 1 This route is received by remote PE-B that has another sight in the same VPN. The site connected to PE-B is site id 3. Traffic forward from site 3 to site 1 will arrive at PE-A with a label 1002 label base + remote sight id - offset -- David W. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Olive Qemu/GNS3 networking issue on Snow Leopard
-Original Message- From: Deon Vermeulen [mailto:vermeulen.d...@gmail.com] Sent: Thursday, June 17, 2010 5:05 AM To: Tommy Perniciaro; Giany; Stefan Fouant Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Olive Qemu/GNS3 networking issue on Snow Leopard I have a MBPro with 4Gig RAM, so I'll be setting up my LAB with the 182559er interfaces and see if my qemu instance crashes when running the EBGP case study on my machine. FYI, I've successfully managed to run my Olives with as little as 96 MB of memory allocated to each VM, but only AFTER installation was complete. It seems for whatever reason the memory check function only exists during initial installation, but once its installed it can be run with effectively a lot less memory. I've even managed to get my Olives to run with as little as 48 MB of memory allocated to the VM but it was painfully slow. 4 GB of memory should be more than adequate to get yourself a decent virtual lab going... Stefan Fouant, CISSP, JNCIEx2 www.shortestpathfirst.net GPG Key ID: 0xB5E3803D ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Olive Qemu/GNS3 networking issue on Snow Leopard
Thanks I've picked up that I need quite a bit of Memory to get JUNOS installed. I used 1534 for installing 10.2. I'm sure 1024 is more then enough for this. I'm running my qemus with 96MB RAM in GNS3 as I don't want to boot the LAB every time I want to use it, but I also still want to be able to use my machine as normal without the lack of Memory. Images do take a long time to boot up, but once up and running they work like a charm. Thanks again for the Notes. Really Appreciate it. Kind Regards Deon Vermeulen On Jun 17, 2010, at 4:28 PM, Stefan Fouant wrote: -Original Message- From: Deon Vermeulen [mailto:vermeulen.d...@gmail.com] Sent: Thursday, June 17, 2010 5:05 AM To: Tommy Perniciaro; Giany; Stefan Fouant Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Olive Qemu/GNS3 networking issue on Snow Leopard I have a MBPro with 4Gig RAM, so I'll be setting up my LAB with the 182559er interfaces and see if my qemu instance crashes when running the EBGP case study on my machine. FYI, I've successfully managed to run my Olives with as little as 96 MB of memory allocated to each VM, but only AFTER installation was complete. It seems for whatever reason the memory check function only exists during initial installation, but once its installed it can be run with effectively a lot less memory. I've even managed to get my Olives to run with as little as 48 MB of memory allocated to the VM but it was painfully slow. 4 GB of memory should be more than adequate to get yourself a decent virtual lab going... Stefan Fouant, CISSP, JNCIEx2 www.shortestpathfirst.net GPG Key ID: 0xB5E3803D ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Logical-Systems Management SNMP
# set snmp community XPTO clients 10.31.0.236
Dan
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Gabriel Farias
Sent: Thursday, June 17, 2010 4:16 PM
To: juniper-nsp@puck.nether.net; juniper-nsp-boun...@puck.nether.net
Subject: Re: [j-nsp] Logical-Systems Management SNMP
Hi friends,
I used the following configuration, but I'm having error and the server
database can not read the information via snmp.
Do you have any hint of what is happening?
thanks
*Attempting Server*:
sa19rb1:/ # ping 10.251.42.230 -n 4
PING 10.251.42.230: 64 byte packets
64 bytes from 10.251.42.230: icmp_seq=0. time=1. ms
64 bytes from 10.251.42.230: icmp_seq=1. time=1. ms
64 bytes from 10.251.42.230: icmp_seq=2. time=1. ms
64 bytes from 10.251.42.230: icmp_seq=3. time=1. ms
10.251.42.230 PING Statistics
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 1/1/1
sa19rb1:/ # snmpwalk 10.251.42.230 system
snmpwalk: No response arrived before timeout.
*Configure used*
{master}[edit]
q...@ixr01rjo# show snmp
community XPTO {
authorization read-only;
logical-system RT30RJO {
routing-instance manager-snmp;
}
}
trap-options {
logical-system RT30RJO {
routing-instance manager-snmp {
source-address 10.251.42.230;
}
}
}
routing-instance-access;
traceoptions {
file debug-snmp;
flag all;
}
{master}[edit]
q...@ixr01rjo# run monitor start debug-snmp
*ERROR*:
{master}[edit]
q...@ixr01rjo#
*** debug-snmp ***
Jun 17 16:35:28 snmpd[5709]
Jun 17 16:35:28 snmpd[5709] Get-Next-Request
Jun 17 16:35:28 snmpd[5709] Source: 10.31.0.236
Jun 17 16:35:28 snmpd[5709] Destination: 10.251.42.230
Jun 17 16:35:28 snmpd[5709] Version: SNMPv1
Jun 17 16:35:28 snmpd[5709] Request_id: 0x5709
Jun 17 16:35:28 snmpd[5709] Community: XPTO
Jun 17 16:35:28 snmpd[5709] Error: status=0 / vb_index=0
Jun 17 16:35:28 snmpd[5709]OID : system
Jun 17 16:35:28 snmpd[5709]
Jun 17 16:35:28 SNMPD_AUTH_RESTRICTED_ADDRESS: nsa_initial_callback: request
from address 10.31.0.236 not allowed
Jun 17 16:35:28 SNMPD_AUTH_FAILURE: nsa_initial_embedcomm: unauthorized SNMP
community from 10.31.0.236 to unknown community name (XPTO)
Jun 17 16:35:28 ns_trap_internal
Jun 17 16:35:28 ns_trap_internal
Jun 17 16:35:29 snmpd[5709]
Jun 17 16:35:29 snmpd[5709] Get-Next-Request
Jun 17 16:35:29 snmpd[5709] Source: 10.31.0.236
Jun 17 16:35:29 snmpd[5709] Destination: 10.251.42.230
Jun 17 16:35:29 snmpd[5709] Version: SNMPv1
Jun 17 16:35:29 snmpd[5709] Request_id: 0x5709
Jun 17 16:35:29 snmpd[5709] Community: XPTO
Jun 17 16:35:29 snmpd[5709] Error: status=0 / vb_index=0
Jun 17 16:35:29 snmpd[5709]OID : system
Jun 17 16:35:29 snmpd[5709]
Jun 17 16:35:29 SNMPD_AUTH_RESTRICTED_ADDRESS: nsa_initial_callback: request
from address 10.31.0.236 not allowed
Jun 17 16:35:29 SNMPD_AUTH_FAILURE: nsa_initial_embedcomm: unauthorized SNMP
community from 10.31.0.236 to unknown community name (XPTO)
Jun 17 16:35:32 snmpd[5709]
Jun 17 16:35:32 snmpd[5709] Get-Next-Request
Jun 17 16:35:32 snmpd[5709] Source: 10.31.0.236
Jun 17 16:35:32 snmpd[5709] Destination: 10.251.42.230
Jun 17 16:35:32 snmpd[5709] Version: SNMPv1
Jun 17 16:35:32 snmpd[5709] Request_id: 0x5709
Jun 17 16:35:32 snmpd[5709] Community: XPTO
Jun 17 16:35:32 snmpd[5709] Error: status=0 / vb_index=0
Jun 17 16:35:32 snmpd[5709]OID : system
Jun 17 16:35:32 snmpd[5709]
Jun 17 16:35:32 SNMPD_AUTH_RESTRICTED_ADDRESS: nsa_initial_callback: request
from address 10.31.0.236 not allowed
Jun 17 16:35:32 SNMPD_AUTH_FAILURE: nsa_initial_embedcomm: unauthorized SNMP
community from 10.31.0.236 to unknown community name (XPTO)
Tranks
Gabriel Farias
2010/6/10 Gabriel Farias gabrielfaria...@gmail.com
Dear friends,
I have a router model M10i Junos 9.6R1.13 running and is working with
three-logical systems (LS1, LS2 and LS3), I need to manage all logical
systems using SNMP, the best way?
*I am using the command*:
set snmp community name-community logical-system name-system
In addition to this command that is needed?
Thanks,
Gabriel Farias
___
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] Logical-Systems Management SNMP
You might also want to try from your server-
# snmpwwalk -c XPTO 10.251.42.230 system
Dan
-Original Message-
From: Dan Farrell
Sent: Thursday, June 17, 2010 4:39 PM
To: 'Gabriel Farias'; juniper-nsp@puck.nether.net;
juniper-nsp-boun...@puck.nether.net
Subject: RE: [j-nsp] Logical-Systems Management SNMP
# set snmp community XPTO clients 10.31.0.236
Dan
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Gabriel Farias
Sent: Thursday, June 17, 2010 4:16 PM
To: juniper-nsp@puck.nether.net; juniper-nsp-boun...@puck.nether.net
Subject: Re: [j-nsp] Logical-Systems Management SNMP
Hi friends,
I used the following configuration, but I'm having error and the server
database can not read the information via snmp.
Do you have any hint of what is happening?
thanks
*Attempting Server*:
sa19rb1:/ # ping 10.251.42.230 -n 4
PING 10.251.42.230: 64 byte packets
64 bytes from 10.251.42.230: icmp_seq=0. time=1. ms
64 bytes from 10.251.42.230: icmp_seq=1. time=1. ms
64 bytes from 10.251.42.230: icmp_seq=2. time=1. ms
64 bytes from 10.251.42.230: icmp_seq=3. time=1. ms
10.251.42.230 PING Statistics
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 1/1/1
sa19rb1:/ # snmpwalk 10.251.42.230 system
snmpwalk: No response arrived before timeout.
*Configure used*
{master}[edit]
q...@ixr01rjo# show snmp
community XPTO {
authorization read-only;
logical-system RT30RJO {
routing-instance manager-snmp;
}
}
trap-options {
logical-system RT30RJO {
routing-instance manager-snmp {
source-address 10.251.42.230;
}
}
}
routing-instance-access;
traceoptions {
file debug-snmp;
flag all;
}
{master}[edit]
q...@ixr01rjo# run monitor start debug-snmp
*ERROR*:
{master}[edit]
q...@ixr01rjo#
*** debug-snmp ***
Jun 17 16:35:28 snmpd[5709]
Jun 17 16:35:28 snmpd[5709] Get-Next-Request
Jun 17 16:35:28 snmpd[5709] Source: 10.31.0.236
Jun 17 16:35:28 snmpd[5709] Destination: 10.251.42.230
Jun 17 16:35:28 snmpd[5709] Version: SNMPv1
Jun 17 16:35:28 snmpd[5709] Request_id: 0x5709
Jun 17 16:35:28 snmpd[5709] Community: XPTO
Jun 17 16:35:28 snmpd[5709] Error: status=0 / vb_index=0
Jun 17 16:35:28 snmpd[5709]OID : system
Jun 17 16:35:28 snmpd[5709]
Jun 17 16:35:28 SNMPD_AUTH_RESTRICTED_ADDRESS: nsa_initial_callback: request
from address 10.31.0.236 not allowed
Jun 17 16:35:28 SNMPD_AUTH_FAILURE: nsa_initial_embedcomm: unauthorized SNMP
community from 10.31.0.236 to unknown community name (XPTO)
Jun 17 16:35:28 ns_trap_internal
Jun 17 16:35:28 ns_trap_internal
Jun 17 16:35:29 snmpd[5709]
Jun 17 16:35:29 snmpd[5709] Get-Next-Request
Jun 17 16:35:29 snmpd[5709] Source: 10.31.0.236
Jun 17 16:35:29 snmpd[5709] Destination: 10.251.42.230
Jun 17 16:35:29 snmpd[5709] Version: SNMPv1
Jun 17 16:35:29 snmpd[5709] Request_id: 0x5709
Jun 17 16:35:29 snmpd[5709] Community: XPTO
Jun 17 16:35:29 snmpd[5709] Error: status=0 / vb_index=0
Jun 17 16:35:29 snmpd[5709]OID : system
Jun 17 16:35:29 snmpd[5709]
Jun 17 16:35:29 SNMPD_AUTH_RESTRICTED_ADDRESS: nsa_initial_callback: request
from address 10.31.0.236 not allowed
Jun 17 16:35:29 SNMPD_AUTH_FAILURE: nsa_initial_embedcomm: unauthorized SNMP
community from 10.31.0.236 to unknown community name (XPTO)
Jun 17 16:35:32 snmpd[5709]
Jun 17 16:35:32 snmpd[5709] Get-Next-Request
Jun 17 16:35:32 snmpd[5709] Source: 10.31.0.236
Jun 17 16:35:32 snmpd[5709] Destination: 10.251.42.230
Jun 17 16:35:32 snmpd[5709] Version: SNMPv1
Jun 17 16:35:32 snmpd[5709] Request_id: 0x5709
Jun 17 16:35:32 snmpd[5709] Community: XPTO
Jun 17 16:35:32 snmpd[5709] Error: status=0 / vb_index=0
Jun 17 16:35:32 snmpd[5709]OID : system
Jun 17 16:35:32 snmpd[5709]
Jun 17 16:35:32 SNMPD_AUTH_RESTRICTED_ADDRESS: nsa_initial_callback: request
from address 10.31.0.236 not allowed
Jun 17 16:35:32 SNMPD_AUTH_FAILURE: nsa_initial_embedcomm: unauthorized SNMP
community from 10.31.0.236 to unknown community name (XPTO)
Tranks
Gabriel Farias
2010/6/10 Gabriel Farias gabrielfaria...@gmail.com
Dear friends,
I have a router model M10i Junos 9.6R1.13 running and is working with
three-logical systems (LS1, LS2 and LS3), I need to manage all logical
systems using SNMP, the best way?
*I am using the command*:
set snmp community name-community logical-system name-system
In addition to this command that is needed?
Thanks,
Gabriel Farias
___
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] ospfv3 - JUNOS sends zero mtu in dbd - stuck in ExStart
Hi Daniel, thank you for your reply. I've read the RFC now and you're right. I opened a bug report with quagga regarding this issue: https://bugzilla.quagga.net/show_bug.cgi?id=602 OSPFv3 on quagga seems to be a bit buggy in general, I'm still waiting for a fix of another problem (bug #600). Thanks again and have a good night, Volker On 06/16/10 08:49, Daniel Roesen wrote: On Wed, Jun 16, 2010 at 03:39:47AM +0200, Volker D. Pallas wrote: I'm having an issue with an OSPFv3 neighborship between Linux/quagga (0.99.16) and JUNOS (10.1R2.8 on SRX-100) via a standard ip-tunnel: the dbd info sent by JUNOS always contains mtu 0, which quagga does not like at all. This keeps my neighborship in ExStart. According to the OSPFv3 spec (RFC2740), JUNOS is correct in sending MTU 0 on a tunnel interface: Interface MTU The size in bytes of the largest IPv6 datagram that can be sent out theassociated interface, without fragmentation. The MTUs of common Internet link types can be found in Table 7-1of [Ref12]. Interface MTU should be set to 0 in Database Description packets sent over virtual links. [...] I'd say Quagga is wrong to expect anything else than MTU 0 on a tunnel type interface... Best regards, Daniel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ospfv3 - JUNOS sends zero mtu in dbd - stuck in ExStart
Hi, On Thu, Jun 17, 2010 at 10:46:51PM +0200, Volker D. Pallas wrote: I've read the RFC now and you're right. I'm not so sure anymore. A fellow reader has challenged my interpretation of the RFC wording, that it might mean OSPF virtual links, not tunnel (and similar virtual, non-physical) interfaces. Upon re-reading with that interpretation in mind, I tend to agree. Thinking further about it, mtu=0 for OSPF virtual links makes sense, as only OSPF PDUs are being tunnelled, no actual traffic. So there is no sensible MTU to report in the DBD packets. On real tunneling interfaces though, everything (OSPF PDUs and actual traffic) gets tunnelled, and the tunnel has a real MTU associated. So in fact, I think my interpretation was wrong and JUNOS is actually misbehaving by advertising MTU=0. It should report the tunnel interface L3 MTU. Sorry for the noise. I suggest raising a case with JTAC and closing off the Quagga bug filing. BTW, I noticed your Linux tunnel interface being named gre-nc - I guess the gre part is a leftover misnomer from trying GRE encaps? Best regards from Porz to Porz, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- d...@ircnet -- PGP: 0xA85C8AA0 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ospfv3 - JUNOS sends zero mtu in dbd - stuck in ExStart
Hi again, yeah, this makes total sense! At first I thought this is a JUNOS-problem, as Cisco does send the right mtu along. I closed the bug report on the quagga bugzilla for now (with closed/invalid) and will talk to JTAC. I'll get back to you and the list as soon as I have some confirmation and/or fix. I'm not so sure anymore. A fellow reader has challenged my interpretation of the RFC wording, that it might mean OSPF virtual links, not tunnel (and similar virtual, non-physical) interfaces. Upon re-reading with that interpretation in mind, I tend to agree. Thinking further about it, mtu=0 for OSPF virtual links makes sense, as only OSPF PDUs are being tunnelled, no actual traffic. So there is no sensible MTU to report in the DBD packets. On real tunneling interfaces though, everything (OSPF PDUs and actual traffic) gets tunnelled, and the tunnel has a real MTU associated. So in fact, I think my interpretation was wrong and JUNOS is actually misbehaving by advertising MTU=0. It should report the tunnel interface L3 MTU. Sorry for the noise. I suggest raising a case with JTAC and closing off the Quagga bug filing. No, not at all! Thanks a lot for your input! I did not even read the appropriate RFC before you posted, which I should do next time. BTW, I noticed your Linux tunnel interface being named gre-nc - I guess the gre part is a leftover misnomer from trying GRE encaps? exactly ;-) It's actually sit now on the linux side Best regards from Porz to Porz, Daniel and best wishes back to you! Volker ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
