Re: [j-nsp] SRX100 reset
Hi, had the same problem when I first unpacked my SRX100. It requested an IP address but was not reachable at all by that address. I don't remember the exact way i finally fixed it that night, but there was something wrong with the VLAN/port-assignments (and maybe even zones) in the factory default config. You might want to try another port first, as fe-0/0/0 is [supposed to be] in the untrust and fe-0/0/1-7 in trust zone. If this doesn't work, check the config via serial cable and put one specific port into trust and manually assign an IP address to it. I clearly remember that for 1 or 2 hours I thought the device was broken, as it did not work at all, even following the quickstart guide. best regards, Volker Stefan Schlesinger wrote: > Hello Folks, > > I'm trying to reset my SRX100. When I press the Reset button the status > light turns amber, the SRX requests an IP address from my DHCP server, > I see an ARP entry, but I cannot ping it nor connect to it > using telnet/ssh/http. > > What could be the reason for this and how can I do a factory reset? > > Thanks, > > Stefan. > ___ > 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 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
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
[j-nsp] ospfv3 - JUNOS sends zero mtu in dbd -> stuck in ExStart
Hi, 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. I set an ipv6 mtu on all kinds of underlying interfaces but the transmitted mtu does not ever change. there is actually an mtu on the interface: # run show interfaces ip-0/0/0.2 | match mtu Protocol inet6, MTU: 1472 # run show ospf3 interface ip-0/0/0.2 extensive Interface State AreaDR ID BDR ID Nbrs ip-0/0/0.2 PtToPt 0.0.0.1 0.0.0.0 0.0.0.01 Address fe80::b2c6:9aff:fe39:b200, Prefix-length 64 OSPF3-Intf-index 3, Type P2P, MTU 1472, Cost 1 Adj count: 0, Router LSA ID: - Hello 5, Dead 10, ReXmit 5, Not Stub Protection type: None still JUNOS sends 0 (excerpt from trace on JUNOS): Jun 16 02:57:14.012463 OSPF sent DbD fe80::b2c6:9aff:fe39:b200 -> ff02::5 (ip-0/0/0.2 IFL 86 area 0.0.0.1) Jun 16 02:57:14.012576 Version 3, length 28, ID 172.23.5.1, area 0.0.0.1 Jun 16 02:57:14.012669 checksum 0x0, instance-id 0 Jun 16 02:57:14.012763 options 0x13, i 1, m 1, ms 1, seq 0xac14361c, mtu 0 tcpdump on the linux side: 03:00:05.532800 IP6 fe80::b2c6:9aff:fe39:b200 > ff02::5: OSPFv3-dd 28: rtrid 172.23.5.1 area 0.0.0.1 V6/E/R I/M/MS mtu 0 S AC14361C quagga log: 2010/06/16 03:01:19 OSPF6: DbDesc received on gre-nc 2010/06/16 03:01:19 OSPF6: src: fe80::b2c6:9aff:fe39:b200 2010/06/16 03:01:19 OSPF6: dst: ff02::5 2010/06/16 03:01:19 OSPF6: OSPFv3 Type:2 Len:28 Router-ID:172.23.5.1 2010/06/16 03:01:19 OSPF6: Area-ID:0.0.0.1 Cksum:6d7e Instance-ID:0 2010/06/16 03:01:19 OSPF6: MBZ: 0 Option: --|R|-|--|E|V6 IfMTU: 0 2010/06/16 03:01:19 OSPF6: MBZ: 0 Bits: IMm SeqNum: 0xac14361c 2010/06/16 03:01:19 OSPF6: I/F MTU mismatch Unfortunately quagga does not support mtu-ignore, so how can I influence what JUNOS sends as mtu? Thanks, Volker ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] GRE tunnel - inbound traffic drops
To provide my solution in case someone finds this thread:
-I changed the tunnel to ip-0/0/0[.2] using the same config
-changed the linux end to:
> ip tunnel add tun-nc mode sit remote 87.79.237.76 local 80.237.249.84
> ttl 255
> ip addr add 2a01:488:1000:1001:0:50ed:c910:aa00/127 dev tun-nc
> ip link set tun-nc up multicast on
The tunnel now works fine and both ends are ospfv3-neighbors.
Thank you,
Volker
On 05/23/2010 05:56 PM, Volker D. Pallas wrote:
Hi,
i'm trying to set up a simple gre-tunnel from an SRX-100 running JUNOS
10.1R2.8 to a remote linux host.
I verified using tcpdump on both sides:
-pings from linux to junos get sent but are never received.(no sign of
them in tcpdump of pp0.0/gre.0)
-pings from junos to linux arrive (also visible in tcpdump of pp0.0) and
are replied to, but the reply does not reach junos
This sounds like a problem with security zones or policies, but I have
tried about *everything* and it never worked - not even with extreme
measures. Temporarily allowed all inbound traffic for pp0.0, put all
involved interfaces into the 'trust'-zone and so on.
this is my basic tunnel-config:
# set interfaces gre unit 0 tunnel source 87.79.237.76
# set interfaces gre unit 0 tunnel destination 80.237.249.84
# set interfaces gre unit 0 family inet6 address
2a01:488:1000:1001:0:50ed:c910:aa01/127
# set security zones security-zone untrust interfaces gre.0
host-inbound-traffic system-services ping
I already switched to ipv4 which was also not working, so i can rule out
that this has something to do with ipv6.
A trace on 'security' also showed the following, which I don't really like:
May 23 15:58:32 15:58:31.1697039:CID-0:RT:pak_for_self: No handler
function found for proto:47, dst-port:2048, drop pkt
There is a second tunnel configured on that linux box to a remote cisco
device ("same" config) and this is working properly.
I would appreciate any help,
thanks in advance,
Volker
___
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] no family inet6 for vlan.*-interfaces on 10.1R2.8?
Oh yes, I forgot to mention. It's an SRX-100. I downgraded the box to 10.1R1.8 yesterday and now I have my family inet6 back :-) weird issue! Volker On 05/26/2010 09:20 AM, Thomas Eichhorn wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Volker, on what kind of device? teichh...@testbox.fra# set interfaces vlan.333 family ? Possible completions: + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups inet IPv4 parameters inet6IPv6 protocol parameters iso OSI ISO protocol parameters mpls MPLS protocol parameters [edit] I have it on JUNOS Base OS boot [10.1R2.8]... Tom ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] no family inet6 for vlan.*-interfaces on 10.1R2.8?
Hi,
I just realized that there seems to be no "family inet6" anymore for
vlan-interfaces since upgrading to junos 10.1R2.8.
Fortunately my old config is still active and working, but I cannot
modify it:
# show interfaces vlan unit 10
family inet {
address 172.23.5.1/25;
}
family inet6 {
address 2001:4dd0:ff08:10::1/64;
}
# set interfaces vlan unit 10 family ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> inet IPv4 parameters
> mpls MPLS protocol parameters
> tcc Translational cross-connect parameters
> vpls Virtual private LAN service parameters
Is this a new feature or a bug?
For interfaces other than vlan.* this is still working as expected.
Thanks,
Volker
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] GRE tunnel - inbound traffic drops
Hi,
i'm trying to set up a simple gre-tunnel from an SRX-100 running JUNOS
10.1R2.8 to a remote linux host.
I verified using tcpdump on both sides:
-pings from linux to junos get sent but are never received.(no sign of
them in tcpdump of pp0.0/gre.0)
-pings from junos to linux arrive (also visible in tcpdump of pp0.0) and
are replied to, but the reply does not reach junos
This sounds like a problem with security zones or policies, but I have
tried about *everything* and it never worked - not even with extreme
measures. Temporarily allowed all inbound traffic for pp0.0, put all
involved interfaces into the 'trust'-zone and so on.
this is my basic tunnel-config:
# set interfaces gre unit 0 tunnel source 87.79.237.76
# set interfaces gre unit 0 tunnel destination 80.237.249.84
# set interfaces gre unit 0 family inet6 address
2a01:488:1000:1001:0:50ed:c910:aa01/127
# set security zones security-zone untrust interfaces gre.0
host-inbound-traffic system-services ping
I already switched to ipv4 which was also not working, so i can rule out
that this has something to do with ipv6.
A trace on 'security' also showed the following, which I don't really like:
May 23 15:58:32 15:58:31.1697039:CID-0:RT:pak_for_self: No handler
function found for proto:47, dst-port:2048, drop pkt
There is a second tunnel configured on that linux box to a remote cisco
device ("same" config) and this is working properly.
I would appreciate any help,
thanks in advance,
Volker
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
