Re: [j-nsp] MTU: old style vs new style trunk configuration on MX80
On Mon, Feb 13, 2012 at 7:04 PM, Doug Hanks dha...@juniper.net wrote: It's as expected; you have to use vlan-tagging to add the 4 bytes to the MTU. It's a documentation error. Thank you for your clarification. Regards, Dawid ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Random BGP peer drops
Hello, We have an MPLS network made up of many MX960s and MX80s. We run OSPF as our IGP - all links in area 0. BGP is used for signaling of all L2VPN VPLS. At this time we only have 1 L3VPN for mgmt. LDP is used for for transport LSPs. We have M10i as dedicated Route Reflectors. Most MX are on 10.4S5. M10i still on 10.0R3. Each PE peers with 2 RRs and has 2 diverse uplinks for redundancy. If 1 link fails, there's always another path. It's been rare but we've seen random iBGP peer drops. The first was several months ago. We've now seen 2 in the last week. 2 of the 3 were related to link failures. The primary path from the PE to the RR failed. BGP timed out after a bit. Here's an example: Feb 8 14:05:32 OURBOX-re0 mib2d[2279]: %DAEMON-4-SNMP_TRAP_LINK_DOWN: ifIndex 129, ifAdminStatus up(1), ifOperStatus down(2), ifName xe-7/0/0 Feb 8 14:05:32 OURBOX-re0 mib2d[2279]: %DAEMON-4-SNMP_TRAP_LINK_DOWN: ifIndex 120, ifAdminStatus up(1), ifOperStatus down(2), ifName xe-0/0/0 Feb 8 14:06:33 OURBOX-re0 rpd[1413]: %DAEMON-4: bgp_hold_timeout:3660: NOTIFICATION sent to 10.1.1.2 (Internal AS 123): code 4 (Hold Timer Expired Error), Reason: holdtime expired for 10.1.1.2 (Internal AS 123), socket buffer sndcc: 0 rcvcc: 0 TCP state: 4, snd_una: 1056225956 snd_nxt: 1056225956 snd_wnd: 16384 rcv_nxt: 3883304584 rcv_adv: 3883320968, hold timer 0 BGP holdtime is 90sec. This is more than enough time for OSPF to find the other path and converge. The BGP peer came back up before the link so things did eventually converge. The last BGP peer drop happened without any links failure. Out of the blue, BGP just went down. The logs on the PE: Feb 13 20:40:48 OUR-PE1 rpd[1159]: %DAEMON-4: bgp_hold_timeout:3660: NOTIFICATION sent to 10.1.1.2 (Internal AS 123): code 4 (Hold Timer Expired Error), Reason: holdtime expired for 10.1.1.2 (Internal AS 123), socket buffer sndcc: 0 rcvcc: 0 TCP state: 4, snd_una: 2149021074 snd_nxt: 2149021074 snd_wnd: 16384 rcv_nxt: 2049196833 rcv_adv: 2049213217, hold timer 0 Feb 13 20:40:48 OUR-PE1 rpd[1159]: %DAEMON-4-RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 10.1.1.2 (Internal AS 123) changed state from Established to Idle (event HoldTime) Feb 13 20:41:21 OUR-PE1 rpd[1159]: %DAEMON-4-RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 10.1.1.2 (Internal AS 123) changed state from OpenConfirm to Established (event RecvKeepAlive) The RR side shows the same: Feb 13 20:40:49 OUR-RR1-re0 rpd[1187]: %DAEMON-4-RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 10.1.1.61 (Internal AS 123) changed state from Established to Idle (event RecvNotify) Feb 13 20:40:49 OUR-RR1-re0 rpd[1187]: %DAEMON-4: bgp_read_v4_message:8927: NOTIFICATION received from 10.1.1.61 (Internal AS 123): code 4 (Hold Timer Expired Error), socket buffer sndcc: 57 rcvcc: 0 TCP state: 4, snd_una: 2049196833 snd_nxt: 2049196871 snd_wnd: 16384 rcv_nxt: 2149021095 rcv_adv: 2149037458, hold timer 1:03.112744 Feb 13 20:41:21 OUR-RR1-re0 rpd[1187]: %DAEMON-4-RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 10.1.1.61 (Internal AS 123) changed state from EstabSync to Established (event RsyncAck) Feb 13 20:41:30 OUR-RR1-re0 rpd[1187]: %DAEMON-3: bgp_send: sending 30 bytes to 10.1.1.61 (Internal AS 123) blocked (no spooling requested): Resource temporarily unavailable You can see the peer wasn't down long and re-established on it's own. The logs on the RR make it look like it received a msg from the PE that it was dropping the BGP session. The last error on the RR seems odd as well. Has anyone seen something like this before? We do have a case open regarding a large number of LSA retransmits. TAC is saying this is a bug related to NSR but shouldn't cause any negative impacts. I'm not sure if this is related. I'm considering opening a case for this as well but I'm not very confident I'll get far. Any help would be appreciated. Thanks, Serge ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Random BGP peer drops
Yes. That was the first thing we checked. I should've mentioned that. Serge From: sth...@nethelp.no sth...@nethelp.no To: se...@nbnet.nb.ca; sergevaut...@yahoo.ca Cc: juniper-nsp@puck.nether.net Sent: Tuesday, February 14, 2012 3:41:02 PM Subject: Re: [j-nsp] Random BGP peer drops It's been rare but we've seen random iBGP peer drops. The first was several months ago. We've now seen 2 in the last week. Have you verified that you have a consistent MTU throughout your net? Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Random BGP peer drops
I saw something similar on a T-series w/2 REs running 10.0, and it was related to an NSR bug that was causing the backup RE to thrash and push CPU through the roof on the primary. Also recall a mib2d bug resulting in high CPU, though I'm sure you would have noticed in either case. David On 14 February 2012 15:31, Serge Vautour sergevaut...@yahoo.ca wrote: Yes. That was the first thing we checked. I should've mentioned that. Serge From: sth...@nethelp.no sth...@nethelp.no To: se...@nbnet.nb.ca; sergevaut...@yahoo.ca Cc: juniper-nsp@puck.nether.net Sent: Tuesday, February 14, 2012 3:41:02 PM Subject: Re: [j-nsp] Random BGP peer drops It's been rare but we've seen random iBGP peer drops. The first was several months ago. We've now seen 2 in the last week. Have you verified that you have a consistent MTU throughout your net? Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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] next hop behavior within between VRFs
Hi Ido,
Thanks to Harry Reynolds, I also figured out how to accomplish what you wanted
even for traffic entering from a remote PE.
The trick is to apply the filter-based forwarding policy to the vrf-a
forwarding table rather than to a specific interface.
This requires to firewall filters with the exact same content (fbf and fbf2 in
my example). That's because the same firewall filter can not be applied to a
forwarding table and an interface.
The links below have been updated with the new configs.
--Stacy
On Feb 14, 2012, at 2:09 PM, Stacy W. Smith wrote:
Hi Ido,
I have a setup that accomplishes most of what you were asking. Take a look at
my topology and configs.
Topology:
http://dl.dropbox.com/u/13293084/j-nsp_topology/Topology.png
pe1 config
http://dl.dropbox.com/u/13293084/j-nsp_topology/pe1-config.txt
pe2 config
http://dl.dropbox.com/u/13293084/j-nsp_topology/pe2-config.txt
In my topology, server, ce-a1, r1, ce-a2, and r2 are all virtual routers on
pe2. (That's just because I only had two physical routers to set this up).
ce-a1 in my topology would be equivalent to your BRAS device.
In my topology, I use lt interfaces between vrf-b and inet.0, and I run a
iBGP session across those lt interfaces from vrf-b to inet.0. The inet.0 side
is configured as a route-reflector for the session to vrf-b. There are no lt
interfaces between vrf-a and vrf-b. I use filter-based forwarding to force
the traffic to the proxy server. My topology and configuration allows me to
force the traffic from ce-a1 to the Internet through the proxy server, and
also allows me to force the traffic from the Internet to ce-a1 back though
the proxy server.
The good news is this doesn't require any changes to the ce-a1 (BRAS) config.
There's a single iBGP session from ce-a1 to vrf-a in pe1.
The only thing that doesn't work in my topology is forcing traffic from ce-a2
to the Internet through the proxy server. The problem is that there's no
interface on pe1 on which to apply filter-based forwarding for the traffic
that comes in from a remote PE and is destined for the Internet. The return
traffic from the Internet to ce-a2, however, does pass through the proxy
server as desired.
FYI, I used the following match conditions in my filter-based forwarding
firewall filter:
from {
address {
172.16.255.1/32;
172.16.255.2/32;
}
}
This allowed me to test with traceoute and sourcing the different traffic
from different IPs.
In your setup, you would probably want something like this instead:
from {
protocol tcp;
port [ http https];
}
I hope this helps. Let me know if you have any questions about my setup.
--Stacy
On Feb 13, 2012, at 1:25 PM, Ido Szargel wrote:
On Feb 9, 2012, at 12:07 AM, Ido Szargel wrote:
Hi Stacy,
Almost all the traffic must go through the servers, those are web
filtering proxies and the base requirement of our customer, as this is
the service they are selling.
I'm using FBF as I do not want to maintain static routes to determine
that IP x should go through the servers or not but I want this to be
dynamic and updated via BGP from VRF A (which is where the LNS routers
are) Once the traffic has entered into VRF B then I can use FBF to
throw all traffic to the servers , they will do their magic and return
it back to the MX which will forward it according to its routing table.
Traffic in both direction should pass through the servers.
Currently there is only one site, and only one VRF to catch but there
might be more VRFs soon.
Thanks,
Ido
-Original Message-
From: Stacy W. Smith [mailto:st...@acm.org]
Sent: Thursday, February 09, 2012 7:42 AM
To: Ido Szargel
Subject: Re: [j-nsp] next hop behavior within between VRFs
Even more questions...
Are their remote sites that are members of the same VPN as VRF A?
If so, is there a set of servers (VRF B) in each site, or a single hub
site?
If so, is there Internet access in each site, or a single hub site?
--Stacy
On Feb 8, 2012, at 7:16 PM, Stacy W. Smith wrote:
Ido,
Sorry for the delay in getting back to this.
I think I understand what you're trying to accomplish, but just a
couple more questions.
I'm assuming this traffic has a source IP in vrf A and a destination
IP in
inet.0, and that's why you're using FBF to detour the traffic through
the servers in vrf B. Is that correct?
Is there anything in vrf B besides the servers that need to catch
the
traffic?
Are the servers in vrf B being used to catch traffic for any other
vrfs,
or only vrf A?
Does traffic from inet.0 also need to pass through the servers in vrf
B on
it's way to vrf A or is it only the traffic in the other direction
vrfA-vrfB servers-inet.0 that passes through the servers?
[j-nsp] WAN-PHY support for EX-series 10g interfaces
Hi, Potentially odd question here but does anyone know, from 1st hand experience, whether WAN-PHY mode is supported on 10g interfaces in EX-series devices? Specifically EX4200 and/or EX4500? I ask because we have a new carrier circuit being delivered in the not-too-distant future and we need to plug something into it to test it. Eventually we'll jam a SRX5800 with a 4x10GE DPC onto the end of it but in the meantime it would be handy to terminate and test with something .. smaller. The existing interfaces we have (provisioned before my time) apparently needed to be configured with the framing wan-phy and optics-options wavelength 1550.12 configuration options. The framing command auto-completes on an EX-series box but the optics-options command is hidden. Couldn't find any definitive references in the product docs. cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] flexible ethernet services / pppoe
I'm trying to work with an interface that has mixed subinterfaces. some of
the subinterfaces are part of a bridge domain, some are family inet, and one
interface is PPPOE for subscriber termination.
unit 402 {
description Wireless_PPPOE;
encapsulation ppp-over-ether;
vlan-id 402;
pppoe-underlying-options {
duplicate-protection;
dynamic-profile PPPOE;
}
}
paul@dis1.beachburg1# commit check
[edit interfaces ge-1/2/8]
'unit 402'
Link encapsulation type is not valid for device type
error: configuration check-out failed
Try this:
[edit interfaces]
demux0 {
unit 402 {
proxy-arp;
vlan-id 402;
demux-options {
underlying-interface ge-1/2/8;
}
family pppoe {
duplicate-protection;
dynamic-profile PPPOE;
}
}
}
(and remove the other pppoe unit from the physical interface)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX960 Redundant RE problem
Hi everyone
We have an MX960 with two routing engines, Re0: Backup, Re1: Master
When we try to switchover to the backup RE we see the following message:
XXX# run request chassis routing-engine master switch
error: Standby Routing Engine is not ready for graceful switchover
(replication_err soft_mask_err)
Toggle mastership between routing engines ? [yes,no] (no)
Noting that we used to switchover between the two Res a day a before with no
issues
Also, when we login to the re0 (backup) and check the isis, rsvp, etc… we
see the following:
XXX request routing-engine login other-routing-engine
€
--- JUNOS 10.2R3.10 built 2010-10-16 19:24:06 UTC
{backup}
XXX show isis adjacency
{backup}
XXX show rsvp session
Ingress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0
Egress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0
{backup}
XXX
While we can see the bgp routes and L3VPN routes,,,
We have tried to replace the backup with another one, but with the same
results
Any ideas, this issue is really confusing us, and it is a very critical
router in our network.
Thank you in advance
Mohammad Salbad
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] define name servers on pppoe dynamic profile
Hi everyone
We have an mx router that will be acting as BRAS router, with the following
config.:
dynamic-profiles {
pppoe_profile {
routing-instances {
$junos-routing-instance {
interface $junos-interface-name;
}
}
interfaces {
pp0 {
unit $junos-interface-unit {
ppp-options {
chap;
pap;
}
pppoe-options {
underlying-interface $junos-underlying-interface;
server;
}
family inet {
address x.x.x.x/x;
}
}
}
}
}
}
system {
services {
dhcp-local-server {
dynamic-profile pppoe_profile;
}
static-subscribers {
authentication {
username-include {
domain-name ;
}
}
}
}
}
interfaces {
ge-x/x/x{
unit 0 {
encapsulation ppp-over-ether;
proxy-arp;
pppoe-underlying-options {
dynamic-profile pppoe_profile;
}
}
}
ms-1/0/0 {
unit 0 {
family inet;
}
}
lo0 {
unit 0 {
family inet {
address x.x.x.x/x;
}
}
}
}
access {
group-profile pppoe_group {
ppp {
primary-dns x.x.x.x;
secondary-dns x.x.x.x;
}
}
profile aaa_profile {
authentication-order radius;
radius {
authentication-server x.x.x.x;
accounting-server x.x.x.x;
}
radius-server {
x.x.x.x {
port 1812;
secret #
}
}
accounting {
order radius;
accounting-stop-on-failure;
accounting-stop-on-access-deny;
immediate-update;
update-interval 10;
statistics time;
}
}
profile freeradius {
authentication-order radius;
radius {
authentication-server x.x.x.x;
accounting-server x.x.x.x;
}
}
radius-server {
x.x.x.x {
port 1812;
secret #
}
}
accounting {
order radius;
accounting-stop-on-failure;
accounting-stop-on-access-deny;
immediate-update;
update-interval 10;
statistics time;
}
}
address-assignment {
pool pppoe_pool {
family inet {
network x.x.x.x/x;
range pppoe_range {
low x.x.x.x;
high x.x.x.x;
}
dhcp-attributes {
name-server {
x.x.x.x;
}
}
}
}
}
address-protection;
}
access-profile freeradius;
when we try to define a destination profile in the dynamic profile it gives
a syntax error on the destination profile
set dynamic-profiles pppoe_profile interfaces pp0 unit $junos-interface-unit
family inet unnumbered-address lo0.0 destination-profile {group-profile}
any ideas ???
Thank you in advance
Mohammad Salbad
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX960 Redundant RE problem
Correct me if I'm wrong, but backup routing engines never have adjacencies
or peering relationships etc because they are not active, correct? When
they become master they have to reestablish those sessions. Thats how it
seems to be for our SRX routing engines, at least, but routes are shared
between the two so that during the time it takes for those things to
reestablish, the routes are still moving traffic.
I might be wrong, but that was my impression.
Morgan
2012/2/14 Mohammad masal...@gmail.com
Hi everyone
We have an MX960 with two routing engines, Re0: Backup, Re1: Master
When we try to switchover to the backup RE we see the following message:
XXX# run request chassis routing-engine master switch
error: Standby Routing Engine is not ready for graceful switchover
(replication_err soft_mask_err)
Toggle mastership between routing engines ? [yes,no] (no)
Noting that we used to switchover between the two Res a day a before with
no
issues
Also, when we login to the re0 (backup) and check the isis, rsvp, etc… we
see the following:
XXX request routing-engine login other-routing-engine
€
--- JUNOS 10.2R3.10 built 2010-10-16 19:24:06 UTC
{backup}
XXX show isis adjacency
{backup}
XXX show rsvp session
Ingress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0
Egress RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0
Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0
{backup}
XXX
While we can see the bgp routes and L3VPN routes,,,
We have tried to replace the backup with another one, but with the same
results
Any ideas, this issue is really confusing us, and it is a very critical
router in our network.
Thank you in advance
Mohammad Salbad
___
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
