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 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 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
[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
