Re: [j-nsp] Odd issue with ARP in different subnet
On 03/09/2011 03:43 PM, Chris Adams wrote: I have run into an odd issue with ARP on an EX switch that I think is a bug in JUNOS, but I wanted to see what others thought before I tried JTAC (maybe I'm missing something). I have an EX2200 switch that cannot talk to one of my recursive DNS servers. The switch is in subnet a.b.c.0/27, while the DNS IP is in x.y.z.0/29. The DNS IP is anycasted, and the primary server serving it is in the same a.c.b.0/27 subnet as the switch (the DNS IP is a secondary IP on the same interface). When the switch tries to reach the DNS IP, it sends the packet to the default router. The router sends it to the server, and the server sends an ARP request for the switch's IP. The sending IP address in the ARP request is the DNS IP. As far as I can tell, JUNOS doesn't send a response to the ARP request. Yeah, we see this a lot. You need the following in /etc/sysctl.conf: # These values make linux be sensible about making and replying # to ARP requests - specifically they force ARP requests to come # from an in-subnet IP, and ignore ARP replies for out-of-subnet # addresses net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2 ...and then you need to move the anycast /32 to the loopback (lo) interface. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Odd issue with ARP in different subnet
On 03/10/2011 02:09 AM, Chris Adams wrote: Once upon a time, Keegan Holleykeegan.hol...@sungard.com said: I don't think the server should arp for 10.1.1.5 from 10.2.2.2. Devices don't usually arp (or answer) for things that aren't in the same subnet. Can you name anything (other than the EX) that behaves as you describe? We've seen this cause problems with other (non-Juniper) things. I think Windows barfs on it in certain versions. It's probably a bug in JunOS in theory, but in my experience you'll need to change the ARP sysctl values to be 100% sure of it working. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] virtual router, M or J?
On 10/03/11 18:42, Richard Zheng wrote: SRX seems to be a really good candidate. It looks like all models have almost identical features, the only difference is performance. I will buy a SRX100, maybe even 2 to test high availability. The SRX100 is a nice test platform, but it does have a bunch of annoying limitations vs the rest of the line. (Jumbo frames, MPLS bits, a bunch of performance), although at least you can be sure it will work on anything. Customers may have overlapping address space and the virtual router may interact with their CPE routers too. That only needs a routing instance, not a full virtual router which makes things easier to manage. The only issue is that it doesn't support DC power and can't be deployed in some cases. Depends on the model. SRX240 650 have DC variants (see the HW guide), SRX1400 will get DC according to the data sheet. J-series seems much more expensive and doesn't have nearly as many features. DC power is available though. Just wonder what's application? The J's are getting on a bit, they do support some interfaces that SRX don't (xDSL, T/E3, ISDN BRI), and except for needing ~1GB more RAM with the -ES (AKA SRX) code still make nice routing boxes for those places where 1Gb throughput isn't needed. M-series seems really over priced for this application. The smaller M's at this point are also old and due for replacement, the MX80 covers a lot, but wouldn't suit your needs due to (current) lack of services. If and when Juniper launch SONET MIC's I think that will be the end of the smaller M's. -- Julien Goodwin Studio442 Blue Sky Solutioneering signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] virtual router, M or J?
Hi Richard, On Thu, Mar 10, 2011 at 6:42 PM, Richard Zheng rzh...@gmail.com wrote: SRX seems to be a really good candidate. It looks like all models have almost identical features, the only difference is performance. I will buy a SRX100, maybe even 2 to test high availability. I can only speak for J and SRX as I have no first hand experience with M ... I recently did some performance testing of SRX240, J6350 and SRX650 -- in terms of pps, they come out in that order; SRX240 is out-performed by J6350 which is out-performed by SRX650. That might seem obvious as it's the same sequence dollars-wise but just because J is an older platform doesn't mean everything SRX is 'better'. If the SRX240 meets your pps needs, it's a great box; dirt cheap for what it can do. It's a big leap price-wise from SRX240 to SRX650. Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] IPv4 FIB corruption with 6vPE/protocols mpls ipv6-tunneling
All,
We use a bunch of J-series routers, currently running 10.1R1.8, to serve
100meg-connected remote sites.
These J-series are all MPLS L3VPN PEs (as well as P-routers, since it's
a routed ring for cost reasons). The vast majority of edge-facing
interfaces are in a routing instance. In that role, they work fine.
We wanted to enable 6vPE on these routers, to deploy v6 inside the
L3VPNs, but we ran into a problem on one router.
This router has a 3d party connected. Their interface is *not* in a
routing-instance, and already has both IPv4 and IPv6 enabled. When we do
this:
set protocols mpls ipv6-tunneling
...the 3rd-parties IPv4 connectivity breaks. Their routes remain
advertised, and the LDP FECs and so forth all look ok - but the traffic
does not reach them (or possibly the return-path traffic doesn't come
back - it's hard to be sure).
IPv4 connectivity can be restored by *disabling* their static IPv6
route, and doing a clear ldp session:
deactivate routing-options rib inet6.0 static route x:x/48
commit and-quit
clear ldp session
It's worth noting that, at this site, we actually have two PE routers,
and use VRRP to provide resilient routing to the customer for IPv4. The
customer IPv6 is only configured on one router however.
Looking at the traffic path from our core, it goes:
border router - label imposed
hop 2 - label swap
hop N-1 - label swap
hop N - label pop
broken router - unlabelled IPv4 traffic
...so I guess one of four things is happening:
1. The broken router is dropping the unlabelled IPv4 on receive
2. The broken router is failing to egress the IPv4 to the customer
3. The customer return-path traffic is being dropped in ingress
4. The customer return-path traffic is failing to egress to the
next-hop P-router
Is there any way I can determine which of these is the case?
The config sort-of looks like this (customer-facing interface is
ge-0/0/2.951):
interfaces {
ge-0/0/0 {
description to another P/PE router
mtu 1544;
unit 0 {
family inet {
address w.w.w.w/31;
}
family inet6 {
address x:x/112;
}
family mpls;
}
}
ge-0/0/2 {
vlan-tagging;
unit 951 {
description 3rd party;
vlan-id 951;
family inet {
rpf-check;
address a.b.c.d/27 {
vrrp-group 1 {
apply-groups VRRP;
virtual-address a.b.c.1;
}
}
}
family inet6 {
rpf-check;
address 2001:db8:1::1/112;
}
}
}
}
routing-options {
rib inet6.0 {
static {
route 2001:db8:100::/48 next-hop 2001:db8:1::2;
}
}
}
protocols {
mpls {
inactive: ipv6-tunneling;
icmp-tunneling;
interface ge-0/0/0.0;
}
bgp {
# standard L3VPN stuff here
}
ldp {
interface ge-0/0/0.0;
}
}
routing-instances {
# loads and loads of these
{
description Gold network;
instance-type vrf;
interface ge-0/0/2.xx;
route-distinguisher a.b.c.d:1;
vrf-target target:a.b.c.d:1;
vrf-table-label;
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IPv4 FIB corruption with 6vPE/protocols mpls ipv6-tunneling
Have you tried to disable rpf check ?
Thanks
On 3/10/11, Phil Mayers p.may...@imperial.ac.uk wrote:
All,
We use a bunch of J-series routers, currently running 10.1R1.8, to serve
100meg-connected remote sites.
These J-series are all MPLS L3VPN PEs (as well as P-routers, since it's
a routed ring for cost reasons). The vast majority of edge-facing
interfaces are in a routing instance. In that role, they work fine.
We wanted to enable 6vPE on these routers, to deploy v6 inside the
L3VPNs, but we ran into a problem on one router.
This router has a 3d party connected. Their interface is *not* in a
routing-instance, and already has both IPv4 and IPv6 enabled. When we do
this:
set protocols mpls ipv6-tunneling
...the 3rd-parties IPv4 connectivity breaks. Their routes remain
advertised, and the LDP FECs and so forth all look ok - but the traffic
does not reach them (or possibly the return-path traffic doesn't come
back - it's hard to be sure).
IPv4 connectivity can be restored by *disabling* their static IPv6
route, and doing a clear ldp session:
deactivate routing-options rib inet6.0 static route x:x/48
commit and-quit
clear ldp session
It's worth noting that, at this site, we actually have two PE routers,
and use VRRP to provide resilient routing to the customer for IPv4. The
customer IPv6 is only configured on one router however.
Looking at the traffic path from our core, it goes:
border router - label imposed
hop 2 - label swap
hop N-1 - label swap
hop N - label pop
broken router - unlabelled IPv4 traffic
...so I guess one of four things is happening:
1. The broken router is dropping the unlabelled IPv4 on receive
2. The broken router is failing to egress the IPv4 to the customer
3. The customer return-path traffic is being dropped in ingress
4. The customer return-path traffic is failing to egress to the
next-hop P-router
Is there any way I can determine which of these is the case?
The config sort-of looks like this (customer-facing interface is
ge-0/0/2.951):
interfaces {
ge-0/0/0 {
description to another P/PE router
mtu 1544;
unit 0 {
family inet {
address w.w.w.w/31;
}
family inet6 {
address x:x/112;
}
family mpls;
}
}
ge-0/0/2 {
vlan-tagging;
unit 951 {
description 3rd party;
vlan-id 951;
family inet {
rpf-check;
address a.b.c.d/27 {
vrrp-group 1 {
apply-groups VRRP;
virtual-address a.b.c.1;
}
}
}
family inet6 {
rpf-check;
address 2001:db8:1::1/112;
}
}
}
}
routing-options {
rib inet6.0 {
static {
route 2001:db8:100::/48 next-hop 2001:db8:1::2;
}
}
}
protocols {
mpls {
inactive: ipv6-tunneling;
icmp-tunneling;
interface ge-0/0/0.0;
}
bgp {
# standard L3VPN stuff here
}
ldp {
interface ge-0/0/0.0;
}
}
routing-instances {
# loads and loads of these
{
description Gold network;
instance-type vrf;
interface ge-0/0/2.xx;
route-distinguisher a.b.c.d:1;
vrf-target target:a.b.c.d:1;
vrf-table-label;
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Sent from my mobile device
./diogo -montagner
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IPv4 FIB corruption with 6vPE/protocols mpls ipv6-tunneling
On 10/03/11 12:45, Diogo Montagner wrote: Have you tried to disable rpf check ? I hadn't actually; good suggestion. Do you have a specific bug in mind, or just guessing? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] virtual router, M or J?
I have deployed a SRX240 with DC power. -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Richard Zheng Sent: Thursday, March 10, 2011 1:43 AM To: Julien Goodwin Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] virtual router, M or J? On Wed, Mar 9, 2011 at 7:58 PM, Julien Goodwin jgood...@studio442.com.auwrote: On 10/03/11 16:50, Julien Goodwin wrote: It sounds like what you really want is just an SRX (Probably 2x240, 650 or 1400). Scratch the 240's, from the data sheet: Maximum security zones: - SRX240 - 32 - SRX650 - 128 - SRX3k - 256 (1k should be the same, but not listed on it's data sheet) And unless you have overlapping address space there's no need for virtual routers at all (and even then they'd only need to be routing instances) The J's at this point are essentially just (branch) SRX's with a different chip. SRX seems to be a really good candidate. It looks like all models have almost identical features, the only difference is performance. I will buy a SRX100, maybe even 2 to test high availability. Customers may have overlapping address space and the virtual router may interact with their CPE routers too. The only issue is that it doesn't support DC power and can't be deployed in some cases. J-series seems much more expensive and doesn't have nearly as many features. DC power is available though. Just wonder what's application? M-series seems really over priced for this application. 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] IPv4 FIB corruption with 6vPE/protocols mpls ipv6-tunneling
Not bug. But just guessing the urpf may be the root cause of your problem. Thanks On 3/10/11, Phil Mayers p.may...@imperial.ac.uk wrote: On 10/03/11 12:45, Diogo Montagner wrote: Have you tried to disable rpf check ? I hadn't actually; good suggestion. Do you have a specific bug in mind, or just guessing? -- Sent from my mobile device ./diogo -montagner ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] virtual router, M or J?
This is fantastic! Thanks for the valuable input. On Wed, Mar 9, 2011 at 11:38 PM, Julien Goodwin jgood...@studio442.com.auwrote: On 10/03/11 18:42, Richard Zheng wrote: SRX seems to be a really good candidate. It looks like all models have almost identical features, the only difference is performance. I will buy a SRX100, maybe even 2 to test high availability. The SRX100 is a nice test platform, but it does have a bunch of annoying limitations vs the rest of the line. (Jumbo frames, MPLS bits, a bunch of performance), although at least you can be sure it will work on anything. Customers may have overlapping address space and the virtual router may interact with their CPE routers too. That only needs a routing instance, not a full virtual router which makes things easier to manage. The only issue is that it doesn't support DC power and can't be deployed in some cases. Depends on the model. SRX240 650 have DC variants (see the HW guide), SRX1400 will get DC according to the data sheet. J-series seems much more expensive and doesn't have nearly as many features. DC power is available though. Just wonder what's application? The J's are getting on a bit, they do support some interfaces that SRX don't (xDSL, T/E3, ISDN BRI), and except for needing ~1GB more RAM with the -ES (AKA SRX) code still make nice routing boxes for those places where 1Gb throughput isn't needed. M-series seems really over priced for this application. The smaller M's at this point are also old and due for replacement, the MX80 covers a lot, but wouldn't suit your needs due to (current) lack of services. If and when Juniper launch SONET MIC's I think that will be the end of the smaller M's. -- Julien Goodwin Studio442 Blue Sky Solutioneering ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Difference between M320 and T320
As other have mentioned, port density due to the form factor is the biggest functional difference (if you're using Type 3's there is no difference). The Type 1 PIC's that are supported can be found here: http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/pic-t320-fpc-compat.html#jd0e25 http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/pic-t320-fpc-compat.html#jd0e25 Many PICs are interchangeable between the T and M series as well (the FPCs are not). This offers some investment protection if you choose to upgrade later. Here is a list: http://www.juniper.net/us/en/local/pdf/datasheets/1000253-en.pdf http://www.juniper.net/us/en/local/pdf/datasheets/1000253-en.pdf On Tue, Mar 8, 2011 at 5:48 AM, Jose Sanchez jasjuni...@gmail.com wrote: Hi guys, Does someone knows the difference between the M320 and the T320? I know that the T320 does not accept Type 1 FPC, but beyond that I don't know any differences, maybe something in the internal architecture? Thanks Jose ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Matthew Tighe matthew.e.ti...@gmail.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Allow BGp loops
You may need to use the independent domain knob depending on your topology: http://www.juniper.net/techpubs/en_US/junos10.4/topics/task/configuration/routing-independent-domain-attribute-set-disabling.html On Tue, Mar 8, 2011 at 9:08 AM, meryem Z merye...@hotmail.com wrote: Hello Community , on an M320 router running junos 9.6 I had a problem of BGP routes hidden due to BGP loops. So i used the command set routing-instances ri protocols bgp local-as as loops 2 to allow loops. but then i got the following error message : 'local-as' Invalid loop count configured error: configuration check-out failed Any idea about this problem? Thank you. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Matthew Tighe matthew.e.ti...@gmail.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
