Re: [j-nsp] Olive Qemu/GNS3 networking issue on Snow Leopard
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
[j-nsp] Change in routing policy functionality somewhere between 9.2 and 10.0 ?
We recently completed an upgrade from 9.2 to 10.0R3.10 (2-step
manual upgrade, stopping at 9.4R4.5 on the way) on our core T640 and
MX480 routers. All went well, with the exception of something that
popped up the next day, only affecting L3VPN customers.
For more than 3yrs, we've had an import and export policy (the value
of which I'm questioning) on our core iBGP sessions which had a
'reject' statement for any RFC1918 blocks. It's a legacy policy that
somehow stuck when we migrated from some old M10s that only used to
handle internet. Anyhow, up to at least 9.2, these policies actually
permitted (despite the policy) RFC1918 space for any L3VPN/VRFs that
we had set up, so it's never been a problem. Our L3VPN customers who
used this space worked fine.
But, following our upgrade to 10.0R3.10, those policies suddenly
started acting differently. The export policy which was supposed to
deny RFC1918 space still wasn't doing its job, so 192.168/x space was
still being advertised to a neighbor. On the neighbor though, the
import policy is having a different effect now, and is storing them as
'hidden' routes (whereas, prior to upgrade, they worked fine).
Ticket is open with JTAC, but wondered if anyone else had stumbled
upon this. I re-verified in the lab by using 9.2 the moving to 10.0
with identical config.
This is the 1st policy applied to iBGP sessions on import and export:
m...@router> ...options policy-statement reject-bad-routes
term reject {
from {
prefix-list-filter martian-space orlonger;
}
then reject;
}
{master}
m...@router> show configuration policy-options prefix-list martian-space
0.0.0.0/8;
10.0.0.0/8;
127.0.0.0/8;
169.254.0.0/16;
172.16.0.0/12;
192.0.2.0/24;
192.168.0.0/16;
198.18.0.0/15;
224.0.0.0/3;
David
___
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
[j-nsp] clear-dont-fragment bit in firewall filter...
It would be awesome if we could clear the DF bit in a FW filter... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX3600
I would look at 10.0R3 or 10.1R2. There had been some corner case issues with 10.1R1 and JSRP/Chassis Cluster Rob Cameron Technical Marketing Engineer - HSSBU r...@juniper.net www.juniper.net On Jun 14, 2010, at 4:11 AM, Fahad Khan wrote: I have recently deployed 10.0R3.10 as recommended by Juniper. Did not see any issue. let me know the issues you are facing in 10.1 regards, Muhammad Fahad Khan JNCIP - M/T # 834 IT Specialist Global Technology Services, IBM fa...@pk.ibm.com +92-321-2370510 +92-301-8247638 Skype: fahad-ibm http://www.linkedin.com/in/muhammadfahadkhan On Mon, Jun 14, 2010 at 2:08 PM, eddaibouni bilal wrote: > Hello all, > > Is there any reason to believe that 10.1R1 may have issues with JSRP that > > are resolved, or at least work better in other release? If yes, which > Software release whould you recommend? > > Best Regards > ___ > 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] IS-IS database leaking across virtual routers?
Alan, Actually, I did implement your workaround before with the static host mapping. But that is rather cosmetic when compared to something like the overload bit. In theory (or at least, in *my* theory), setting the IS-IS overload bit in one virtual routing instance should not interfere with IS-IS in another virtual routing instance. Unfortunately, the observed behavior on the MX platform suggests some form of leaking. I'm just not entirely convinced now that a "virtual router" really means a separate link-state database per virtual router. Within this context, a virtual router should behave just like a physical router --- or like a logical router, for that matter. Am I mistaken here? Clarke Morledge College of William and Mary Information Technology - Network Engineering Jones Hall (Room 18) Williamsburg VA 23187 On Sun, 13 Jun 2010, Alan Gravett wrote: Use static host mapping for each VR/lo0.x to avoid confusion set system static-host-mapping R1 sysid 0100.0011.0001 and so on... On Fri, Jun 11, 2010 at 7:23 PM, Clarke Morledge wrote: I am trying to figure out how Junos handles IS-IS in an environment with virtual routers (VRs). I see weird behvavior with some MX routers running 9.6 where some TLV information and some other details are "bleeding" between different VRs when IS-IS is the routing protocol in those VRs. By default, routing information in one VR should always remain separate from routing information in a different VR. With our MX infrastructure, we are stacking a bunch of different network topologies on top of one another using VRs to keep the routing tables separate. I would assume that if you run IS-IS in each VR that you will have a separate IS-IS database per VR, analogous to having a separate routing table per VR. But I am having my doubts. SNIP---SNIP- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] E120 port flapping
Dear All, I am facing issue with Juniper E120. Its ports are flapping every every two to three months. We opened the case with Jtec as well and they are asking to upgrade the junos. Any idea why it is happening, today i checked the logs after flapping and logs says: ERROR 06/15/2010 22:40:09 GMT+3 ipProfileMgr: doDcmIpIntfCreate : Creation of IP interface/address failed with status: lower layer bind failed ERROR 06/15/2010 22:51:06 GMT+3 dosProtection: Flow is suspicious: GigabitEthernet0/0/3.10102.255041 for control protocol: IP Normal Path MTU source might be on slot 0 with rate 85 pps ERROR 06/15/2010 22:51:18 GMT+3 dosProtection: Flow is suspicious: GigabitEthernet0/0/3.10107.8939 for control protocol: IP Normal Path MTU source might be on slot 0 with rate 110 pps What i get from these logs is we went under dos attack and i guess this is always the case when our ports flaps. Can anyone help me out if this is possible to disable the flapping of the port if it is by default on some threshold. Regards, Raheel ___ 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
Hi Giany, Stefan, Thank you both for getting back to me and for your input. I really appreciate it. I will consider the VMWare configurations as my last and quickest resort, but I still would like to get the qemu/GNS working as I would like to do LAB testing between Cisco and Juniper without having to Tab between GNS and VMware etc.. Giany, Can you perhaps give me a qemu config for what you have just explained? I have tried going the tap route but for some reason TAP interfaces just doesn't want to work on my machine. I have TunTap package from http://tuntaposx.sourceforge.net/ installed on my machine, but still no luck. Here is output I get when running image with tap: DeonV-MBPro:JNCIP DeonV$ qemu R1.img -m 96 -nographic -daemonize -serial telnet::2001,server,nowait -localtime -net nic,vlan=1,macaddr=00:aa:00:60:00:01,model=e1000 -net tap,vlan=1,ifname=tap0,script=no warning: could not open /dev/tap: no virtual network emulation qemu: Could not initialize device 'tap' DeonV-MBPro:JNCIP DeonV$ ls /dev/tap tap0 tap1 tap10 tap11 tap12 tap13 tap14 tap15 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 DeonV-MBPro:JNCIP DeonV$ ls /dev/tap Thank you again for your guidance. Kind Regards Deon Vermeulen Fax2Email: 088628731 email: vermeulen.d...@gmail.com On Jun 15, 2010, at 3:46 PM, Giany wrote: > Hello, > > If you say that you see the ARP packets there then most likely you did not > set the udp tunnels properly and the packets are not sent to the right router > interface. A while ago when I was playing with that topology I've used the > net=tap option from qemu and I was able to ping between routers. > > > > --- On Tue, 6/15/10, Deon Vermeulen wrote: > >> From: Deon Vermeulen >> Subject: [j-nsp] Olive Qemu/GNS3 networking issue on Snow Leopard >> To: juniper-nsp@puck.nether.net >> Date: Tuesday, June 15, 2010, 5:24 AM >> 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] Olive Qemu/GNS3 networking issue on Snow Leopard
Hello, If you say that you see the ARP packets there then most likely you did not set the udp tunnels properly and the packets are not sent to the right router interface. A while ago when I was playing with that topology I've used the net=tap option from qemu and I was able to ping between routers. --- On Tue, 6/15/10, Deon Vermeulen wrote: > From: Deon Vermeulen > Subject: [j-nsp] Olive Qemu/GNS3 networking issue on Snow Leopard > To: juniper-nsp@puck.nether.net > Date: Tuesday, June 15, 2010, 5:24 AM > 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] Olive Qemu/GNS3 networking issue on Snow Leopard
Why use Qemu/GNS3? I prepared for JNCIP entirely using traditional Olives in VMware Fusion on a Mac. All you need to do is add a few additional vmnets to the VMware configuration files and then modify each Olive's individual configurations to map the E1000s NICs to specific vmnets. Much, much easier than Qemu/GNS3 IMO. Stefan Fouant, CISSP, JNCIEx2 www.shortestpathfirst.net GPG Key ID: 0xB5E3803D -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 8: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
[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
