[j-nsp] Route Precedence
Hi all, I have a pair of EX4200's which are running iBGP to a pair of J6350's. I am seeing some strange behaviour with the routing on them. The EX4200's have a few different VLANs setup: vlan 50 - Used to connect to a J6350 vlan 100 - The VLAN the devices I am trying to reach are on The devices on vlan 100 are on the 10.10.10.0/24 range, with the EX4200's being the gateway for that network (it has been assigned 10.10.10.254). The problem I am seeing is from the EX4200's I can reach any device in that network fine. From the J6350's I can reach SOME devices but not others. I have not been able to find a pattern for this - an example device I have plugged in is a Dell blade chassis. It has a management controller that sits on 10.10.10.100 which I can get to from both the EX4200's and the J6350's. Each blade in the chassis is also assigned an IP for management through the same controller, in this case 10.10.10.101-117. I can't reach the individual blade management IP's from the J6350's yet from the EX4200's I can reach them fine. It has me a bit confused as it uses the same port on the EX4200's. For the below examples, here is the IP addressing (these are obviously not real): 99.99.99.240/30 - acc-core vlan50 (99.99.99.241) and acc-bdr1 ge-0/0/0 (99.99.99.242) 99.99.99.253 - acc-core lo0 On the J6350's the route for 10.10.10.0/24 is learnt via iBGP: root@acc-bdr1 show route 10.10.10.0 inet.0: 363930 destinations, 363932 routes (170427 active, 0 holddown, 193504 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.0/24 *[BGP/170] 00:49:35, localpref 100, from 99.99.99.253 AS path: I to 99.99.99.241 via ge-0/0/0.0 That route does seem to work, if I ping any IP in 10.10.10.0/24 (even the 'non-working' IPs) and run a tcpdump on the J6350 I can see the traffic heading out to the EX4200's. As a test, I added a static route for 10.10.10.101/32 with a next hop of 10.10.10.254 on the J6350. This doesn't show in the routing table on the J6350: root@acc-bdr1 show configuration routing-options static route 10.10.10.101/32 next-hop 10.10.10.254; root@acc-bdr1 show route 10.10.10.101 inet.0: 363933 destinations, 363935 routes (170429 active, 0 holddown, 193505 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.0/24 *[BGP/170] 00:54:12, localpref 100, from 99.99.99.253 AS path: I to 99.99.99.241 via ge-0/0/0.0 On the EX4200 the route is there correctly: root@acc-core show route 10.10.10.101 inet.0: 16384 destinations, 16384 routes (16384 active, 0 holddown, 0 hidden) Restart Complete + = Active Route, - = Last Active, * = Both 10.10.10.0/24 *[Direct/0] 00:55:58 via vlan.100 After the route was added, the EX4200 had the power cut and restored and I could magically ping 10.10.10.101 from the J6350 with no other config changes. The power was cut again, and I then lost the ability to ping it from the J6350, but I could still ping it from the EX4200. I have no idea why this is so I am a bit confused. The J6350 has no filters in place currently, it is running the router config too with the security features disabled. Is there anything obvious I'm missing? Thanks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Route Precedence
On 13/07/2011 2:27 PM, Chris wrote: snip To add to the already long email, here is some more examples of whats happening: From the 10.10.10.100 device, trying to ping the 'acc-bdr1' (J6350) device works: traceroute to 99.99.99.242 (99.99.99.242), 30 hops max, 40 byte packets 1 10.10.10.254 (10.10.10.254) 0.996 ms 0.699 ms 0.66 ms 2 99.99.99.242 (99.99.99.242) 1.928 ms 1.589 ms 1.978 ms Yet if I try it from a device that I CANT ping from acc-bdr1 (the source being 10.10.10.30): [root@acc-nx4cs ~]# traceroute -n 99.99.99.242 traceroute to 99.99.99.242 (99.99.99.242), 30 hops max, 40 byte packets 1 10.10.10.254 4.021 ms 3.981 ms 3.958 ms 2 * * * 3 * * * 4 * * * It's like something is filtering certain IP's from getting out but the config doesn't have anything like that in it so it has me stumped. Any help is much appreciated! Thanks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Route Precedence
On Tue, Jul 12, 2011 at 11:35 PM, Chris li...@blackhat.bz wrote: On 13/07/2011 2:27 PM, Chris wrote: snip To add to the already long email, here is some more examples of whats happening: From the 10.10.10.100 device, trying to ping the 'acc-bdr1' (J6350) device works: traceroute to 99.99.99.242 (99.99.99.242), 30 hops max, 40 byte packets 1 10.10.10.254 (10.10.10.254) 0.996 ms 0.699 ms 0.66 ms 2 99.99.99.242 (99.99.99.242) 1.928 ms 1.589 ms 1.978 ms Yet if I try it from a device that I CANT ping from acc-bdr1 (the source being 10.10.10.30): [root@acc-nx4cs ~]# traceroute -n 99.99.99.242 traceroute to 99.99.99.242 (99.99.99.242), 30 hops max, 40 byte packets 1 10.10.10.254 4.021 ms 3.981 ms 3.958 ms 2 * * * 3 * * * 4 * * * Wow. Weird situation. In the case of the traceroute above (from 10.10.10.30 to 99.99.99.242), it only gets back ICMP messages from your EX but not the J series. What route does the EX show for 99.99.99.242? In the case of the static route that you added to the J series, the route may not have been installed by default as indirect next-hops are disabled by default. Since the router has no directly-connected interface to 10.10.10.0/24, it's not sure that's what you want to do and will just take the route it already has (the one learned via iBGP). You can set routing-options forwarding-table indirect-next-hop to enable this functionality. I would just trace down the path to the host that isn't working and look at the routing and switching tables of anything along the path and debug the path from the source to the destination, and then back again. A route may just be missing somewhere (though this wouldn't explain why only some IP-paths break). Out of curiosity, is there any discernible pattern to the unreachable IPs (every other, every four, etc.)? All the times that I've seen the some-IPs-are-reachable-but-not-others problem, it's been due to a link aggregation or ECMP configuration that has a failed link or IP path along the way that isn't being communicated (and shutdown) by higher layers. Cheers, jof ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Route Precedence
Hi Chris, At a guess, It looks like you're trying to dump 170,000 routes from your Border: inet.0: 363930 destinations, 363932 routes (170427 active, 0 holddown, 193504 hidden) into your core EX4200: inet.0: 16384 destinations, 16384 routes (16384 active, 0 holddown, 0 hidden) which is topping out at 16k (which is over the 10k supported according to the data sheet): Without knowing your full topology, it's hard to suggest a workaround, but it would be something like create a summary default from your border for your internet routes, and only redistribute your own routes over your iBGP and every thing should work fine. I think the reason you're seeing internal routes work sometimes (after a power cut) is due to the order they are being added to the route table in (eg: sometimes it's within the first 16k and sometimes it's not) Cheers, Ben On 13/07/2011, at 4:27 PM, Chris wrote: Hi all, I have a pair of EX4200's which are running iBGP to a pair of J6350's. I am seeing some strange behaviour with the routing on them. The EX4200's have a few different VLANs setup: vlan 50 - Used to connect to a J6350 vlan 100 - The VLAN the devices I am trying to reach are on The devices on vlan 100 are on the 10.10.10.0/24 range, with the EX4200's being the gateway for that network (it has been assigned 10.10.10.254). The problem I am seeing is from the EX4200's I can reach any device in that network fine. From the J6350's I can reach SOME devices but not others. I have not been able to find a pattern for this - an example device I have plugged in is a Dell blade chassis. It has a management controller that sits on 10.10.10.100 which I can get to from both the EX4200's and the J6350's. Each blade in the chassis is also assigned an IP for management through the same controller, in this case 10.10.10.101-117. I can't reach the individual blade management IP's from the J6350's yet from the EX4200's I can reach them fine. It has me a bit confused as it uses the same port on the EX4200's. For the below examples, here is the IP addressing (these are obviously not real): 99.99.99.240/30 - acc-core vlan50 (99.99.99.241) and acc-bdr1 ge-0/0/0 (99.99.99.242) 99.99.99.253 - acc-core lo0 On the J6350's the route for 10.10.10.0/24 is learnt via iBGP: root@acc-bdr1 show route 10.10.10.0 inet.0: 363930 destinations, 363932 routes (170427 active, 0 holddown, 193504 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.0/24 *[BGP/170] 00:49:35, localpref 100, from 99.99.99.253 AS path: I to 99.99.99.241 via ge-0/0/0.0 That route does seem to work, if I ping any IP in 10.10.10.0/24 (even the 'non-working' IPs) and run a tcpdump on the J6350 I can see the traffic heading out to the EX4200's. As a test, I added a static route for 10.10.10.101/32 with a next hop of 10.10.10.254 on the J6350. This doesn't show in the routing table on the J6350: root@acc-bdr1 show configuration routing-options static route 10.10.10.101/32 next-hop 10.10.10.254; root@acc-bdr1 show route 10.10.10.101 inet.0: 363933 destinations, 363935 routes (170429 active, 0 holddown, 193505 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.0/24 *[BGP/170] 00:54:12, localpref 100, from 99.99.99.253 AS path: I to 99.99.99.241 via ge-0/0/0.0 On the EX4200 the route is there correctly: root@acc-core show route 10.10.10.101 inet.0: 16384 destinations, 16384 routes (16384 active, 0 holddown, 0 hidden) Restart Complete + = Active Route, - = Last Active, * = Both 10.10.10.0/24 *[Direct/0] 00:55:58 via vlan.100 After the route was added, the EX4200 had the power cut and restored and I could magically ping 10.10.10.101 from the J6350 with no other config changes. The power was cut again, and I then lost the ability to ping it from the J6350, but I could still ping it from the EX4200. I have no idea why this is so I am a bit confused. The J6350 has no filters in place currently, it is running the router config too with the security features disabled. Is there anything obvious I'm missing? Thanks ___ 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] Route Precedence
On 13/07/2011 3:29 PM, Ben Dale wrote: Hi Chris, Hi all, Thanks for the replies - the issue is as above, the routing table was topping out. I should have checked that - it completely slipped my mind. Thanks again all! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Route Precedence
On Wed, Jul 13, 2011 at 12:31 AM, Chris li...@blackhat.bz wrote: On 13/07/2011 3:29 PM, Ben Dale wrote: Hi Chris, Hi all, Thanks for the replies - the issue is as above, the routing table was topping out. I should have checked that - it completely slipped my mind. Nice catch, Ben! The EXes are not geared to be routers, but are fine for injecting dynamic routes and holding a modest IGP's worth of routes. I suppose in many environments, do you really care if a downstream switch knows about every route on the Internet -- in most cases, probably not. --j ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Route Precedence
Hi Chris, Just a hunch but I suspect the FIB on your EX4200 is full (I seem to recall the EX can only hold 16K routes), which is probably causing all kinds of weirdness: inet.0: 16384 destinations, 16384 routes (16384 active, 0 holddown, 0 You probably want to filter your routes down to what you receive from WAIX and a default route. -Shane On 13/07/2011, at 2:27 PM, Chris wrote: Hi all, I have a pair of EX4200's which are running iBGP to a pair of J6350's. I am seeing some strange behaviour with the routing on them. The EX4200's have a few different VLANs setup: vlan 50 - Used to connect to a J6350 vlan 100 - The VLAN the devices I am trying to reach are on The devices on vlan 100 are on the 10.10.10.0/24 range, with the EX4200's being the gateway for that network (it has been assigned 10.10.10.254). The problem I am seeing is from the EX4200's I can reach any device in that network fine. From the J6350's I can reach SOME devices but not others. I have not been able to find a pattern for this - an example device I have plugged in is a Dell blade chassis. It has a management controller that sits on 10.10.10.100 which I can get to from both the EX4200's and the J6350's. Each blade in the chassis is also assigned an IP for management through the same controller, in this case 10.10.10.101-117. I can't reach the individual blade management IP's from the J6350's yet from the EX4200's I can reach them fine. It has me a bit confused as it uses the same port on the EX4200's. For the below examples, here is the IP addressing (these are obviously not real): 99.99.99.240/30 - acc-core vlan50 (99.99.99.241) and acc-bdr1 ge-0/0/0 (99.99.99.242) 99.99.99.253 - acc-core lo0 On the J6350's the route for 10.10.10.0/24 is learnt via iBGP: root@acc-bdr1 show route 10.10.10.0 inet.0: 363930 destinations, 363932 routes (170427 active, 0 holddown, 193504 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.0/24 *[BGP/170] 00:49:35, localpref 100, from 99.99.99.253 AS path: I to 99.99.99.241 via ge-0/0/0.0 That route does seem to work, if I ping any IP in 10.10.10.0/24 (even the 'non-working' IPs) and run a tcpdump on the J6350 I can see the traffic heading out to the EX4200's. As a test, I added a static route for 10.10.10.101/32 with a next hop of 10.10.10.254 on the J6350. This doesn't show in the routing table on the J6350: root@acc-bdr1 show configuration routing-options static route 10.10.10.101/32 next-hop 10.10.10.254; root@acc-bdr1 show route 10.10.10.101 inet.0: 363933 destinations, 363935 routes (170429 active, 0 holddown, 193505 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.0/24 *[BGP/170] 00:54:12, localpref 100, from 99.99.99.253 AS path: I to 99.99.99.241 via ge-0/0/0.0 On the EX4200 the route is there correctly: root@acc-core show route 10.10.10.101 inet.0: 16384 destinations, 16384 routes (16384 active, 0 holddown, 0 hidden) Restart Complete + = Active Route, - = Last Active, * = Both 10.10.10.0/24 *[Direct/0] 00:55:58 via vlan.100 After the route was added, the EX4200 had the power cut and restored and I could magically ping 10.10.10.101 from the J6350 with no other config changes. The power was cut again, and I then lost the ability to ping it from the J6350, but I could still ping it from the EX4200. I have no idea why this is so I am a bit confused. The J6350 has no filters in place currently, it is running the router config too with the security features disabled. Is there anything obvious I'm missing? Thanks ___ 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] Back-reference in JunOS regular expressions
Hi, Is back-reference, like (.)( \1)*$, provided by the JunOS AS-path matching engine? (This should match, for instance, ^6453$, ^6453_6453$, ^6453_6453_6453$, and so on...) I can't find a firm statement in the JunOS documentation, and some tests makes me believe it's not implemented. Or am I mistaken with the syntax? (I can use back-reference in 'replace', etc, etc...) Cheers, mh 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
[j-nsp] m10i RE-5.0 Memory Upgrade
Hi All We are looking for some way to Upgrade the Memory of the RE-5.0 (512Mb Memory Base) on M10i Router. Anybody has perform this before ? is this possible ? Thanks !! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Back-reference in JunOS regular expressions
Hi, Is back-reference, like (.)( \1)*$, provided by the JunOS AS-path matching engine? (This should match, for instance, ^6453$, ^6453_6453$, ^6453_6453_6453$, and so on...) Never tried this, but do you mean something like ([0-9]*)( \1)* ? This works with egrep: $ echo 123 123 | egrep '^([0-9]*)( \1)*$' 123 123 $ echo 123 124 | egrep '^([0-9]*)( \1)*$' $ Alex ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] ASRe: Back-reference in JunOS regular expressions
Le mercredi 13 juillet 2011 à 15:15 +0100, Alexander Frolkin a écrit : Hi, Is back-reference, like (.)( \1)*$, provided by the JunOS AS-path matching engine? (This should match, for instance, ^6453$, ^6453_6453$, ^6453_6453_6453$, and so on...) Never tried this, but do you mean something like ([0-9]*)( \1)* ? No, in AS-path context, ASNs are the atoms (thus (.) above). This works with egrep: $ echo 123 123 | egrep '^([0-9]*)( \1)*$' 123 123 $ echo 123 124 | egrep '^([0-9]*)( \1)*$' $ Yes. mh Alex 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] Back-reference in JunOS regular expressions
Hi, On Wed, Jul 13, 2011 at 15:18, Michael Hallgren m.hallg...@free.fr wrote: I can't find a firm statement in the JunOS documentation, and some tests makes me believe it's not implemented. Or am I mistaken with the syntax? (I can use back-reference in 'replace', etc, etc...) see https://puck.nether.net/pipermail/juniper-nsp/2010-July/017473.html Not supported. I requested an ER back then, don't think it ever got implemented... --Daniel. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] m10i RE-5.0 Memory Upgrade
On Jul 13, 2011, at 9:07 AM, Mario Andres Rueda Jaimes wrote: We are looking for some way to Upgrade the Memory of the RE-5.0 (512Mb Memory Base) on M10i Router. Anybody has perform this before ? is this possible ? Sure is, there are three DIMM slots on your RE-5.0. Assuming you probably have two 256MB sticks in there now. Previous thread on this, related to 3rd party memory option too: http://puck.nether.net/pipermail/juniper-nsp/2005-February/003780.html ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Making an SRX a Router and Security Device, for an enterprise
Hi all, Two of us here have almost lost our minds trying to do this. So we're hoping for a suitably strong fu-injection. We have an MX80 and an SRX650, and shortly we'll have another MX and SRX, with further to come. Elsewhere we've got a mixture of SRX, J-series (some Js all packet-mode, some flow-mode), and a couple Ms. Little of this is relevant though. Obviously we got the little SRX to offer security, as only certain traffic has to be filtered. We also got it so all our intersite traffic can be nicely encrypted (IPSec). We're pretty happy with policy filters, routing instances, interface rib-groups, etc, on the MX to send the right traffic to the SRX. But one area we're seriously stuck on is the IPSec, and the asymmetry in intersite routing that will occur. We're anycasting services. The available documentation, and examples floating around the interwebs, are aimed more at service providers doing MPLS with customers, but we're an enterprise with little interest in MPLS and no customers routes we need to carry separately. What I *think* we need is; st0.X/Y/Z in the master. gr-0/0/0.X/Y/Z over st0.X/Y/Z tied to a packet-mode VR. Intersite OSPF. ge-2/0/8.X tied to the same packet-mode VR. OSPF to the MX. ge-2/0/9.X/Y/Z tied to another VR, but flow-mode. Various interfaces and zones for the MX to forward to, policies and snat, an interface for the SRX to return SNAT'd traffic, and a couple static routes for it to return the traffic to the right unit on the MX. How to go about making a packet-mode VR and a flow-mode VR, and whether I am infact using the right terms, is where I'm mostly stuck. One thing I don't believe we want, and is something fairly central to one document (3500192-en.pdf) is the lt- interface between Services-VR and Packet-VR. We think that's counter-productive for us, as having flow-mode services act as 'an-SRX on a stick' is right, so traffic to the MX from another site is only seen (i.e. not encapsulated) and statefully tracked if we explicitally choose it to be so. Any hints on configuration, pointers to the One True Path (TM), or even confirmation we're already on the right path, all gladly welcomed. Thanks -- Mike Williams ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Únete a mi red en LinkedIn
LinkedIn Nam Nguyen ha solicitado añadirte como contacto en LinkedIn: -- Me gustaría añadirte a mi red profesional en LinkedIn. Aceptar invitación de Nam Nguyen http://www.linkedin.com/e/u96119-gq37xzgy-71/XqZSB0oknt5cTYQCxwU5LkoQzUifoQRJSaUSlk19WH/blk/I1516889603_3/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYPnPcMdzAUe3oNdj59bSJfdAhxcSR1bPsPdPkRcjcPdjcLrCBxbOYWrSlI/EML_comm_afe/ Ver invitación de Nam Nguyen http://www.linkedin.com/e/u96119-gq37xzgy-71/XqZSB0oknt5cTYQCxwU5LkoQzUifoQRJSaUSlk19WH/blk/I1516889603_3/3dvcP0SejwUdz4RckALqnpPbOYWrSlI/svi/ -- ¿SABÍAS que LinkedIn puede ayudarte a encontrar respuestas a tus preguntas más difíciles? Publica esas preguntas tan molestas en Respuestas LinkedIn y haz uso del conocimiento de los expertos profesionales más destacados del mundo: http://www.linkedin.com/e/u96119-gq37xzgy-71/ask/inv-23/ -- (c) 2011, LinkedIn Corporation ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] m10i RE-5.0 Memory Upgrade
Hi, The RE 400 (CLI name RE.5) can be upgraded. It does supports upto 786B of SDRAM. Please check the following link: Page#4 and table:32. http://www.juniper.net/techpubs/software/nog/nog-hardware/download/routing-engines.pdf -- Thanks, Siva ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
