[j-nsp] 6pe traceroute on qfx10k
Hello,
So using QFX10K as P core, it seems 6PE traceroute handling is broken
(15.1X63-D65).
QFX10K configured typically as a Juniper P box, and to get it to respond to
traceroute in 6PE environment, I have the following config below (pasted below).
Basically, you configure family inet6 on core/PE facing interfaces so LSR can
source
icmp using the core-facing interface's v6 address in a 6PE setup. This works
fine on MX.
It appears that on QFX10K, the box is attempting to pop labels and use inet6.0
unicast
routing table to send ttl-expired? Seems like icmp-tunneling is broken for
v6..? o_O
Anyone else seeing similar issues? Nothing surrounding icmp or 6pe issues when
doing
quick PR searches for 15.1X.
James
---
protocols {
mpls {
ipv6-tunneling;
icmp-tunneling;
}
}
interfaces {
et-0/0/1 {
description "facing another P router";
mtu 9216;
unit 0 {
family inet {
address 192.168.1.1/31;
}
family inet6 {
address 2001:db8::192.168.1.1/127;
}
}
}
}
---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Service Provider Shaping vs Policing
On Wed, Apr 19, 2017 at 01:44:19PM -0400, Skyler Blumer wrote: > Is this a single point of failure? For example if one 10GE NNI goes > down, are customer's backauled to this NNI down until they can be > manually moved over? It is and it isn't, depends on how you evaluate the risks. In our case, both IP POP and transport network meet in the same suite at the colo, typically in their same cage or private room, so there is no third party access or outside plant fiber involved on these interconnects. As for optics failing or line card dying causing the NNI to go down -- same situation can be said of any interface. By that statue, every customer port connecting into our network would be single point of failure, unless the customer opts for redundant ports. For customers paying redundant ports, we haul them to two physically separate IP POPs and would run BGP across both circuits. So if NNI dies or the whole POP dies, other side stays up. For NNI's terminating to the same equipment, I don't see how LAG adds much practical redundancy other than eery corner cases (like SFP dying bringing down a link member). If anything, using LAG to aggregate subrate circuits IMO just increases complexity on queueing and policing operations. We use LAG when we need to increase aggregate capacity available to a link path, but not for reasons of redundancy. If I need redundancy, we build diverse. James ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Service Provider Shaping vs Policing
On Wed, Apr 19, 2017 at 11:55:37AM -0400, Shamen Snyder wrote: > I'm curious as to what other Juniper service providers are doing for > their internet customers. I assume most probably shape or police at the > customer CPE or as close as they can to it. > > We are currently in a position where we terminate internet customers in > the POP that we purchase bulk transit in several collocations around the > United States. Then carry customer internet traffic back to the IP > termination via our MPLS network. We have similar setup, we backhaul customers to IP POP via our MPLS transport network in the metro. We setup 10GE NNI interfaces between IP and transport network and configure shaping on the NNI to subscriber line speed for that EVC. Likewise, for customer's upload direction, shaping is performed in opposite direction. On the customer facing PE, we police the ingress on customer port (so that will be customer's upload bandwidth) to prevent admitting too much traffic than what the shaper would eventually allow at the point of NNI interconnection. Since their upload bandwidth is shaped at the interconnect site, the ingress policer at the customer facing PE does not get violated in normal cases, unless customer has a compromised host sending large burst of uncontrolled fire-and-forget traffic (e.g. DoS). > > Shaping is broken when configured on a LAG (see KB22921). Which > depending on how many interfaces you have in a LAG a customer would need > that many flows to see all of their bandwidth. So I assume most > providers are using policing instead. We never use LAG for NNI interfaces, precisely because queueing and policing get complicated. Each NNI is independent 10GE interfaces as we hand-off from IP to transport network, and each EVC backhauling a customer never exceeds 3 Gbps subscriber speed. If the customer needs to be a 10G port to IP network (regardless of whether burstable or full-rate 10G), we put them on optical transport and deliver the service via unprotected 10G wave. This will change ofcourse with the ongoing deployment of 100G interfaces. We don't do any complex QoS or classifications for internet traffic uses -- after all, if we had a choice, we would rather put layer-3 routers at every customer facing site, but alas that is not very cost effective right now. We just police & queue (no classification) to enforce traffic contract and prevent over-admittance of traffic onto the metro transport network. HTH, James ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IPv6 traceroute over 6PE
On Wed, Aug 31, 2016 at 03:50:26PM -0500, kwor...@gmail.com wrote: > I have a simple lab setup using logical systems on an MX80 and I???m trying > to get trace route to work from CE1 <-> PE1 <-> P1 <-> PE2 <-> CE2 using ipv6 > and I always get loss on the 2nd hop although it completes after the > timeouts. Any clues would be appreciated. Have you tried enabling icmp-tunneling under [protocols mpls] on hop 2? It seems like your P router is popping label and trying to return using inet.0 James ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 6PE RR next-hop resolution best practices
Thanks Adam Ivan! I'll try this out shortly. Best, James On Mon, May 18, 2015 at 06:24:32AM +, Adam Vitkovsky wrote: To resolve the NHs you can do: set routing-options rib-groups 0-to-6 import-rib inet.0 set routing-options rib-groups 0-to-6 import-rib inet6.0 set routing-options rib-groups 0-to-6 import-policy loopbacks set protocols isis/ospf rib-group inet 0-to-6 This should create the ipv4-mapped-in-v6 (::ipv4) addresses in inet6 And then you tell BGP to resolve the NHs in inet.6: set routing-options resolution rib bgp.inet6.0 resolution-ribs inet6.0 adam ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 6PE RR next-hop resolution best practices
Hey Adam, Thanks for your reply. On Sat, May 16, 2015 at 06:45:45AM +, Adam Vitkovsky wrote: [ .. snip.. ] If you say that the RRs act as thru-traffic boxes for the transiting LSPs between PE's then they should just perform pure label switching and no IPv6 lookup. Are you sure your IPv6 traffic is labelled correctly indeed? Yes, traffic is labelled correctly, and P's are doing what they're supposed to. The problem however is that I'm using the P's also as route-reflectors for distributing BGP throughout the network. So, I need the RR's to make correct BGP best-path decisions, but they can't do that on 6PE routes without having inet6.3 table to reference the ipv4-mapped-in-v6 next-hops against. I've tried importing the PE loopbacks (which are my 6PE next-hops) from inet.0 into inet.3 using rib-groups, but that doesn't create the ipv4-mapped-in-v6 (::ipv4) conversions into inet6.3 table (yes, ipv6-tunneling under [ protocols mpls ] is enabled on the RR/P's). And are you sure the RRs are enabled for MPLS forwarding i.e. the label switched path between PEs crossing RRs is operational? I mean this could have gone unnoticed for IPv4 as the RRs happened to have all the routing information necessary for the IPv4 traffic to be forward traffic across. Yup absolutely, mpls forwarding is working correctly on the P's. The issue I'm having is route-reflectors running on the same P boxes being unable to make best-path decisions on 6PE routes having quad-F's/ipv4-mapped-inv6 next-hops-- they don't exist in inet6.3 unless RR's themselves have LSPs heading out to PE's.. I suppose other people doing 6PE with 'bgp-free core' or topologies of similar import (i.e. oob route-reflectors) probably have dealt with similar situations, when it comes to RR's having to make best-path decision on 6PE prefixes having v4-mapped-in-v6 next-hops. James ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] 6PE RR next-hop resolution best practices
Hello, Consider the following scenario, typical MPLS setup: PE -- P -- P -- PE. The P core routers are serving as route-reflectors for PE's. The topology is a RSVP full mesh between PE's only -- the P routers do not have LSPs to anybody, they're simply acting as pure signaling thru-traffic boxes for the transiting LSPs between PE's. Now, because the P core routers don't have LSPs themselves heading to edges, there is no 'inet.3' table to fill; thus 'ipv6-tunneling' has nothing to copy into inet6.3. With P routers are acting as RRs for 6PE, you can see the obvious problem: they can't resolve ipv4-mapped-ipv6 next-hops in 6PE, therefore closest-exit routing breaks for route-reflector clients (i.e. IPv6 traffic to a peer in same city exits out via other coast as there is no IGP distance to reference). Now, short of spamming LDP or going LSP-explosion-mode on every RRs, are there any recommendations for best practices to cleanly feed resolution reference for 6PE routes to RR's? Thank you in advance! James ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX3300/EX4300 Licensing
Yup, I hear ya, so does lot of other people. Juniper nickel diming with this licensing BS on second generation EX series is already making a battered platform full of software bugs and hardware limitations come out even worse. Arista seems to be looking better nowadays ;) You know, second tier ISPs and hosting shops are hard-pressed to implement BCP38 at customer ports as best practice. Requiring a paid license to enable sommething as simple as uRPF is Juniper's contribution to further help discourage BCP38 implementation, imo. Probably the most funny insult to injury that Juniper adds with this licensing crap is that on platforms like EX3300 and 4300, the software is so unstable, that you'd have to be stupid to be paying more for it. In some cases you could barely even download new image to upgrade the switch fresh out of the box before it crashes. Then when you do get it stable, turning on simple features like VRRP, uRPF, etc requires you to pay to play. Oh and don't even think about trying IPv6 OSPF on EX3300, it instantly kernel panics :P (verified all recent JUNOS releases supporting IPv6 available for that platform). james -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Skeeve Stevens Sent: Monday, November 18, 2013 12:00 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] EX3300/EX4300 Licensing All, I am a little confused. The EX3300/EX4300 has EFL and AFL licenses. But to get the AFL, you need to buy the EFL as well. Personally, I think this sucks... those features aren't worth that much extra. If you were buying per feature range and they were the same price, fair enough - but to be double the price for those few extra features... But, is this the same for the EX3200 and EX4200? Do I need to buy the EFL *and* AFL to get BGP? ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud ___ 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] Vlan question MX
VLANs used in this fashion are the new forms of 'DLCI' / VC you're used to from frame-relay/ATM days. It is common for a service provider to deliver multi-VLAN'd NNI host interface with vlans broken out to several types of services, such as: VLAN #A: ip transit/internet bandwidth VLAN #B: mpls layer-2 transport to another site VLAN #C: evpl circuit to another party VLAN #D: remote peering/vpls instance to an internet exchange point Etc etc james -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Tom Storey Sent: Monday, July 08, 2013 6:00 PM To: Michael Loftis Cc: juniper-nsp Subject: Re: [j-nsp] Vlan question MX The thing thats confusing me is, who on earth presents a service to a customer as a tagged service? Ive never come across such a thing. If you're plugged in to a router interface on the providers side, why is there a need to add VLAN tagging on top? Similarly, if you're plugged in to a switch, normally the switch port is just an access port, not a trunk. Someone help me out here... :-) On 8 July 2013 22:47, Michael Loftis mlof...@wgops.com wrote: vlan-tagging tells JunOS to treat the interface as multiple separate L3 interfaces, identified by VLAN ID. Their end is almost certainly similarly configured (maybe as a MPLS PE) On Mon, Jul 8, 2013 at 10:26 AM, Keith kwo...@citywest.ca wrote: Have this setup in the lab on some srx's but want to get some info on this. We have an upstream provider that we use a config: set interfaces ge-0/1/0 vlan-tagging set interfaces ge-0/1/0 encapsulation flexible-ethernet-services set interfaces ge-0/1/0 unit 1500 vlan-id 1500 set interfaces ge-0/1/0 unit 1500 family inet address x.x.x.x/30 We are turning up a second connection to them that will be terminated on a 10G link and want us to use the same thing, vlan 1500, just a different IP address. Will this cause a problem by having the same vlan id on both links to the same provider? (I am guessing we are being terminated on different routers on their side). My lab router didn't complain so I'm guessing its probably ok. Thanks, Keith ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds. -- Samuel Butler ___ 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] VPLS route reflection
Thanks for your response.
Yea, LDP and MPLS are running and reachable (there are test l2circuits
between lab edge routers). I noticed that on your BGP session, you're only
carrying l2vpn family - does it still work if you also carry inet.0 + inet.6
on same the same session?
james
From: Mihai Gabriel [mailto:mihaigabr...@gmail.com]
Sent: Tuesday, July 02, 2013 3:07 AM
To: James Jun
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] VPLS route reflection
VPLS with RR works very well for me in a small lab (see the example below).
Make sure that your loopbacks are reachable through ldp and mpls is enabled
on the interfaces.
mx5t# top show logical-systems r1 protocols bgp
group rr-client {
type internal;
local-address 172.27.255.1;
family l2vpn {
signaling;
}
neighbor 172.27.255.5;
}
mx5t# top show logical-systems r2 protocols bgp
group rr-client {
type internal;
local-address 172.27.255.2;
family l2vpn {
signaling;
}
neighbor 172.27.255.5;
}
mx5t# top show logical-systems r5 protocols bgp
group rr {
type internal;
local-address 172.27.255.5;
family l2vpn {
signaling;
}
cluster 0.0.0.1;
neighbor 172.27.255.1;
neighbor 172.27.255.2;
}
mx5t# run show route protocol bgp logical-system r5 table bgp.l2vpn.0
bgp.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
6L:1:1:1/96
*[BGP/170] 00:09:14, localpref 100, from 172.27.255.1
AS path: I, validation-state: unverified
to 172.27.0.26 via ge-1/1/6.53, Push 299808
6L:1:2:1/96
*[BGP/170] 00:09:14, localpref 100, from 172.27.255.2
AS path: I, validation-state: unverified
to 172.27.0.21 via ge-1/1/6.54, Push 299888
mx5t# run show route protocol bgp logical-system r1 table bgp.l2vpn.0
bgp.l2vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
6L:1:2:1/96
*[BGP/170] 00:02:49, localpref 100, from 172.27.255.5
AS path: I, validation-state: unverified
to 172.27.0.2 via ge-1/1/7.12
mx5t# run show route protocol bgp logical-system r2 table bgp.l2vpn.0
bgp.l2vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
6L:1:1:1/96
*[BGP/170] 00:03:00, localpref 100, from 172.27.255.5
AS path: I, validation-state: unverified
to 172.27.0.1 via ge-1/1/6.21
mx5t# run show vpls mac-table logical-system r1 | find Bridging
Bridging domain : __vpls-test__, VLAN : NA
MAC MAC Logical NH RTR
address flagsinterfaceIndex ID
64:87:88:5e:a5:1c Dvt-1/0/10.84934912
64:87:88:5e:a5:1d Dge-1/1/5.555
On Tue, Jul 2, 2013 at 7:07 AM, James Jun ja...@towardex.com wrote:
Hey all,
So, I've been trying to google for some sample configuration of
BGP-signalled VPLS setup using route-reflectors, and having some trouble
finding one. All of the sample BGP-signaled examples on Juniper site are
using full-mesh iBGP between PE's with no RR's in the middle.
A pretty simple and straight-forward iBGP topology like this, that we're all
used to in a typical SP network:
CE -- PE (rr client) - P (route-reflector) -- P (route-reflector )
- PE (rr client) -- CE
So, lacking any config examples, I've just enabled 'family l2vpn signaling;'
on existing iBGP sessions that are using the above topology.
Unfortunately, the route-reflector / P-router does not reflect the route
received from PE and vice versa -- it is behaving like non-RR client peer
that wants full mesh.
When viewing bgp.l2vpn.0 RIB, routers can only see l2vpn NLRI's received
from directly configured / meshed peer, but cannot see thru a
route-reflector (i.e. P router cannot see NLRIs from a PE that's attached
thru another P serving as route-reflector). Please note that unicast inet.0
and inet6.0 RIBs are also carried by same iBGP session transports across the
topology -- and those routes obviously work flawlessly using
route-reflectors.
Setup looks like this on a P router:
bgp {
group teh-core {
type internal;
family inet {
unicast;
}
family inet6 {
unicast;
}
family l2vpn {
signaling;
}
export mp64-ibgp-export-policy;
peer-as 64552;
neighbor 10.0.0.2 {
description core1.lab2;
}
neighbor 10.0.0.3 {
description core1.lab3;
}
}
group PE-edge-routers__RR-clients {
type internal;
family inet {
unicast;
}
family inet6
Re: [j-nsp] VPLS route reflection
Yup, you're right, there's nothing wrong with the RR behavior.
I found the problem -- it appears that the standard policy-statements I use
to control inet.0 + inet6.0 tables is filtering out L2VPN routes as they are
not tagged with the internal/standard AS communities. I've set those on
vrf-export policy for VPLS instance and it's working great now.
Thanks for your help! ;-)
james
-Original Message-
From: Mihai [mailto:mihaigabr...@gmail.com]
Sent: Tuesday, July 02, 2013 1:20 PM
To: James Jun
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] VPLS route reflection
yes, no problem after I activate inet unicast and inet6 unicast:
mx5t# run show bgp summary logical-system r2
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths SuppressedHistory Damp State
Pending
bgp.l2vpn.0
1 1 0 0 0
0
inet.0
1 1 0 0 0
0
inet6.0
0 0 0 0 0
0
Peer AS InPkt OutPktOutQ Flaps Last
Up/Dwn State|#Active/Received/Accepted/Damped...
172.27.255.5 6 12 11 0 0
3:41 Establ
bgp.l2vpn.0: 1/1/1/0
vpls-test.l2vpn.0: 1/1/1/0
inet.0: 1/1/1/0
inet6.0: 0/0/0/0
On 07/02/2013 06:54 PM, James Jun wrote:
Thanks for your response.
Yea, LDP and MPLS are running and reachable (there are test l2circuits
between lab edge routers). I noticed that on your BGP session, you're
only carrying l2vpn family - does it still work if you also carry
inet.0
+ inet.6 on same the same session?
james
*From:*Mihai Gabriel [mailto:mihaigabr...@gmail.com]
*Sent:* Tuesday, July 02, 2013 3:07 AM
*To:* James Jun
*Cc:* juniper-nsp@puck.nether.net
*Subject:* Re: [j-nsp] VPLS route reflection
VPLS with RR works very well for me in a small lab (see the example
below).
Make sure that your loopbacks are reachable through ldp and mpls is
enabled on the interfaces.
mx5t# top show logical-systems r1 protocols bgp
group rr-client {
type internal;
local-address 172.27.255.1;
family l2vpn {
signaling;
}
neighbor 172.27.255.5;
}
mx5t# top show logical-systems r2 protocols bgp
group rr-client {
type internal;
local-address 172.27.255.2;
family l2vpn {
signaling;
}
neighbor 172.27.255.5;
}
mx5t# top show logical-systems r5 protocols bgp
group rr {
type internal;
local-address 172.27.255.5;
family l2vpn {
signaling;
}
cluster 0.0.0.1;
neighbor 172.27.255.1;
neighbor 172.27.255.2;
}
mx5t# run show route protocol bgp logical-system r5 table bgp.l2vpn.0
bgp.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
6L:1:1:1/96
*[BGP/170] 00:09:14, localpref 100, from 172.27.255.1
AS path: I, validation-state: unverified
to 172.27.0.26 via ge-1/1/6.53, Push 299808
6L:1:2:1/96
*[BGP/170] 00:09:14, localpref 100, from 172.27.255.2
AS path: I, validation-state: unverified
to 172.27.0.21 via ge-1/1/6.54, Push 299888
mx5t# run show route protocol bgp logical-system r1 table bgp.l2vpn.0
bgp.l2vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
6L:1:2:1/96
*[BGP/170] 00:02:49, localpref 100, from 172.27.255.5
AS path: I, validation-state: unverified
to 172.27.0.2 via ge-1/1/7.12
mx5t# run show route protocol bgp logical-system r2 table bgp.l2vpn.0
bgp.l2vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
6L:1:1:1/96
*[BGP/170] 00:03:00, localpref 100, from 172.27.255.5
AS path: I, validation-state: unverified
to 172.27.0.1 via ge-1/1/6.21
mx5t# run show vpls mac-table logical-system r1 | find Bridging
Bridging domain : __vpls-test__, VLAN : NA
MAC MAC Logical NH RTR
address flags interface Index ID
64:87:88:5e:a5:1c D vt-1/0/10.84934912
64:87:88:5e:a5:1d D ge-1/1/5.555
On Tue, Jul 2, 2013 at 7:07 AM, James Jun ja...@towardex.com
mailto:ja...@towardex.com wrote:
Hey all,
So, I've been trying to google for some sample configuration of
BGP-signalled VPLS setup using route-reflectors, and having some
trouble finding one. All of the sample BGP-signaled examples on
Juniper site are using full-mesh iBGP between PE's with no RR's in the
middle.
A pretty simple and straight-forward iBGP topology like this, that
we're all used to in a typical SP network:
CE -- PE (rr client) - P (route-reflector) -- P
(route-reflector
) - PE (rr client) -- CE
So, lacking any config examples, I've just enabled 'family l2vpn
signaling;' on existing iBGP sessions that are using the above topology.
Unfortunately, the route-reflector / P-router does not reflect the
route received from PE and vice versa -- it is behaving like
[j-nsp] VPLS route reflection
Hey all,
So, I've been trying to google for some sample configuration of BGP-signalled
VPLS setup using route-reflectors, and having some trouble finding one. All of
the sample BGP-signaled examples on Juniper site are using full-mesh iBGP
between PE's with no RR's in the middle.
A pretty simple and straight-forward iBGP topology like this, that we're all
used to in a typical SP network:
CE -- PE (rr client) - P (route-reflector) -- P (route-reflector )
- PE (rr client) -- CE
So, lacking any config examples, I've just enabled 'family l2vpn signaling;' on
existing iBGP sessions that are using the above topology.
Unfortunately, the route-reflector / P-router does not reflect the route
received from PE and vice versa -- it is behaving like non-RR client peer that
wants full mesh.
When viewing bgp.l2vpn.0 RIB, routers can only see l2vpn NLRI's received from
directly configured / meshed peer, but cannot see thru a route-reflector (i.e.
P router cannot see NLRIs from a PE that's attached thru another P serving as
route-reflector). Please note that unicast inet.0 and inet6.0 RIBs are also
carried by same iBGP session transports across the topology -- and those routes
obviously work flawlessly using route-reflectors.
Setup looks like this on a P router:
bgp {
group teh-core {
type internal;
family inet {
unicast;
}
family inet6 {
unicast;
}
family l2vpn {
signaling;
}
export mp64-ibgp-export-policy;
peer-as 64552;
neighbor 10.0.0.2 {
description core1.lab2;
}
neighbor 10.0.0.3 {
description core1.lab3;
}
}
group PE-edge-routers__RR-clients {
type internal;
family inet {
unicast;
}
family inet6 {
unicast;
}
family l2vpn {
signaling;
}
export mp64-ibgp-export-policy;
cluster 10.0.0.1;
peer-as 64552;
neighbor 10.0.1.1 {
description edge1.lab1;
}
neighbor 10.0.1.2 {
description edge2.lab1;
}
}
}
Thanks in advance!
james
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] overload bit for MPLS LSPs?
Hey folks, Is there a way to set overload bit on RSVP signaled LSPs? I've got OSPF-TE setup with overload timer set to 120 seconds. Obviously the problem here is that LSPs get established sooner than that with CSPF metrics getting set really high. I believe on IS-IS, LSPs get recomputed after overload times out, but it doesn't seem to be the case with OSPF. :S TIA, james ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 vs MX10 software testing
There is no hardware difference between MX80 and MX5-40, other than EEPROM coded interfaces for license enforcement. An MX5 can do everything MX80 can do, except you can only use the 20x GE MIC3D card. HTH, james -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Serge Vautour Sent: Friday, April 05, 2013 12:41 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] MX80 vs MX10 software testing Hello, Before we deploy a new Junos version to production we run it through a series of test cases to prove all the functionality we use. We will also re-test on each piece of hardware (ie MX80 vs MX960). Any comments on the Hardware differences between an MX80 and MX10? Juniper initial had MX80-10 which were the exact same Hardware as MX80. There was a gentleman's agreement license as to which ports you could use. Technically, the box was an MX80. Now Juniper has MX5, MX10 and MX40. These are slightly different than MX80 as they won't work before 11.x while MX80 started on 10.2 code. We're being told the difference is minor (new eprom chip and timing kit). We're struggling with the level of testing we should do between MX80 and MX10. Should we repeat all test cases on both? Some test cases? Which ones? Should we not bother at all (ie anything that works on MX10 will also work in MX80)? Juniper is tell us the differences are minor and we shouldn't have to repeat testing on both platforms. Comments? Thanks, Serge ___ 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] EX4550 experiences?
Does anyone have experiences / thoughts to share on EX4550 series? Thanks, james ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Peering with loopback
I'm running a mixed environment of Juniper and Cisco and have noticed some odd behavior with some of iBGP peers. It's my understanding that Junos has no equivalent to the Cisco 'update-source loobback0'. Try, local-address x.x.x.x under edit protocols bgp where x.x.x.x is your lo0 loopback IP. James ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Route Reflecting Next-Hop Self
Well, given the fact that BGP uses IGP information (metric) to make
best-path decision, you should include inter -AS xfernets in your IGP
if you want to do decent deterministic traffic engineering toward your
nexthops.
I think the whole notion of my IPs in IGP only is silly..
James
Sent from my iPhone
On Sep 9, 2008, at 4:01 PM, Dan Armstrong [EMAIL PROTECTED] wrote:
A hotly debated topic among BGP nerds I honestly don't know
how I feel about it either way.
Many people think that because the IPs that you often use between
yourself and a transit provider belong to your transit provider,
they have no business being in your IGP My IGP is for MY
address space.At the end of the day I don't think it really
matters, but you know how passionate some people can be.
Amos Rosenboim wrote:
Hello Dan,
You can also work around all of this by simply adding the inter-AS
prefix into your IGP by adding this interface as a passive
interface for the IGP.
This will eliminate the need for next hop self in the first place.
This seems simpler to me, am I missing any reason not to use this?
Regards
Amos Rosenboim
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
On Sep 6, 2008, at 12:46 AM, Dan Armstrong wrote:
EUREKA you're a genius!
Thanks... That works perfectly.
And thanks to all who replied!
Kevin Hodle wrote:
Hi Dan,
Instead of 'from external' you need 'from route-type external',
like so:
term external-nexthopself {
from {
protocol bgp;
route-type external;
}
then {
next-hop self;
accept;
}
}
HTH,
Kevin
On Fri, Sep 5, 2008 at 9:26 AM, Dan Armstrong [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote:
I was trying to make a generic policy statement that I could
deploy across all our boxes... this is not possible if we name
ebgp peers specifically, and if we change transit providers - we
have to keep track of changing policy statements as well... kind
of messy.
Chuck Anderson wrote:
On Thu, Sep 04, 2008 at 10:08:45PM -0400, Dan Armstrong wrote:
In IOS, if I set next-hop self in a neighbor relationship with
an RR-Client, it sets the next-hop to itself for routes
learned from local eBGP sessions, but leaves the next-hop
unchanged for routes that it's passing on from other fellow
route-reflectors...
The *problem* is that in JunOS, if I set next-hop self on a
neighbor relationship with an RR-Client, it sets the next-hop
to itself all the time, even on routes it's passing on from
other fellow route-reflectors, effectively sucking all
traffic into the route reflector and totally defeating the
purpose of route reflecting.
That's just the way it is in JunOS--not much policy-related
behavior is hard-coded into JunOS like it might be in other
vendors. This gives you the most flexibility in writing policy
to do exactly what you want.
Now, of course we can policy-statement our way out of this -
with big messy kludgey stuff, but it seems to me that there
has to be a fairly simple and elegant way to do this, since
it's pretty common, no?
(My current kludge is to set an import policy on my eBGP
sessions that tag each route with a community called HERE,
have an export policy towards all my iBGP neighbors to set
next-hop self if the route is tagged with the community
HERE, then strip it off - so that the community HERE
never leaves any box.)
That is one recommended method. The other is to match the eBGP
neighbor and only apply next-hop self to routes from your eBGP
peers.
e.g. in your IBGP export policy (from the JNCIP study guide):
term 3 {
from {
protocol bgp;
neighbor [ 172.16.0.14 172.16.0.18 ];
}
then {
next-hop self;
}
}
where 172.16.0.14 and 17.16.0.18 are eBGP peer addresses.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net mailto:juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net mailto:juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net mailto: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] ttl-security
http://www.juniper.net/techpubs/software/junos/junos92/swconfig- routing/multihop.html#id-13320727 Yes you can specify a maximum TTL value. This match is performed on RE, not on the PFE as opposed to a firewall match. That's not filtering on TTL. It just specifies what TTL to use to send bgp traffic over to your peer. James ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] cogent bgp example?
Hi, I'm a small site and I'm just getting ready to go live with a
cogent connection. But, I'm finding myself a bit confused by their
Peer A / Peer B description. I can find some examples of multihop
things, but none seem very clear.
Can someone send a basic cogent bgp setup?
[edit protocols bgp]
group cogent-in {
type external;
peer-as 174;
local-address $peer-b-local;
neighbor $peer-b {
description Cogent Transit [CE-PE] [EMAIL PROTECTED];
multihop ttl 5;
}
import gen_transit_in;
}
group cogent-out {
type external;
peer-as 174;
neighbor $peer-a {
description Cogent Transit [CE-PE] [EMAIL PROTECTED];
}
export transit_cogent_out;
import no;
}
[edit routing-options]
static {
$peer-b/32 next-hop $peer-a;
}
For Cisco:
neighbor $peer-a remote-as 174
neighbor $peer-a description Cogent Transit [CE-PE] [EMAIL PROTECTED]
neighbor $peer-b remote-as 174
neighbor $peer-b description Cogent Transit [CE-PE] [EMAIL PROTECTED]
neighbor $peer-b ebgp-multihop 5
! set interface loopback1 with $peer-b-local address
neighbor $peer-b update-source loop1
!
address-family ipv4
neighbor $peer-a activate
neighbor $peer-a send-community both
neighbor $peer-a remove-private-as
neighbor $peer-a prefix-list To_Cogent out
neighbor $peer-a route-map no in
neighbor $peer-a route-map transit_export out
neighbor $peer-b activate
neighbor $peer-b prefix-list ISP-Ingress-Filter in
neighbor $peer-b route-map transit_import in
neighbor $peer-b route-map no out
neighbor $peer-b filter-list 500 in
!
ip route $peer-b 255.255.255.255 $peer-a
!
Replace peer-a, peer-b with appropriate peer IP's and replace all
import/export/route-maps/prefix-lists/etc accordingly to your organization
routing policy.
Replace peer-b-local with the /32 ip address Cogent assigns you for
Loopback1 interface.
Peer A is a directly connected neighbor where you announce/advertise your
network routes to them.
Peer B is a multi-hop peer where you advertise NO routes to them, but
receive full internet routing table from them.
And one other thing:
Cogent sends you IP address of peer B over the bgp session with peer A, so
that your router will be able to establish multi-hop session with peer B.
I don't like relying on an ebgp peer to receive session address for another
ebgp peer (takes longer for peer B to come up) so I generally prefer using
manual static-route for peer B, pointed to peer A's directly connected
address.
Hope this helps.
james
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
