Re: [j-nsp] Parallel BGP sessions for v6 prefixes over v4 and v6

[Alexandre Snarskii via juniper-nsp]

On Mon, Jul 08, 2024 at 11:33:48AM -0400, Andrey Kostin via juniper-nsp wrote:
[...]
> The problem here is that route-reflector selects a path with ipv4 mapped 
> nexthop and advertises it over ipv6 session. I'm wondering, is anybody 
> already encountered this problem and found a solution how to make a RR 
> to advertise paths with a correct nexthop?

Have you considered making your inet6 sessions not unicast but labeled-unicast 
explicit-null too ? I guess it may prevent bgp from losing label..

> I know that having two session for ipv6 adds complexity and one of them 
> can be removed, but interested to find out an elegant solution for this 
> issue.
> 
> Kind regards,
> Andrey
> ___
> 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] L3VPNs and on-prem DDoS scrubbing architecture

[Alexandre Snarskii via juniper-nsp]

On Thu, Apr 04, 2024 at 04:15:03PM +, Michael Hare wrote:
> Alexandre,
> 
> Thanks for your emails.  I finally got around to trying it myself; 
> it definitely works!  I first "broke" my A.B.C.D destination and =then= 
> added a static.  When I reproduced this, instead of putting the static 
> route into inet.0 I chose to install in my cleanVRF, which gets around 
> the admin distance issues.  Any reason you install the routes in global 
> instead of cleanVRF that I'm overlooking?

I guess you have not only static A.B.C.D/32 but also covering direct
A.B.C.0/24 in your cleanVRF ? Looks like I just overlooked that with
the help of imported direct route I'll be able to resolve /32 into mac
in VRF (not yet tested, but shall work).

> I'm curious to know how safe it is to rely on working in the future.  
> How long have you been using this trick?  

Trick with self-pointing routes is from the times when there were
no 'vrf-table-label' option in routing instances (there were no other
option to provide VRF access without CE-router). Trick with redistributing
them into cleanVRF is used since 2018 or something like.

> I'll probably follow up with our Juniper support channels, as Saku 
> suggests, maybe something even better can come out of this.
> 
> Thanks again,
> -Michael
> 
> =/
> 
> @# run show route A.B.C.D 
> 
> inet.0: 933009 destinations, 2744517 routes (932998 active, 0 holddown, 360 
> hidden)
> + = Active Route, - = Last Active, * = Both
> 
> A.B.C.D/32   *[BGP/170] 00:24:03, localpref 100, from 2.3.4.5
>   AS path: I, validation-state: unverified
> >  to 5.6.7.8 via et-0/1/10.3099
> 
> cleanVRF.inet.0: 319 destinations, 1179 routes (318 active, 0 holddown, 1 
> hidden)
> Limit/Threshold: 5000/4000 destinations
> + = Active Route, - = Last Active, * = Both   
>   
> 
> 
> A.B.C.D/32   *[Static/5] 00:07:36
> >  to A.B.C.D via ae17.3347
> 
> @# run show route forwarding-table destination A.B.C.D 
> Routing table: default.inet
> Internet:
> DestinationType RtRef Next hop   Type IndexNhRef Netif
> A.B.C.D/32   user 0indr  1048588 3
>   5.6.7.8  ucst  981 5 et-0/1/10.3099
> A.B.C.D/32   dest 0 0:50:56:b3:4f:fe   ucst 1420 3 ae17.3347
> 
> Routing table: cleanVRF.inet  
>   
>   
> Internet:
> DestinationType RtRef Next hop   Type IndexNhRef Netif
> A.B.C.D/32   user 0 0:50:56:b3:4f:fe   ucst 1420 3 ae17.3347
> 
> > -Original Message-
> > From: Alexandre Snarskii 
> > Sent: Tuesday, April 2, 2024 12:20 PM
> > To: Michael Hare 
> > Cc: juniper-nsp@puck.nether.net
> > Subject: Re: [j-nsp] L3VPNs and on-prem DDoS scrubbing architecture
> > 
> > On Tue, Apr 02, 2024 at 07:43:01PM +0300, Alexandre Snarskii via juniper-
> > nsp wrote:
> > > On Tue, Apr 02, 2024 at 03:25:21PM +, Michael Hare via juniper-nsp
> > wrote:
> > >
> > > Hi!
> > >
> > > Workaround that we're using (not elegant, but working): setup a
> > > "self-pointing" routes to directly connected destinations:
> > >
> > > set routing-options static route A.B.C.D/32 next-hop A.B.C.D
> > 
> > Forgot to note one thing: these self-pointing routes shall have
> > preference of 200 (or anytning more than BGP's 170):
> > 
> > set routing-options static route A.B.C.D/32 next-hop A.B.C.D
> > set routing-options static route A.B.C.D/32 preference 200
> > 
> > so, in case when traffic shall be diverted to scrubbing, bgp route
> > will be active in inet.0 and static route will be active in cleanL3VPN:
> > 
> > s...@rt1.ov.spb> show route A.B.C.D/32
> > inet.0: ...
> > + = Active Route, - = Last Active, * = Both
> > 
> > A.B.C.D/32 *[BGP/170] 00:06:33, localpref 100
> >   AS path: 65532 I, validation-state: unverified
> > >  to Scrubbing via ae3.232
> > [Static/200] 00:02:22
> > >  to A.B.C.D via ae3.200
> > 
> > cleanL3VPN.inet.0: 
> > + = Active Route, - = Last Active, * = Both
> > 
> > A.B.C.D/32 *[Static/200] 00:02:22
> > >  to A.B.C.D via 

Re: [j-nsp] L3VPNs and on-prem DDoS scrubbing architecture

[Alexandre Snarskii via juniper-nsp]

On Tue, Apr 02, 2024 at 07:43:01PM +0300, Alexandre Snarskii via juniper-nsp 
wrote:
> On Tue, Apr 02, 2024 at 03:25:21PM +, Michael Hare via juniper-nsp wrote:
> 
> Hi!
> 
> Workaround that we're using (not elegant, but working): setup a 
> "self-pointing" routes to directly connected destinations:
> 
> set routing-options static route A.B.C.D/32 next-hop A.B.C.D

Forgot to note one thing: these self-pointing routes shall have 
preference of 200 (or anytning more than BGP's 170):

set routing-options static route A.B.C.D/32 next-hop A.B.C.D
set routing-options static route A.B.C.D/32 preference 200

so, in case when traffic shall be diverted to scrubbing, bgp route
will be active in inet.0 and static route will be active in cleanL3VPN:

s...@rt1.ov.spb> show route A.B.C.D/32
inet.0: ...
+ = Active Route, - = Last Active, * = Both

A.B.C.D/32 *[BGP/170] 00:06:33, localpref 100
  AS path: 65532 I, validation-state: unverified
>  to Scrubbing via ae3.232
[Static/200] 00:02:22
>  to A.B.C.D via ae3.200

cleanL3VPN.inet.0: 
+ = Active Route, - = Last Active, * = Both

A.B.C.D/32 *[Static/200] 00:02:22
>  to A.B.C.D via ae3.200


and the corresponding forwarding entry:

Routing table: default.inet [Index 0] 
Internet:

Destination:  A.B.C.D/32
  Route type: user  
  Route reference: 0   Route interface-index: 0   
  Multicast RPF nh index: 0 
  P2mpidx: 0  
  Flags: sent to PFE, rt nh decoupled  
  Nexthop: Scrubbing
  Next-hop type: unicast   Index: 2971 Reference: 6
  Next-hop interface: ae3.232  
  RPF interface: ae3.200
  RPF interface: ae3.232

Destination:  A.B.C.D/32
  Route type: destination   
  Route reference: 0   Route interface-index: 431 
  Multicast RPF nh index: 0 
  P2mpidx: 0  
  Flags: none 
  Nexthop: 0:15:17:b0:e6:f8
  Next-hop type: unicast   Index: 2930 Reference: 3
  Next-hop interface: ae3.200   
  RPF interface: ae3.200

[...]
Routing table: cleanL3VPN.inet [Index 6] 
Internet:   

Destination:  A.B.C.D/32
  Route type: user  
  Route reference: 0   Route interface-index: 0   
  Multicast RPF nh index: 0 
  P2mpidx: 0
  Flags: sent to PFE, rt nh decoupled   
  Nexthop: 0:15:17:b0:e6:f8 
  Next-hop type: unicast   Index: 2930 Reference: 3
  Next-hop interface: ae3.200   


> 
> and export these to cleanL3VPN. Resulting forwarding-table:
> 
> Routing table: default.inet [Index 0]
> Internet:
> 
> Destination:  A.B.C.D/32
>   Route type: user
>   Route reference: 0   Route interface-index: 0
>   Multicast RPF nh index: 0
>   P2mpidx: 0
>   Flags: sent to PFE, rt nh decoupled
>   Nexthop: 0:15:17:b0:e6:f8
>   Next-hop type: unicast   Index: 2930 Reference: 4
>   Next-hop interface: ae3.200
>   RPF interface: ae3.200
> 
> [...]
> 
> Routing table: cleanL3VPN.inet [Index 6]
> Internet:
> 
> Destination:  A.B.C.D/32
>   Route type: user
>   Route reference: 0   Route interface-index: 0
>   Multicast RPF nh index: 0
>   P2mpidx: 0
>   Flags: sent to PFE, rt nh decoupled
>   Nexthop: 0:15:17:b0:e6:f8
>   Next-hop type: unicast   Index: 2930 Reference: 4
>   Next-hop interface: ae3.200
> 
> Unfortunately, we found no way to provision such routes via BGP,
> so you have to have all those in configuration :(
> 
> If there is a better workaround, I'd like to know it too :)
> 
> 
> > Hi there,
> > 
> > We're a US research and education ISP and we've been tasked for coming up 
> > with an architecture to allow on premise DDoS scrubbing with an appliance.  
> >  As a first pass I've created an cleanL3VPN routing-instance to function as 
> > a clean VRF that uses rib-groups to mirror the relevant parts of inet.0.   
> > It is in production and is working great for customer learned BGP routes.  
> > It falls apart when I try to protect a directly attached destination that 
> > has a mac address in inet.0.  I think I understand why and the purpose of 
> > this message is to see if anyone has been in a similar situation and has 
> > thoughts/advice/warnings about alternative designs.
> > 
> > To explain what I see, I noticed that mac address based nexthops don't seem 
> > to be copied from inet.0 into cleanL3VPN.inet.0.  I assume this means that 
> > mac-address based forwarding must be referencing inet.0 [se

Re: [j-nsp] L3VPNs and on-prem DDoS scrubbing architecture

[Alexandre Snarskii via juniper-nsp]

On Tue, Apr 02, 2024 at 03:25:21PM +, Michael Hare via juniper-nsp wrote:

Hi!

Workaround that we're using (not elegant, but working): setup a 
"self-pointing" routes to directly connected destinations:

set routing-options static route A.B.C.D/32 next-hop A.B.C.D

and export these to cleanL3VPN. Resulting forwarding-table:

Routing table: default.inet [Index 0]
Internet:

Destination:  A.B.C.D/32
  Route type: user
  Route reference: 0   Route interface-index: 0
  Multicast RPF nh index: 0
  P2mpidx: 0
  Flags: sent to PFE, rt nh decoupled
  Nexthop: 0:15:17:b0:e6:f8
  Next-hop type: unicast   Index: 2930 Reference: 4
  Next-hop interface: ae3.200
  RPF interface: ae3.200

[...]

Routing table: cleanL3VPN.inet [Index 6]
Internet:

Destination:  87.245.206.15/32
  Route type: user
  Route reference: 0   Route interface-index: 0
  Multicast RPF nh index: 0
  P2mpidx: 0
  Flags: sent to PFE, rt nh decoupled
  Nexthop: 0:15:17:b0:e6:f8
  Next-hop type: unicast   Index: 2930 Reference: 4
  Next-hop interface: ae3.200

Unfortunately, we found no way to provision such routes via BGP,
so you have to have all those in configuration :(

If there is a better workaround, I'd like to know it too :)


> Hi there,
> 
> We're a US research and education ISP and we've been tasked for coming up 
> with an architecture to allow on premise DDoS scrubbing with an appliance.   
> As a first pass I've created an cleanL3VPN routing-instance to function as a 
> clean VRF that uses rib-groups to mirror the relevant parts of inet.0.   It 
> is in production and is working great for customer learned BGP routes.  It 
> falls apart when I try to protect a directly attached destination that has a 
> mac address in inet.0.  I think I understand why and the purpose of this 
> message is to see if anyone has been in a similar situation and has 
> thoughts/advice/warnings about alternative designs.
> 
> To explain what I see, I noticed that mac address based nexthops don't seem 
> to be copied from inet.0 into cleanL3VPN.inet.0.  I assume this means that 
> mac-address based forwarding must be referencing inet.0 [see far below].   
> This obviously creates a loop once the best path in inet.0 becomes a BGP /32. 
>  For example when I'm announcing a /32 for 1.2.3.4 out of a locally attached 
> 1.2.3.0/26, traceroute implies the packet enters inet.0, is sent to 5.6.7.8 
> as the nexthop correctly, arrives in cleanL3VPN which decides to forward to 
> 5.6.7.8 in a loop, even though the BGP /32 isn't part of cleanL3VPN [see 
> below], cleanL3VPN Is dependent on inet.0 for resolution.  Even if I could 
> copy inet.0 mac addresses into cleanL3VPN, eventually the mac address would 
> age out of inet.0 because the /32 would no longer be directly connected.  If 
> I want to be able to protect locally attached destinations so I think my 
> design is unworkable, I think my solutions are 
> 
> = use flowspec redirection to dirty VRF, keep inet.0 as clean and use 
> flowspec interface filter-group appropriately on backbone interfaces 
> [routing-options flow interface-group exclude, which I already have deployed 
> correctly].  This seems easy but is less performant.
> = put my customers into a customerVRF and deal with route leaking between 
> global and customerVRF.  This is a well-known tactic but more complicated to 
> approach and disruptive to deploy as I have to airlift basically all the 
> customers to into a VRF to have full coverage.
> 
> For redirection, to date I've been looking at longest prefix match solutions 
> due to the presumed scalability vs using flowspec.  I have an unknown amount 
> of "always on" redirects I might be asked to entertain.  10?  100? 1000?  I'm 
> trying to come up with a solution that doesn't rely on touching the routers 
> themselves.  I did think about creating a normal [non flowspec] input 
> firewall term on untrusted interfaces that redirects to dirty VRF based in a 
> single destination prefix-list and just relying on flowspec for on demand 
> stuff with the assumption one firewall term with let's say 1000 prefixes is 
> more performant than 1000 standalone flowspec rules.   I think my solution is 
> fundamentally workable but I don't think the purchased turnkey ddos 
> orchestration is going to natively interact with our Junipers, so that is 
> looked down upon, since it would require " a router guy " or writing custom 
> automation when adding/removing always-on protection.  Seems technically very 
> viable to me, I j
 us
>  t bring up these details because I feel like without a ton of effort VRF 
> redirection can be made to be nearly as performant as longest prefix match.
> 
> While we run MPLS, currently all of our customers/transit are in the global 
> table.  I'm trying to avoid solutions for now that puts the 1M+ RIB DFZ zone 
> into an L3VPN; it's awfully big change I don't want to rush into especially 
> for this proof of concept 

Re: [j-nsp] Flowspec not filtering traffic.

[Alexandre Snarskii via juniper-nsp]

On Sat, Sep 17, 2022 at 11:41:58AM -0300, Gustavo Santos via juniper-nsp wrote:
> Hi Saku,
> 
> PS: Real ASN was changed to 65000 on the configuration snippet.
> 
> 
> 
> show route table inetflow.0 extensive
> 
> 1x8.2x8.84.34,*,proto=17,port=0/term:7 (1 entry, 1 announced)

port=0 seems to be poor choice when trying to shut down NTP reflection,
with this rule your router filters only small fraction of DDoS traffic..

Background:
- udp reflection attacks try go generate as much traffic as possible,
so, amplification attacks usually carry lots of fragmented traffic.
- when non-first fragment enters your router it does not contain
UDP header so it's reported by netflow as having source and destination
ports of zeros.
- your detection system generates and injects flowspec matching port=0,
- now when your router sees first fragment of amplified packet, it does
not matches this rule (source port is 123 and destination port is usually
non-zero too), so your router passes this packet.
- when your router sees non-first fragment of amplified packet,
it understand that it does not know neither source nor destination
ports, so it can't compare against this rule, so this packet is 
not matched and passed too.
- so, what is filtered is only these (rare) packets that are the
first fragments and have destination port of zero.

What you can try here: replace port matching with is-fragment matching.
In JunOS syntax it will be

set routing-options flow route NTP-AMP match destination 1x8.2x8.84.34/32 
set routing-options flow route NTP-AMP match protocol udp fragment is-fragment
set routing-options flow route NTP-AMP then discard

> TSI:
> KRT in dfwd;
> Action(s): discard,count
> Page 0 idx 0, (group KENTIK_FS type Internal) Type 1 val 0x63b7c098
> (adv_entry)
>Advertised metrics:
>  Flags: NoNexthop
>  Localpref: 100
>  AS path: [65000 I
>  Communities: traffic-rate:52873:0
> Advertise: 0001
> Path 1x8.2x8.84.34,*,proto=17,port=0
> Vector len 4.  Val: 0
> *Flow   Preference: 5
> Next hop type: Fictitious, Next hop index: 0
> Address: 0x5214bfc
> Next-hop reference count: 22
> Next hop:
> State: 
> Local AS: 52873
> Age: 8w0d 20:30:33
> Validation State: unverified
> Task: RT Flow
> Announcement bits (2): 0-Flow 1-BGP_RT_Background
> AS path: I
> Communities: traffic-rate:65000:0
> 
> show firewall
> 
> Filter: __flowspec_default_inet__
> Counters:
> NameBytes
>  Packets
> 1x8.2x8.84.34,*,proto=17,port=0   19897391083
>  510189535
> 
> 
> BGP Group
> 
> {master}[edit protocols bgp group KENTIK_FS]
> type internal;
> hold-time 720;
> mtu-discovery;
> family inet {
> unicast;
> flow {
> no-validate flowspec-import;
> }
> }
> }
> 
> 
> 
> Import policy
> {master}[edit]
> gustavo@MX10K3# edit policy-options policy-statement flowspec-import
> 
> {master}[edit policy-options policy-statement flowspec-import]
> gustavo@MX10K3# show
> term 1 {
> then accept;
> }
> 
> IP transit interface
> 
> {master}[edit interfaces ae0 unit 10]
> gustavo@MX10K3# show
> vlan-id 10;
> family inet {
> mtu 1500;
> filter {
> inactive: input ddos;
> }
> sampling {
> input;
> }
> address x.x.x.x.x/31;
> }
> 
> 
> Em sáb., 17 de set. de 2022 às 03:00, Saku Ytti  escreveu:
> 
> > Can you provide some output.
> >
> > Like 'show route table inetflow.0 extensive' and config.
> >
> > On Sat, 17 Sept 2022 at 05:05, Gustavo Santos via juniper-nsp
> >  wrote:
> > >
> > > Hi,
> > >
> > > We have noticed that flowspec is not working or filtering as expected.
> > > Trying a DDoS detection and rule generator tool, and we noticed that the
> > > flowspec rule is installed,
> > > the filter counter is increasing , but no filtering at all.
> > >
> > > For example DDoS traffic from source port UDP port 123 is coming from an
> > > Internet Transit
> > > facing interface AE0.
> > > The destination of this traffic is to a customer Interface ET-0/0/10.
> > >
> > > Even with all information and "show" commands confirming that the traffic
> > > has been filtered, customer and snmp and netflow from the customer facing
> > > interface is showing that the "filtered" traffic is hitting the
> > destination.
> > >
> > > Is there any caveat or limitation or anyone hit this issue? I tried this
> > > with two MX10003 routers one with 19.R3-xxx and the other one with 20.4R3
> > > junos branch.
> > >
> > > Regards.
> > > ___
> > > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> >
> >
> > --
> >   ++ytti
> >
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> 

Re: [j-nsp] UDP telemetry sensors

[Alexandre Snarskii via juniper-nsp]

On Thu, Jul 28, 2022 at 04:18:03PM -0400, Jared Mauch via juniper-nsp wrote:
> Most examples I've seen are GRPC dial in or out, but anyone using 
> the UDP based telemetry with success? What format are you using? 

Protobuf over UDP (mx-series), works just fine.

> Curious as I'm seeing what appears to be corrupted packets be it PFE 
> or RE sourced and want to check what others are seeing. 
> 
> - Jared 
> 
> Sent via RFC1925 compliant device
> ___
> 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] labeled-unicast to ldp redistribution ?

[Alexandre Snarskii via juniper-nsp]

On Mon, Dec 20, 2021 at 04:47:23PM -0500, Andrey Kostin wrote:
> Thanks for details, it looks a little illogical though.
> I mentioned that the best BGP route is received from the same OSPF/LDP 
> neighbor in the same island. 

Because it's oversimplified lab, just to demonstrate unexpected behaviour.
In real life, OSPF/LDP route shall come from inside the island and ibgp-lu
from the outside.

> And it looks like it's using P2P IPs for 
> BGP session. Is there some reason why it's not run between loopback IPs? 

Sure, there is: I planned to use ibgp-lu to announce loopbacks reachability
only, something like 'igp-on-steroids' scenario (not a real IGP, because 
with IGP you have no options for example, to filter some loopbacks over
some links).

>   Just shot in the dark, maybe with sessions between loopbacks BGP would 
> rely on OSPF for next-hop resolution and it can change the behavior?
> 
> Kind regards,
> Andrey Kostin
> 
> Alexandre Snarskii писал(а) 2021-12-20 12:31:
> > On Mon, Dec 20, 2021 at 09:08:40AM -0500, Andrey Kostin wrote:
> >> Hi Alexandre,
> >> 
> >> Not sure that I completely understood the issue. When connectivity
> >> between islands recovers, what is the primary route for regular BGP
> >> routes' protocol next-hop?
> > 
> > It's not the connectivity between islands, it's the connectivity
> > within IGP island that recovers. Assume the following simple
> > topology:
> > 
> >A == B
> >||
> >C == D
> > 
> > Routers A and B form one IGP island, C and D - other, and there are
> > two ibgp-lu links between islands with ldp->ibgp-lu->ldp 
> > redistribution.
> > 
> > In normal situation, route A to B goes via direct link (igp/ldp),
> > when link A-B breaks, A switches to ibgp-lu route from C.
> > When link A-B recovers, A does not switch back to direct link and
> > still uses A->C route (in best case it's just suboptimal, in worst
> > case it results in routing loops).
> > 
> >> Looks like it should be OSPF with route
> >> preference lower than BGP and in this case it should be labeled by LDP
> >> and propagated. Only if OSPF route for a protocol next-hop is not the
> >> best, the next-hop from BGP-LU will be used.
> > 
> > Unfortunately, it's expected behaviour, but not what I see in lab.
> > Oversimplified: just two routers, one p2p link with all three ospf/ldp/
> > ibgp-lu enabled,
> > 
> > show route xx.xxx.xxx.78/32 table inet.0
> > 
> > inet.0:
> > xx.xxx.xxx.78/32   *[OSPF/10] 5d 04:58:59, metric 119
> > >  to xxx.xx.xxx.21 via ae0.6
> > 
> > (so, ospf route is the best one in inet.0)
> > 
> > show ldp database session xx.xxx.xxx.7 | match 
> > "database|xx.xxx.xxx.78/32"
> > Input label database, xxx.xx.xxx.8:0--xx.xxx.xxx.7:0
> >   66742  xx.xxx.xxx.78/32
> > Output label database, xxx.xx.xxx.8:0--xx.xxx.xxx.7:0
> >5743  xx.xxx.xxx.78/32
> > 
> > so the label is present and not filtered (.7 is the router-id of .21),
> > 
> > show route xx.xxx.xxx.78/32 receive-protocol bgp xxx.xx.xxx.21
> > 
> > inet.3: 467 destinations, 1125 routes (467 active, 0 holddown, 0 
> > hidden)
> > Restart Complete
> >   Prefix  Nexthop  MED LclprefAS path
> > * xx.xxx.xxx.78/32xxx.xx.xxx.2119  100I
> > 
> > so, it's received and is the best route in inet.3 (best, because
> > there are no ldp route in inet.3 at all:
> > 
> > show route .. table inet.3
> > 
> > xx.xxx.xxx.78/32   *[BGP/10] 02:10:43, MED 19, localpref 100
> >   AS path: I, validation-state: unverified
> > >  to xxx.xx.xxx.21 via ae0.6, Push 69954
> > 
> > ), and, finally,
> > 
> > show ldp route extensive xx.xxx.xxx.78/32
> > DestinationNext-hop intf/lsp/table  
> > Next-hop address
> >  xx.xxx.xxx.78/32  ae0.6
> > xxx.xx.xxx.21
> >Session ID xxx.xx.xxx.8:0--xx.xxx.xxx.7:0
> > 
> > xxx.xx.xxx.21
> >Bound to outgoing label 5743, Topology entry: 0x776dd88
> >Ingress route status: Inactive
> >Route type: Egress route, BGP labeled route
> >Route flags: Route deaggregate
> > 
> > suggests that presence of ibgp-lu route prevented ldp route from being
> > installed to inet.3 and being used.
> > 
> > PS: idea from KB32600 (copy ibgp-lu route from inet.3 to inet.0 and 
> > then
> > use "from protocol bgp rib inet.0" in ldp egress policy) does not work
> > too. Well, in this case presence of ibgp-lu route does not prevent ldp
> > route from being installed into inet.3 and used as best route (when
> > present, of course), but when ldp/igp route is missed, route received
> > with ibgp-lu not gets redistributed into ldp.
> > 
> >> 
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] labeled-unicast to ldp redistribution ?

[Alexandre Snarskii via juniper-nsp]

On Mon, Dec 20, 2021 at 09:08:40AM -0500, Andrey Kostin wrote:
> Hi Alexandre,
> 
> Not sure that I completely understood the issue. When connectivity 
> between islands recovers, what is the primary route for regular BGP 
> routes' protocol next-hop? 

It's not the connectivity between islands, it's the connectivity 
within IGP island that recovers. Assume the following simple 
topology:

   A == B
   ||
   C == D

Routers A and B form one IGP island, C and D - other, and there are
two ibgp-lu links between islands with ldp->ibgp-lu->ldp redistribution. 

In normal situation, route A to B goes via direct link (igp/ldp),
when link A-B breaks, A switches to ibgp-lu route from C. 
When link A-B recovers, A does not switch back to direct link and
still uses A->C route (in best case it's just suboptimal, in worst
case it results in routing loops).

> Looks like it should be OSPF with route 
> preference lower than BGP and in this case it should be labeled by LDP 
> and propagated. Only if OSPF route for a protocol next-hop is not the 
> best, the next-hop from BGP-LU will be used.

Unfortunately, it's expected behaviour, but not what I see in lab. 
Oversimplified: just two routers, one p2p link with all three ospf/ldp/
ibgp-lu enabled,

show route xx.xxx.xxx.78/32 table inet.0

inet.0:
xx.xxx.xxx.78/32   *[OSPF/10] 5d 04:58:59, metric 119
>  to xxx.xx.xxx.21 via ae0.6

(so, ospf route is the best one in inet.0)

show ldp database session xx.xxx.xxx.7 | match "database|xx.xxx.xxx.78/32"
Input label database, xxx.xx.xxx.8:0--xx.xxx.xxx.7:0
  66742  xx.xxx.xxx.78/32
Output label database, xxx.xx.xxx.8:0--xx.xxx.xxx.7:0
   5743  xx.xxx.xxx.78/32

so the label is present and not filtered (.7 is the router-id of .21),

show route xx.xxx.xxx.78/32 receive-protocol bgp xxx.xx.xxx.21

inet.3: 467 destinations, 1125 routes (467 active, 0 holddown, 0 hidden)
Restart Complete
  Prefix  Nexthop  MED LclprefAS path
* xx.xxx.xxx.78/32xxx.xx.xxx.2119  100I

so, it's received and is the best route in inet.3 (best, because
there are no ldp route in inet.3 at all:

show route .. table inet.3

xx.xxx.xxx.78/32   *[BGP/10] 02:10:43, MED 19, localpref 100
  AS path: I, validation-state: unverified
>  to xxx.xx.xxx.21 via ae0.6, Push 69954

), and, finally,

show ldp route extensive xx.xxx.xxx.78/32
DestinationNext-hop intf/lsp/table  Next-hop address
 xx.xxx.xxx.78/32  ae0.6xxx.xx.xxx.21
   Session ID xxx.xx.xxx.8:0--xx.xxx.xxx.7:0
xxx.xx.xxx.21
   Bound to outgoing label 5743, Topology entry: 0x776dd88
   Ingress route status: Inactive
   Route type: Egress route, BGP labeled route
   Route flags: Route deaggregate

suggests that presence of ibgp-lu route prevented ldp route from being
installed to inet.3 and being used. 

PS: idea from KB32600 (copy ibgp-lu route from inet.3 to inet.0 and then 
use "from protocol bgp rib inet.0" in ldp egress policy) does not work
too. Well, in this case presence of ibgp-lu route does not prevent ldp 
route from being installed into inet.3 and used as best route (when 
present, of course), but when ldp/igp route is missed, route received
with ibgp-lu not gets redistributed into ldp.

> 
> Kind regards,
> Andrey Kostin
> 
> Alexandre Snarskii via juniper-nsp писал(а) 2021-12-17 12:29:
> > Hi!
> > 
> > Scenario: router is a part of ospf/ldp island and also have ibgp
> > labeled-unicast rib inet.3 link to other ospf/ldp island. In normal
> > situations, some routes are known through ospf/ldp, however, during
> > failures they may appear from ibgp-lu and redistributed to ldp just
> > fine. However, when failure ends and route is known via ospf/ldp again,
> > it's NOT actually in use. Instead, 'show ldp route extensive' shows
> > this route as:
> > 
> >Ingress route status: Inactive
> >Route type: Egress route, BGP labeled route
> >Route flags: Route deaggregate
> > 
> > and there are only ibgp route[s] in inet.3 table.
> > 
> > Are there any way to make ldp ignore 'BGP labeled' flag and install
> > route to inet.3 ? (other than making all routes be known not only
> > via ospf/ldp but also via ibgp-lu too).
> > 
> > ___
> > 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] labeled-unicast to ldp redistribution ?

[Alexandre Snarskii via juniper-nsp]

Hi!

Scenario: router is a part of ospf/ldp island and also have ibgp
labeled-unicast rib inet.3 link to other ospf/ldp island. In normal 
situations, some routes are known through ospf/ldp, however, during 
failures they may appear from ibgp-lu and redistributed to ldp just
fine. However, when failure ends and route is known via ospf/ldp again, 
it's NOT actually in use. Instead, 'show ldp route extensive' shows
this route as:

   Ingress route status: Inactive
   Route type: Egress route, BGP labeled route
   Route flags: Route deaggregate

and there are only ibgp route[s] in inet.3 table.

Are there any way to make ldp ignore 'BGP labeled' flag and install
route to inet.3 ? (other than making all routes be known not only
via ospf/ldp but also via ibgp-lu too).

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QFX5100 / EX4300 Traffic impact of buffer re-partition.

[Alexandre Snarskii via juniper-nsp]

On Fri, Jul 02, 2021 at 03:18:51PM +0100, Cathal Mooney via juniper-nsp wrote:
> Hi,
> 
> We have some QFX5100-48S-6Q and EX4300-48T switches, on which we've 
> observed tail drops / outbound discards in our monitoring.
> 
> As a result we plan to re-partition the buffer allocation, assigning the 
> maximum space to the best-effort class as described here:
> 
> https://www.juniper.net/documentation/us/en/software/junos/traffic-mgmt-qfx/topics/example/cos-shared-buffer-allocation-lossy-ucast-qfx-series-configuring.html
> 
> I am curious about the statement that "traffic stops on /all/ ports 
> until buffer reprogramming is complete."  Does anyone have any 
> real-world experience of making this kind of change?  What kind of 

In my practice such changes on standalone switches resulted in short 
enough (<0.1sec) traffic interruptions. No idea about virtual-chassis.

> interruption to packet forwarding should we expect (we're just changing 
> the allocation for the existing default classes - not adding any new 
> ones.)  Also we have these configured in a virtual-chassis of 2 x 
> QFX5100 and 6 x ES4300, any idea on what behaviour to expect in that 
> circumstance?
> 
> Best regards,
> 
> Cathal.
> 
> 
> 
> ___
> 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] MX204: 802.3ad LAG 2 x 1 G with a Palo Alto firewall

[Alexandre Snarskii]

On Thu, Mar 18, 2021 at 01:41:50PM +0200, Antti Ristimäki wrote:
> Hi,
> 
> I don't know what the current state is, but at least initially LAG 
> was not supported in MX204 interfaces when running them at 1G speed. 
> At least the official documentation states that this holds true still.

Interesting limitation. However, on 18.4R3-S6.3 there are no problem
running lacp lag over 1G:

snar@RT> show configuration interfaces xe-0/1/2 gigether-options 
802.3ad ae2;
speed 1g;

snar@RT> show lacp interfaces xe-0/1/2 
Aggregated interface: ae2
LACP state:   Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
  xe-0/1/2   ActorNoNo   Yes  Yes  Yes   Yes FastActive
  xe-0/1/2 PartnerNoNo   Yes  Yes  Yes   Yes FastActive
LACP protocol:Receive State  Transmit State  Mux State 
  xe-0/1/2  Current   Fast periodic Collecting distributing

> 
> Antti
> 
> - On 18 Mar, 2021, at 13:30, Emmanuel Halbwachs 
> emmanuel.halbwa...@obspm.fr wrote:
> 
> > Hello,
> > 
> > I'm having hard times moving a 2 x 1 Gb/s LAG with a Palo Alto
> > firewall from a MX5 to a MX204. The MX204 is on my side, the firewall
> > to the partner side. The firewall have 10G interfaces, but we're stuck
> > to 1G because of the MMF underground link between the two campuses.
> > 
> > The LAG is seen UP on the MX204 but DOWN on the firewall.
> > 
> > If I put a 10G switch before the MX204, using the same transceivers, I
> > can ping the remote side. It worked with a MX5. So there must be
> > something with my MX204 configuration.
> > 
> > If a good soul from here could point me a clue or a direction where to
> > dig, it will make my day.
> > 
> > Here is what seems relevant to me:
> > 
> > chassis {
> >aggregated-devices {
> > ethernet {
> > device-count 1;
> > }
> >}
> >fpc 0 {
> > pic 1 {
> > port 4 {
> > speed 10g;
> > }
> > port 5 {
> > speed 10g;
> > }
> > }
> >}
> > }
> > interfaces {
> >xe-0/1/4 {
> > description "IAP (LAG 1/2)";
> > gigether-options {
> > 802.3ad ae0;
> > speed 1g;
> > }
> >}
> >xe-0/1/5 {
> > description "IAP (LAG 2/2)";
> > gigether-options {
> > 802.3ad ae0;
> > speed 1g;
> > }
> >}
> >ae0 {
> > description "IAP (LAG)";
> > unit 0 {
> > family bridge {
> > interface-mode access;
> > vlan-id 4000;
> > }
> > }
> >}
> >irb {
> > unit 4000 {
> > description IAP-INTERCO-TEST;
> > family inet {
> > address 145.238.192.9/30;
> > }
> > }
> >}
> > }
> > 
> > eh-adm@ro-p-coeur> show interfaces xe-0/1/4 terse
> > Interface   Admin Link ProtoLocal Remote
> > xe-0/1/4upup
> > xe-0/1/4.0  upup   aenet--> ae0.0
> > 
> > eh-adm@ro-p-coeur> show interfaces xe-0/1/5 terse
> > Interface   Admin Link ProtoLocal Remote
> > xe-0/1/5upup
> > xe-0/1/5.0  upup   aenet--> ae0.0
> > 
> > eh-adm@ro-p-coeur> show interfaces ae0 terse
> > Interface   Admin Link ProtoLocal Remote
> > ae0 upup
> > ae0.0   upup   bridge
> > 
> > eh-adm@ro-p-coeur> show interfaces xe-0/1/4 brief
> > Physical interface: xe-0/1/4, Enabled, Physical link is Up
> >  Link-level type: Ethernet, MTU: 1514, MRU: 1522, LAN-PHY mode, Speed: 
> > 10Gbps,
> >  Loopback: None, Source filtering: Disabled,
> >  Flow control: Disabled, Speed Configuration: 1G
> >  Device flags   : Present Running
> >  Interface flags: SNMP-Traps Internal: 0x4000
> >  Link flags : None
> > 
> >  Logical interface xe-0/1/4.0
> >Flags: Up SNMP-Traps 0x24024000 Encapsulation: Ethernet-Bridge
> >aenet
> > 
> > eh-adm@ro-p-coeur> show interfaces xe-0/1/5 brief
> > Physical interface: xe-0/1/5, Enabled, Physical link is Up
> >  Link-level type: Ethernet, MTU: 1514, MRU: 1522, LAN-PHY mode, Speed: 
> > 10Gbps,
> >  Loopback: None, Source filtering: Disabled,
> >  Flow control: Disabled, Speed Configuration: 1G
> >  Device flags   : Present Running
> >  Interface flags: SNMP-Traps Internal: 0x4000
> >  Link flags : None
> > 
> >  Logical interface xe-0/1/5.0
> >Flags: Up SNMP-Traps 0x24024000 Encapsulation: Ethernet-Bridge
> >aenet
> > 
> > eh-adm@ro-p-coeur> show interfaces ae0 brief
> > Physical interface: ae0, Enabled, Physical link is Up
> >  Link-level type: Ethernet, MTU: 1514, Speed: 20Gbps, Loopback: Disabled, 
> > Source
> >  filtering: Disabled, Flow control: Disabled
> >  Device flags   : Present Running
> >  Interface flags: SNMP-Traps Internal: 0x4000
> > 
> >  Logical interface ae0.0
> >Flags: Up SNMP-Traps 0x24024000 Encapsulation: Ethernet-Bridge
> >bridge
> > 
> > 

Re: [j-nsp] EX2300 Code

[Alexandre Snarskii]

On Mon, Dec 09, 2019 at 11:15:01AM +, William wrote:
> Hi,
> 
> I am in the process of getting our first stack of EX2300s ready for
> production, can anyone recommend any specific versions of junos to run
> on them?
> 
> I'm not taking advantage of any advance features, just after something
> stable :)

What you shall NOT run on ex2300 is versions released between Feb 2019
and late November 2019 (we hit this bug on 19.2R1 and 19.3R1):

Number  PR1442376
Release NoteOn EX2300/EX2300-C platforms, if Junos software is with FreeBSD
kernel version 11 with the build date on or after 2019-02-12, the switch may 
stop forwarding traffic or responding to console. Power cycle of switch would 
recover the issue.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] ospf lfa: ecmp vs. srlg ?

[Alexandre Snarskii]

Hi!

Sorry for a bit cryptic subject, let me explain it in details here:
looks like OSPF LFA is able to consider SRLG marking when calculating
backup paths in most cases but not when primary path is already ECMP
over two or more links: in this case backup is not calculated at all, 
despite the fact that both links share the same SRLG markings and can 
go down in the same time...

show ospf backup spf  shows:

XX.XXX.X25.14
  Self to Destination Metric: 22
  Parent Node: XX.XXX.X25.1
  Primary next-hop: ae8.11 via XX.XXX.X33.244
  Primary next-hop: ae2.9 via XX.XXX.X33.246
  Backup Neighbor: XX.XXX.X25.2 via: Direct
Neighbor to Destination Metric: 15, Neighbor to Self Metric: 7
Self to Neighbor Metric: 7, Backup preference: 0x0
Not evaluated, Reason: Primary next-hop multipath

this route is indeed multipath:

snar@Router> show route XX.XXX.X25.14 table inet.0 detail | match via
Next hop: XX.XXX.X33.244 via ae8.11 weight 0x1
Next hop: XX.XXX.X33.246 via ae2.9 weight 0x1, selected

however, both primary interfaces using the same dwdm transmission underlay
and srlg marking on interfaces have four segments in common.

For non-multipath nodes backup route is correctly calculated and uses
different transmission system:

snar@Router> show route XX.XXX.X25.46 table inet.0 detail | match via 
Next hop: XX.XXX.X33.244 via ae8.11 weight 0x1, selected
Next hop: XX.XXX.X34.53 via ae4.8 weight 0xf000

Is there any way to force backup calculation for multipath nodes 
without changing metric to make remote node non-multipath ?

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] JunOS 18, ELS vs non-ELS QinQ native vlan handling.

[Alexandre Snarskii]

On Fri, Jul 26, 2019 at 03:13:52PM +0300, Alexandre Snarskii wrote:
> On Tue, Jul 23, 2019 at 01:45:19AM +0200, Olivier Benghozi wrote:
> > 4 months old thread, but (since I'm starting to test some QinQ stuff just 
> > now), I found both this thread and its «solution»:
> > 
> > PR1413700
> > «Untagged traffic is single-tagged in Q-in-Q scenario on EX4300 platforms»
> > «On EX4300 platforms except for EX4300-48MP with Q-in-Q configured, 
> > untagged 
> > traffic over S-VLAN is forwarded with a single tag, whose processing 
> > behavior 
> > is not in line with other products (e.g., the MX platforms) and other 
> > providers
> > (e.g., Cisco). If Q-in-Q is configured between these devices with different
> > processing behavior of untagged traffic, this might cause the untagged 
> > traffic
> > loss.»
> > 
> > So if I understand well, they suddenly chose compatibility with Cisco & MX 
> > instead of compat with old EX (whereas an option would have been fine).
> > The problem is: I'm not sure at all that it's really the case on Cisco 
> > gears...
> 
> According to our SE, this behaviour will be configurable in 18.3R3, 18.4R3 
> and 19.1R2.

19.3R1: set interface ... input-native-vlan-push disable

> > 
> > > Le 24 mars 2019 à 16:36, Alexandre Snarskii  a écrit :
> > > 
> > > On Fri, Mar 22, 2019 at 04:21:47PM -0400, Andrey Kostin wrote:
> > >> Hi Alexandre,
> > >> 
> > >> Did it pass frames without C-tag in Junos versions < 18?
> > > 
> > > Yes. 
> > > 
> > > tcpdump from upstream side when switch running 17.4R1-S6.1:
> > > 
> > > tcpdump: listening on ix1, link-type EN10MB (Ethernet), capture size 
> > > 262144 bytes
> > > 17:59:15.742379 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
> > > (0x8100), length 64: vlan 171, p 0, ethertype ARP, Ethernet (len 6), IPv4 
> > > (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
> > > 17:59:16.773827 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
> > > (0x8100), length 64: vlan 171, p 0, ethertype ARP, Ethernet (len 6), IPv4 
> > > (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
> > > 
> > > exactly the same setup, switch upgraded to 18.3R1-S2.1:
> > > 
> > > 18:19:28.535143 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
> > > (0x8100), length 68: vlan 171, p 0, ethertype 802.1Q, vlan 1, p 0, 
> > > ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 
> > > tell 10.11.1.1, length 46
> > > 18:19:29.598700 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
> > > (0x8100), length 68: vlan 171, p 0, ethertype 802.1Q, vlan 1, p 0, 
> > > ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 
> > > tell 10.11.1.1, length 46
> > > 
> > > as you see, packets that were transferred with only S-vlan tag
> > > now encapsulated with both S-vlan and 'native' vlan..
> > > 
> > > 
> > >> 
> > >> Kind regards,
> > >> Andrey
> > >> 
> > >> Alexandre Snarskii писал 2019-03-22 13:03:
> > >>> Hi!
> > >>> 
> > >>> Looks like JunOS 18.something introduced an incompatibility of native
> > >>> vlan handling in QinQ scenario between ELS (qfx, ex2300) and non-ELS
> > >>> switches: when ELS switch forwards untagged frame to QinQ, it now adds
> > >>> two vlan tags (one specified as native for interface and S-vlan) 
> > >>> instead
> > >>> of just S-vlan as it is done by both non-ELS and 'older versions'.
> > >>> 
> > >>> As a result, if the other end of tunnel is non-ELS (or third-party)
> > >>> switch, it strips only S-vlan and originally untagged frame is passed
> > >>> with vlan tag :(
> > >>> 
> > >>> Are there any way to disable this additional tag insertion ?
> > >>> 
> > >>> PS: when frames sent in reverse direction, non-ELS switch adds only
> > >>> S-vlan and this frame correctly decapsulated and sent untagged.
> > >>> 
> > >>> ELS-side configuration (ex2300, 18.3R1-S1.4. also tested with
> > >>> qfx5100/5110):
> > >>> 
> > >>> [edit interfaces ge-0/0/0]
> > >>> flexible-vlan-tagging;
> > >>> native-vlan-id 1;
> > >>> mtu 9216;
> > >>> encapsulation extended-vlan-bridge;
> > >>> unit 0 {
> > >>>vlan-id-list 1-4094;
> > >>>input-vlan-map push;
> > >>>output-vlan-map pop;
> > >>> }
> > >>> 
> > >>> (when native-vlan-id is not configured, untagged frames are not
> > >>> accepted at all).
> > >>> 
> > ___
> > 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] JunOS 18, ELS vs non-ELS QinQ native vlan handling.

[Alexandre Snarskii]

On Tue, Jul 23, 2019 at 01:45:19AM +0200, Olivier Benghozi wrote:
> 4 months old thread, but (since I'm starting to test some QinQ stuff just 
> now), I found both this thread and its «solution»:
> 
> PR1413700
> «Untagged traffic is single-tagged in Q-in-Q scenario on EX4300 platforms»
> «On EX4300 platforms except for EX4300-48MP with Q-in-Q configured, untagged 
> traffic over S-VLAN is forwarded with a single tag, whose processing behavior 
> is not in line with other products (e.g., the MX platforms) and other 
> providers
> (e.g., Cisco). If Q-in-Q is configured between these devices with different
> processing behavior of untagged traffic, this might cause the untagged traffic
> loss.»
> 
> So if I understand well, they suddenly chose compatibility with Cisco & MX 
> instead of compat with old EX (whereas an option would have been fine).
> The problem is: I'm not sure at all that it's really the case on Cisco 
> gears...

According to our SE, this behaviour will be configurable in 18.3R3, 18.4R3 
and 19.1R2.

> 
> 
> > Le 24 mars 2019 à 16:36, Alexandre Snarskii  a écrit :
> > 
> > On Fri, Mar 22, 2019 at 04:21:47PM -0400, Andrey Kostin wrote:
> >> Hi Alexandre,
> >> 
> >> Did it pass frames without C-tag in Junos versions < 18?
> > 
> > Yes. 
> > 
> > tcpdump from upstream side when switch running 17.4R1-S6.1:
> > 
> > tcpdump: listening on ix1, link-type EN10MB (Ethernet), capture size 262144 
> > bytes
> > 17:59:15.742379 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
> > (0x8100), length 64: vlan 171, p 0, ethertype ARP, Ethernet (len 6), IPv4 
> > (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
> > 17:59:16.773827 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
> > (0x8100), length 64: vlan 171, p 0, ethertype ARP, Ethernet (len 6), IPv4 
> > (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
> > 
> > exactly the same setup, switch upgraded to 18.3R1-S2.1:
> > 
> > 18:19:28.535143 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
> > (0x8100), length 68: vlan 171, p 0, ethertype 802.1Q, vlan 1, p 0, 
> > ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 
> > tell 10.11.1.1, length 46
> > 18:19:29.598700 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
> > (0x8100), length 68: vlan 171, p 0, ethertype 802.1Q, vlan 1, p 0, 
> > ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 
> > tell 10.11.1.1, length 46
> > 
> > as you see, packets that were transferred with only S-vlan tag
> > now encapsulated with both S-vlan and 'native' vlan..
> > 
> > 
> >> 
> >> Kind regards,
> >> Andrey
> >> 
> >> Alexandre Snarskii писал 2019-03-22 13:03:
> >>> Hi!
> >>> 
> >>> Looks like JunOS 18.something introduced an incompatibility of native
> >>> vlan handling in QinQ scenario between ELS (qfx, ex2300) and non-ELS
> >>> switches: when ELS switch forwards untagged frame to QinQ, it now adds
> >>> two vlan tags (one specified as native for interface and S-vlan) 
> >>> instead
> >>> of just S-vlan as it is done by both non-ELS and 'older versions'.
> >>> 
> >>> As a result, if the other end of tunnel is non-ELS (or third-party)
> >>> switch, it strips only S-vlan and originally untagged frame is passed
> >>> with vlan tag :(
> >>> 
> >>> Are there any way to disable this additional tag insertion ?
> >>> 
> >>> PS: when frames sent in reverse direction, non-ELS switch adds only
> >>> S-vlan and this frame correctly decapsulated and sent untagged.
> >>> 
> >>> ELS-side configuration (ex2300, 18.3R1-S1.4. also tested with
> >>> qfx5100/5110):
> >>> 
> >>> [edit interfaces ge-0/0/0]
> >>> flexible-vlan-tagging;
> >>> native-vlan-id 1;
> >>> mtu 9216;
> >>> encapsulation extended-vlan-bridge;
> >>> unit 0 {
> >>>vlan-id-list 1-4094;
> >>>input-vlan-map push;
> >>>output-vlan-map pop;
> >>> }
> >>> 
> >>> (when native-vlan-id is not configured, untagged frames are not
> >>> accepted at all).
> >>> 
> ___
> 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] JunOS 16.2R2.8 High CPU caused by python

[Alexandre Snarskii]

On Wed, Mar 27, 2019 at 11:35:54AM +0100, Thomas Bellman wrote:
> On 2019-03-26 21:11 -0400, Jason Lixfeld wrote:
> 
> > Not a solution, but an ignorant question - Is there a function to
> > kill (and/or restart) the process in this type of scenario?  On
> > IOS-XR, there were specific XR CLI wrappers for restarting a process
> > as a means to fix stuff like processes run amok without having to
> > reboot the box (or RE/RSP/LC/whatever was misbehaving).
> 
> There is a restart command in Junos, which does exactly that.  E.g:
> 
> bellman@Chili4> restart jsd   
> JET Services Daemon started, pid 62402
> 
> However, it can only restart certain processes (on my switches, I see
> 64 possible daemons in the help when I press "?"), and ICMD does not
> seem to be one of them.  (But that's on an EX4600 running 18.4R1; and
> /usr/libexec/icmd doesn't even exist on it.)

There is also generic way to terminate any process you want:

snar@router> request system process terminate ?
Possible completions:
   Process ID (1..9)

(most of them will be restarted automagically). 

> 
> Also, sometimes the name of the process binary does not match exactly
> with the argument you are supposed to give to the restart command, so
> you may need to think a little bit to figure that out.
> 
> (On 18.3, we had similar problems, but with jsd and ga-nrpc; after a
> few weeks, they started using 100% CPU.  Restarting them helped, but
> after another couple of weeks they ran amok again.  Doesn't happen in
> 18.2 or 18.4, though.)

These processes can be just disabled:

snar@router> show configuration system processes 
jsd disable;
na-grpc-server disable;

> 
> 
>   /Bellman
> 




> ___
> 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] JunOS 18, ELS vs non-ELS QinQ native vlan handling.

[Alexandre Snarskii]

Hi!

Looks like JunOS 18.something introduced an incompatibility of native 
vlan handling in QinQ scenario between ELS (qfx, ex2300) and non-ELS 
switches: when ELS switch forwards untagged frame to QinQ, it now adds 
two vlan tags (one specified as native for interface and S-vlan) instead 
of just S-vlan as it is done by both non-ELS and 'older versions'.

As a result, if the other end of tunnel is non-ELS (or third-party)
switch, it strips only S-vlan and originally untagged frame is passed
with vlan tag :( 

Are there any way to disable this additional tag insertion ?

PS: when frames sent in reverse direction, non-ELS switch adds only 
S-vlan and this frame correctly decapsulated and sent untagged.

ELS-side configuration (ex2300, 18.3R1-S1.4. also tested with 
qfx5100/5110):

[edit interfaces ge-0/0/0]
flexible-vlan-tagging;
native-vlan-id 1;
mtu 9216;
encapsulation extended-vlan-bridge;
unit 0 {
vlan-id-list 1-4094;
input-vlan-map push;
output-vlan-map pop;
}

(when native-vlan-id is not configured, untagged frames are not
accepted at all).

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] rfc8097 (rpki) communities ?

[Alexandre Snarskii]

Hi!

Somewhat stupid question: while experimenting with rpki, I found that
while rfc8097 declares origin validation state as extended community
(0x4300:0.0.0.0:N in juniper configuration terms), Juniper documentation 
uses standard communities 0x4300:N for this purpose:

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-origin-as-validation.html

Junos OS supports the following well-known extended communities for 
route validation:

origin-validation-state-valid
origin-validation-state-invalid
origin-validation-state-unknown

[...]

set policy-options community origin-validation-state-invalid members 0x4300:2
set policy-options community origin-validation-state-unknown members 0x4300:1
set policy-options community origin-validation-state-valid members 0x4300:0

Of course, these communities are not translated to extended ones and
sent as standard 17152:N ones.

One more interesting thing: when I configure RPKI communities manually:

set policy-options community origin_invalid members 0x4300:0.0.0.0:2
set policy-options community origin_unknown members 0x4300:0.0.0.0:1
set policy-options community origin_valid members 0x4300:0.0.0.0:0

and use them to announce validation information to other routers,
these communities displayed either as 'unknown iana opaque':

 Communities: unknown iana opaque 0x4300:0x0:0x2 

(junos 17.3R3-S3.3 and 18.3R1-S2.1) or even as just 'unknown iana 4300' 
(15.1R6).

Question: is it just a bit outdated documentaton and I shall follow
RFC and use extended communities, or there are some other reasons
to use standard ones ?

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Use cases for IntServ in MPLS backbones

[Alexandre Snarskii]

On Tue, Oct 02, 2018 at 01:10:14PM +0300, Saku Ytti wrote:
> Hey Mark,
> 
> > We remark all incoming Internet traffic DSCP values to 0.
> >
> > A few years ago, not doing this led to issues where customers were 
> > handling the DSCP values in such a way that any traffic marked as 
> > such was being dropped. Took weeks to troubleshoot.
> 
> Dropped by who? I as an Internet user would prefer my DSCP information
> to traverse internet, I do not ask it to be honoured.
> 
> If customer has problems with DSCP, then of course they can nullify it
> in their network, or you can even sell it as service to them. But to
> nullify it for everyone seems quite big hammer, unless of course in
> your particular deployment it would be technically not possible to
> retain them.

Retaining DSCP in juniper networks leads to consequence of not showing
egress router in traceroute. Well, it's quite easy to classify packet
on ingress (based on interface), and it's quite easy to mark packet
with MPLS EXP and use this marking along the route, but at the egress
router picture is a bit different: in normal situation with 
penultimate-hop-popping packet reaches egress router without MPLS 
encapsulation, so you have to believe external (customer's or peer's) 
marking to [mis]classify packet. Of course, you can use ultimate-hop 
popping (explicit-null) so MPLS EXP can be used at egress router too, 
but in this case egress router will not decrement ip ttl and generate
icmp unreachable/ttl exceeded and so will not be shown in traceroutes 
making troubleshooting much harder.

Or am I missing something ? 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX300 - How much MPLS can be done with that platform?

[Alexandre Snarskii]

On Fri, Aug 24, 2018 at 10:31:14AM -0400, Alain Hebert wrote:
>      Curious to know.

Not too much. In my tests srx300 was able to serve only about 
~260kpps (91Mbit) of small packets and ~110kpps (460Mbit) of 
large ones. Numbers are somewhat 'half-duplex', for packets it's
overall performance, for bps - it's single direction. Actual screen
scrape on a peak survivable load (large packets):

  Input rate : 465659072 bps (55027 pps)
  Output rate: 463557760 bps (54989 pps)
 
>      The commands are there...  Most of the things seems functional up 
> to LDP.

l2circuits works fine.

> 
>      Have a good day.
> 
> -- 
> -
> Alain Hebertaheb...@pubnix.net
> PubNIX Inc.
> 50 boul. St-Charles
> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
> Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
> 
> ___
> 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] Junos 15.1 and DPC

[Alexandre Snarskii]

On Fri, Aug 11, 2017 at 07:24:32AM +, Misak Khachatryan wrote:
> Hi,
> 
> we run 15.1R4-S8 on MX-480 with RE-S-1300 and a few DPCE 4x 10GE R and
> DPCE 20x 1GE + 2x 10GE R for a while, no problem. We use it as pure
> internet border router with bunch of peers and upstreams.

Keep in mind that 14.2 is the last supported software version for 
RE-S-1300 (TSB16556). Looks like newer versions require more RAM than 
this RE can hold  :( 
After about a half-year uptime one of our routers with RE-S-1300 and
15.1F5-S1 got into a problem with memory overconsumption:

20:40:05 rpd[3118]: RPD_KRT_Q_RETRIES: Route Update: Cannot allocate memory
20:40:08 kernel: rt_pfe_veto: Memory over consumed. Op 1 err 12, rtsm_id 5:-1, 
msg type 2
20:40:13 kernel: rt_pfe_veto: Memory over consumed. Op 1 err 12, rtsm_id 5:-1, 
msg type 2

under these conditions ssh/telnet access stopped working, some routes
were not installed into FIB and so on...

PS: back to subject: can confirm that we got no problems (yet?) 
running 15.1F5-S1/15.1F7 on DPC.

> 
> Best regards,
> Misak Khachatryan,
> Network Administration and
> Monitoring Department Manager,
> 
> GNC- ALFA CJSC
> 1 Khaghaghutyan str., Abovyan, 2201 Armenia
> Tel: +374 60 46 99 70 (9670),
> Mob.: +374 55 19 98 40
> URL:www.rtarmenia.am
> 
> 
> On Thu, Aug 10, 2017 at 11:59 AM, john doe  wrote:
> > Hi
> >
> > Will 15.1 work well on MX boxes with old DPC cards? Anyone running 15.1 on
> > MX with DPC?
> >
> > Johan
> > ___
> > 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] bgp peer flapping

[Alexandre Snarskii]

On Thu, Apr 27, 2017 at 03:04:41PM +0100, adamv0...@netconsultings.com wrote:
> > > >
> > > > How often do we rename bgp group names ?  I don't ever.  Wondering
> > > > if this is something that people do often.
> > > >
> > > Do you never change bgp egress policies too?
> > >  - if you do it at the peer level it has the same effect.
> > 
> > Looks like it is not true since JunOS 15.1 or so.
> That would be great news, can you please share the link. 

Not sure if this change documented anywhere. However, what I see in
reality:

snar@Router> ...wnLinks neighbor 172.31.7.17 | compare rollback 1   
[edit protocols bgp group DownLinks neighbor 172.31.7.17]
- export default_and_google_only;
+ export default_originate_only;

{master}
snar@Router> ... DownLinks neighbor 172.31.7.17 | compare rollback 2

{master}
snar@Router> show bgp summary | match 172.31.7.17
172.31.7.17   65534  75147 176660   0   0 1w6d 1:08:30 
Establ

As you see, policy was changed and than this change was rolled back
(another change) and session is stable for about two weeks..

> > 
> > > Basically Junos requires you to have each peer in its own group to be
> > > on safe side.
> > 
> > Having each peer in its own group is one of the best ways to shoot
> yourself in
> > the foot: instead of all peers with same egress policies share RIB-Out, in
> this
> > model each one will have its own RIB so memory use will go through the
> > roof.. (well, at least in SP scenario, where most peers need to keep
> full-view
> > in RIB).
> If the box is in a transit role (has to advertise full internet feed to
> multiple peers) then with separate peer group for each peer, depending on
> how may peers you have, this can harm you or not. But on modern code and RP
> you should be able to hold ~15M+ routes so unless you have 25 of such
> transit peers on one box you should be fine.  

... and with all those peers in one group I'm fine running 25 of such 
peers on good old RE-S-2000 with memory utilization of 24%:

GroupType   Peers EstablishedActive/Received/Accepted/Damped
DownLinksExternal   2825 

DRAM  3584 MB (4096 MB installed)
Memory utilization  24 percent
[...]
Model  RE-S-2000

Well, this is an easy case: all peers in this group have the same 
egress policy. However, even in a much more complicated setup, RE-S-2000
still shows memory utilization of 64%, nowhere close to its limits.

> But exactly,  
> Junos places peers to update groups based on actual commonalities in egress
> policies like IOS ONLY within a peer group (and unlike IOS if it changes
> that automatically it resets the peer), but egress policy commonalities are
> not compared across peer groups -so each new peer group is automatically new
> update group (very inefficient indeed). 

.. and so you shall have number of groups as small as possible. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] bgp peer flapping

[Alexandre Snarskii]

On Thu, Apr 27, 2017 at 08:00:33AM +0100, adamv0...@netconsultings.com wrote:
> > Aaron Gould [mailto:aar...@gvtc.com]
> > Wednesday, April 26, 2017 7:08 PM
> > 
> > How often do we rename bgp group names ?  I don't ever.  Wondering if this
> > is something that people do often.
> > 
> Do you never change bgp egress policies too?
>  - if you do it at the peer level it has the same effect. 

Looks like it is not true since JunOS 15.1 or so.

> Basically Junos requires you to have each peer in its own group 
> to be on safe side. 

Having each peer in its own group is one of the best ways to shoot
yourself in the foot: instead of all peers with same egress policies
share RIB-Out, in this model each one will have its own RIB so memory
use will go through the roof.. (well, at least in SP scenario, where
most peers need to keep full-view in RIB).

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP add-path on QFX

[Alexandre Snarskii]

On Fri, Jan 27, 2017 at 05:00:59PM +0100, Vincent Bernat wrote:
> >> I have upgraded some QFX to 16.1R3 but there is no difference with
> >> 14.1X53-D40: add-path is an hidden command and only "receive" is
> >> available ("send" is not accepted):
> >> 
> >>   set protocols bgp group batman family inet unicast add-path send ...
> >> 
> >> I have also tried on MX104 running 14.1R8. Feature explorer says this
> >> should be supported since 13.2R2. But I am in the exact same situation:
> >> add-path is a hidden command and only "receive" is available.
> >> 
> >> I wonder if I am not missing something obvious. Any tip would be
> >> appreciated!
> >
> > No ideas on what can be wrong with your configuration :(
> > We run add-path on most MXes without any problems. Just tried with QFX 
> > (not running bgp actually), add-path command is not hidden for me and 
> > commit 
> > check succeeds: 
> 
> Thanks for checking, that's helpful!
> 
> In fact, I am using routing instances. Like you, I can get add-path
> send/receive outside a routing instance, but inside, add-path is
> hidden. I assumed this was independent of the routing instance
> (configured type virtual-router), so I didn't bother to check that.
> 
> Does "set routing-instances rr1 protocols bgp group apath family inet
> unicast add-path ..." complete for you?

Looks like routing-instances is the difference. Within routing-instance
add-path does not complete for me too, neither on QFX nor on MX.

> -- 
> ROMEO:Courage, man; the hurt cannot be much.
> MERCUTIO: No, 'tis not so deep as a well, nor so wide
>   as a church-door; but 'tis enough, 'twill serve.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP add-path on QFX

[Alexandre Snarskii]

On Fri, Jan 27, 2017 at 03:02:09PM +0100, Vincent Bernat wrote:
> Hey!
> 
> I am using some QFX as route reflectors and would like to use BGP
> add-path feature. The documentation says that QFX is a supported
> platform[0] while the feature explorer says no QFX has support for
> that[1].
> 
> [0]: 
> http://www.juniper.net/techpubs/en_US/junos16.1/topics/example/bgp-add-path.html
> [1]: 
> https://pathfinder.juniper.net/feature-explorer/feature-info.html?fKey=3294=For+internal+BGP+(IBGP),+advertise+multiple+paths+to+a+destination
> 
> I have upgraded some QFX to 16.1R3 but there is no difference with
> 14.1X53-D40: add-path is an hidden command and only "receive" is
> available ("send" is not accepted):
> 
>   set protocols bgp group batman family inet unicast add-path send ...
> 
> I have also tried on MX104 running 14.1R8. Feature explorer says this
> should be supported since 13.2R2. But I am in the exact same situation:
> add-path is a hidden command and only "receive" is available.
> 
> I wonder if I am not missing something obvious. Any tip would be
> appreciated!

No ideas on what can be wrong with your configuration :(
We run add-path on most MXes without any problems. Just tried with QFX 
(not running bgp actually), add-path command is not hidden for me and commit 
check succeeds: 

--- JUNOS 14.1X53-D35.3 built 2016-02-29 23:35:46 UTC
[...]
snar@QFX5100# set protocols bgp group apath family inet unicast ?
Possible completions:
  <[Enter]>Execute this command
> accepted-prefix-limit  Limit maximum number of prefixes accepted from a peer
> add-path Advertise multiple paths to peer
> aigp Allow sending and receiving of AIGP attribute
+ apply-groups Groups from which to inherit configuration data
[...]

snar@QFX5100# show | compare 
[edit protocols]
+   bgp {
+   group apath {
+   family inet {
+   unicast {
+   add-path {
+   send {
+   path-count 6;
+   }
+   }
+   }
+   }
+   }
+   }

{master:0}[edit]
snar@QFX5100# commit check 
[edit protocols]
  'bgp'
warning: requires 'bgp' license
configuration check succeeds


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] DCU matching in firewall filter

[Alexandre Snarskii]

On Tue, Sep 13, 2016 at 08:35:26PM +0900, Paul S. wrote:
> Hi j-nsp,
> 
> I'm trying to use DCU to filter access to specific prefixes selectively 
> on Juniper MX. i.e: Customer on interface ge-0/0/0 cannot send traffic 
> to prefixes tagged by some BGP community, or perhaps it'll be sent to a 
> policer.
[...]
> So, is there any other way to apply this only on the concerned customer 
> interfaces, or are we going to have to maintain a large 
> forwarding-options filter with entries like 'term 1 from 
> destination-class dcu-local; interface x; then ...' and 'term 2 from 
> destination-class dcu-local; interface y' ...'

You can group customer interfaces using interface-set, e.g.

set firewall interface-set customer-local ge-0/0/0.0
set firewall interface-set customer-local ge-0/0/1.0

and then use that interface set together with DCU in pfe filter, 

term cust-local from destination-class dcu-local interface-set customer-local

Not as nice as having DCU in ingress filter, but still much better than 
one term per interface. 



___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] self-pointing route resolution: static vs. bgp ?

[Alexandre Snarskii]

Hi!

Imagine there is a directly connected network: 

A.B.C.40/29   *[Direct/0] 41w1d 00:10:40
> via xe-0/0/2.232

There is a good old trick: you can configure 'self-pointing'
host route with next-hop within this network: 

snar@router> show configuration routing-options static route A.B.C.43/32
   
next-hop A.B.C.43;

it will be accepted, resolved and installed into routing table:

snar@router> show route A.B.C.43/32 detail 

A.B.C.43/32 (1 entry, 1 announced)
State: 
*Static Preference: 5
Next hop type: Router, Next hop index: 1256
Address: 0x21a45c90
Next-hop reference count: 5
Next hop: A.B.C.43 via xe-0/0/2.232, selected

(this trick was used before introduction vrf-table-label to install 
host routes in vrf's for customers who did not wanted to install CPE).

However, when such self-pointing route is received over iBGP 

snar@router> show route A.B.C.42/32 receive-protocol bgp ...

  A.B.C.42/32 (1 entry, 0 announced)
 Accepted
 Nexthop: A.B.C.42
 MED: 100
 Localpref: 20
 AS path: I

it becomes hidden with Unusable next-hop

snar@router> show route A.B.C.42/32 hidden detail 

A.B.C.42/32 (1 entry, 0 announced)
 BGPPreference: 170/-21
Next hop type: Unusable
Address: 0x24e59bc
Next-hop reference count: 3
State: 
Accepted
Localpref: 15
Indirect next hops: 1
Protocol next hop: A.B.C.42
Indirect next hop: 0 - INH Session ID: 0x0


and not installed into forwarding table. Well, Juniper documentation
clearly says[1] that it will not accept route pointing to device itself,
but it is not the case, Local address is .41:

A.B.C.41/32   *[Local/0] 44w0d 23:41:25
  Local via xe-0/0/2.232


Question: are there any way to convince JunOS to resolve and install
such self-pointing route when received over iBGP ?  

12.3R5.7, MX80 if that matters.

[1]:
http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/hidden-routes-understanding.html
Routes can be hidden for the following reasons:
[...]
The next hop address is the address of the local routing device.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Junos BGP update generation inefficiency -cause for concern?

[Alexandre Snarskii]

On Mon, May 18, 2015 at 10:04:00AM +, Adam Vitkovsky wrote:
 Hi folks,
 
 I'd like to ask if the 90's way of BGP generating updates per peer-group 
 is a cause for concern on a modern gear.
 And if not then anyways am I the only one missing some flexibility in 
 BGP peers configuration in Junos?
 It's really annoying that every time one needs to adjust something for a 
 peer, might even be something session related, a new peer-group has to be 
 carved up.

Is creation of new peer-group really needed ? 

We have absolutely no problems configuring common settings at group-level
and customized settings at peer level: 

s...@rt.ov.spb show configuration protocols bgp group DownLinks   
type external;
import deny_any;
export eBGP_to_customer_default;
remove-private;
multipath multiple-as;
/* typical customer setup, only import policy modified */
neighbor XX.XXX.XXX.XX {
description ...;
passive;
import eBGP_from_Customer1;
peer-as 123456;
}
/* another customer who wants default route together with full-view, 
   so export policy customized too */
neighbor XX.XXX.XXX.XX {
description ;
passive;
import eBGP_from_Customer2;   
export [ default_originate eBGP_to_customer_default ];
peer-as 123457;   
}
/* yet another customer, multihomed (thus metric-out) and with personal
   prefix-limit, prefix-filter is not enough in this case */
neighbor XX.XXX.XXX.XX {
description ..;
metric-out igp;
passive;
import eBGP_from_Customer3;
family inet {
unicast {
prefix-limit {
maximum 1000;
teardown 30 idle-timeout 10;
}
}
}
peer-as 123458;
}


 
 adam
 ---
  This email has been scanned for email related threats and delivered safely 
 by Mimecast.
  For more information please visit http://www.mimecast.com
 ---
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX Series Routers (BGP MPLS L3 VPN RFC 2547bis)

[Alexandre Snarskii]

On Thu, May 22, 2014 at 12:29:16AM -0300, Giuliano Medalha wrote:
 ???People,
 
 Does anyone using ACX Series considering BGP MPLS L3 VPN (RFC 2547 bis) ?
 
 It has some limitation ?   
 Any feature not available ?

When I tested ACX in lab (about one year ago), there were two 
mission-critical features missing: uRPF and aggregated interfaces.
Also, there were no 'family bridge'. 

Not sure if these limitations are hardware or software and if they
can be/are already fixed.

 And about the scalability ?   It works fine 
 
 Could you please share some practical and real experience ?
 
 How many VRF ?   Max PPS ?
 
 The ASX does use any ASIC ?  Like TRIO ?  The control plane is PPC  ?
 
 Thanks a lot,
 
 Giuliano
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] CoS and ingress traffic with DSCP markings

[Alexandre Snarskii]

On Wed, Jan 22, 2014 at 09:20:36AM -0700, John Neiberger wrote:
 I ran into an issue yesterday that confused me, which seems to be a
 weekly occurrence lately regarding Juniper CoS.. We had an interface
 that was receiving traffic marked as EF. The interface only had the
 default CoS configuration. For some reason, the traffic was arriving
 at the destination marked as CS0. After I applied the CoS group to the
 interface, which included classifiers, the packets started arriving at
 the destination as EF like they were supposed to be.
 
 I don't understand why a lack of CoS config would reset DSCP markings
 for traffic that is already marked when it hits the router. Could it
 be that since there were no ingress classifiers, the traffic was not
 put into a forwarding class, so the rewrite rules on egress re-marked
 it? 

When there are no explicit classifiers configured for interface, there 
are implicit default ones applied: 

s...@lab.spb show class-of-service interface ge-1/0/0.13 detail 
  Logical interface: ge-1/0/0.13, Index: 336
Object  Name   TypeIndex
Classifier  ipprec-compatibility   ip 13

and yes, this classifier maps EF (DSCP 101110 = IPPREC 101) traffic 
to BE forwarding class: 

s...@lab.spb show class-of-service classifier name ipprec-compatibility   
Classifier: ipprec-compatibility, Code point type: inet-precedence, Index: 13
  Code point Forwarding classLoss priority
  000best-effort low 
  001best-effort high
  010best-effort low 
  011best-effort high
  100best-effort low 
  101best-effort high
  110network-control low 
  111network-control high

so rewrite-rule configured on outbound interface will rewrite dscp/ipprec
to all-zeros (default for BE). 

 That just occurred to me. I'm going to go check the rewrites rules
 we have applied on egress to see if that is what was happening. I was
 under the bad assumption that traffic already marked would traverse
 the router unchanged.
 
 Thanks,
 John
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX2200 rate limiting per port ?

[Alexandre Snarskii]

On Thu, Oct 17, 2013 at 10:46:45AM +0200, Mark Tinka wrote:
  I'm looking for a small switch that can rate limit
  traffic in and out per port with a granularity of 5mb or
  less. Typical application would be ethernet distribution
  within a building where each office gets a (possibly
  different) amount of bandwidth.
  
  Can the EX2200 do this?
 
 Access or closet switches are notorious for not supporting 
 egress policing.

Actually, EX-series supports egress shaping, which may be sufficient in 
this case (iirc, shapers applied port-wide, there are no way to shape 
this vlan and do not shape (or shape differently) another one). 

On the other hand, shapers and policers should be applied not on the
edge switches but rather on customer-facing routers... 

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SSD disks high failure ratio ?

[Alexandre Snarskii]

On Tue, Oct 08, 2013 at 08:17:16AM +0100, Phil Mayers wrote:
 Does anyone knows what is the 'software solution' that 'has also been
 developed to correct the affected REs in the field' as said in the KB ?
 
 
 Yes, that bit of the PR is annoyingly coy, isn't it?
 
 JTAC told me:
 
 
 So, you need to perform the secure erase of the contents on the SSD to 
 fix this issue.
 This secure erase is done by TAC and I will work with service manager of 
 this account to check how to move forward on this.
 
 
 This is just weird; it's not like a secure erase is some kind of 
 super-secret thing - just break into the shell from alternate boot media 
 and run the command - so why not document it for customers to self-perform?

Juniper recovery procedure aka 'software solution':
- upload custom code provided by Juniper to RE
- reflash BIOS using uploaded binary and image 
- reboot with new BIOS (I think it uses somewhat different initialization
procedure for SSD disks)
- SSD maintenance with uploaded atacontrol binary (secure erase).
- SSD re-partition (by standard request system snapshot partition means).
- reflashing BIOS again, with different code (rollback, I suppose)
- final reboot.

As far as you do not have neither BIOS codes nor customised atacontrol
binary - you can't just run command. And BIOS update steps looks like
reason for Juniper to require only our qualified personnel can do this
maintenance. 

PS: of course, you still can just replace SSD with third-party one,
avoiding Juniper involvement. Not sure if this breaks warranty, though.

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] SSD disks high failure ratio ?

[Alexandre Snarskii]

Hi!

Anyone else experienced high failure ratio with SSD disks installed on 
RE-S-1800x4 or it's just we are that lucky to have two disks failed 
within one week ? :( 

PS: and, just to fill the gap in the documentation: these disks are not
the usual 2.5 notebook-like, they are 1.8 mSATA, not yet widely used 
form-factor, so you can't just get replacement from the nearest PC shop. 
Discovering this after ~400km drive adds more fun :)

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SSD disks high failure ratio ?

[Alexandre Snarskii]

On Wed, Sep 18, 2013 at 01:51:29PM +, Anders Karlsson wrote:
 Hi,
 
 It's known Juniper problem. Contact them and they will fix it.

Thanks for clarification. RMA is underway indeed, just wanted to check
if I should expect more failures or it was some irregular spike. 

 
 /Anders
 
 
  -Original Message-
  From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On
  Behalf Of Alexandre Snarskii
  Sent: den 18 september 2013 15:43
  To: Juniper-NSP Mailing list
  Subject: [j-nsp] SSD disks high failure ratio ?
  
  
  Hi!
  
  Anyone else experienced high failure ratio with SSD disks installed on
  RE-S-1800x4 or it's just we are that lucky to have two disks failed
  within one week ? :(
  
  PS: and, just to fill the gap in the documentation: these disks are not
  the usual 2.5 notebook-like, they are 1.8 mSATA, not yet widely used
  form-factor, so you can't just get replacement from the nearest PC
  shop.
  Discovering this after ~400km drive adds more fun :)
  
  --
  In theory, there is no difference between theory and practice.
  But, in practice, there is.
  
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.net
  https://puck.nether.net/mailman/listinfo/juniper-nsp

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4550 and 3rd Party SFP-1GE-LX

[Alexandre Snarskii]

On Thu, Jun 06, 2013 at 03:57:54PM +0800, Joe Wooller wrote:
 Hey All, 
 
 I was wondering if anyone out there has seen issues with 3rd party 
 1Gig LX Optics on the EX4550.
 We have a bunch of 3rd party optics working fine in EX2200s, 3200s 
 and 4200s however when I stick them into the EX4550 it randomly likes 
 to fail (I can't seem to figure out the pattern). Sometimes it will 
 work and sometimes it wont.
 When it does fail however it seems to make the port inoperable until 
 the switch is rebooted. (It also appears to make other ports break too, 
 perhaps they are on the same PFE?). Even inserting a Genuine optic after 
 the port has failed produces the same error.

Interesting. We also encountered some incompatibilities with 
third-party optics on EX4550, however, with some differences: 
a) these incompatibilities was caused mostly by color (DWDM) 10Ge SFP+
(well, some 1ge-lx too). 
b) we observed no persistent effect of incompatibility - after changing SFP+ 
to another more compatible (however, still third-party) SFP/SFP+ port works
just fine without reboot.


 Without further ado here is the error it produces;
 
 pr 10 04:44:45  sw01 chassism[1298]: ifcm_ifd_remove_vector: ifd ge-0/0/29 
 is_vcp 0 peer master
 Apr 10 04:44:48  sw01chassism[1298]: Error(2):I2C read of EEPROM failed for 
 Port 14 at offset 0x0
 Apr 10 04:44:48  sw01chassism[1298]: KOPTICS(1215): Error reading xcvr eeprom 
 for PIC 61515 port 14
 Apr 10 04:44:48  sw01chassism[1298]: XCVR: XCVR 14 EEPROM read Failed
 Apr 10 04:44:48  sw01chassism[1298]: xcvr_cache_eeprom: xcvr_read_eeprom 
 failed - link:14 pic_slot:0
 Apr 10 04:44:49  sw01chassism[1298]: Error(2):I2C read of EEPROM failed for 
 Port 14 at offset 0x0
 Apr 10 04:44:49  sw01chassism[1298]: KOPTICS(1215): Error reading xcvr eeprom 
 for PIC 61515 port 14
 Apr 10 04:44:49  sw01.chassism[1298]: XCVR: XCVR 14 EEPROM read Failed
 
 I would be interested to see if anyone else has encountered this?
 So far I can not replicate the issue with 3rd party Copper SPF;s or 
 10Gig SFP+'s.
 
 Cheers
 Joe
 
 
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] curious optic issue

[Alexandre Snarskii]

On Tue, Jan 29, 2013 at 11:04:10AM +0200, Saku Ytti wrote:
  Fix is to remove+reinsert optic, or reload router. I've not yet tried
  'test xfp 1 power off|on', but I'm guessing it'll help too.
 
 I can confirm that 'test xfp 1 power off|on' 'fixes' the issue as well. 

Are there any way to power-off SFP+ in MPC-3D-16XGE as well ? 
Looks like we have the same issue in one more location... :(

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MX/SCB-E fabric saturation ?

[Alexandre Snarskii]

Hi!

During DDoS attack targeted to one of our customers we experienced
serious drops on one of our MX960/SCB-E routers. 

Topology: DDoS mostly came to this router via one of backbone links
(10x10Gbit aggregate-ethernet, ingress ports are distributed among 
six MPC-3D-16XGE) and had to egress towards destination router via port 
on one of MPCs (let's call it egress fpc). Well, it's expected that 
there will be packet drops on egress port, may be even on fabric towards 
egress FPC, but what I did not expected is that fabric drops were observed 
between _every_ FPCs. 

For example, drops on FPC0, handling one of ingress links shows 
drops not only towards FPC7 (egress), but to other FPCs too: 

Destination FPC Index: 0, Source FPC Index: 0
 Drop statistics:High priority   Low priority
Packets: 0  100640048
Bytes  : 044394325857
Pps: 0  0
Bps: 0  0
Destination FPC Index: 2, Source FPC Index: 0
 Drop statistics:High priority   Low priority
Packets: 0  168074394
Bytes  : 077508987723
Pps: 0  0
Bps: 0  0
Destination FPC Index: 7, Source FPC Index: 0
 Drop statistics:High priority   Low priority
Packets: 0 1419251793
Bytes  : 0  1287328070805
Pps: 0  0
Bps: 0  0

During this incident, show pfe statistics traffic reported only about 
29Mpps forwarded by this router, while normal load is about 55Mpps. 
After isolating DDoS destination and filtering it out at borders
situation returned back to normal. 

Questions are obvious: are we missing something in configuration ? 
(CoS settings for fabric are default ones, Scheduler: default-fabric,
drop-profile: default-drop-profile). 
Can 11.4R7 with configured chassis fabric redundancy increased-bandwidth 
help in such situations ? 

JunOS version: 11.4R6, if that matters. 

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MPLS and QoS at penultimate hop ?

[Alexandre Snarskii]

On Mon, Feb 04, 2013 at 09:36:10AM -0900, Christopher E. Brown wrote:
 
 The packet is classified on input.
 
 *UNLESS* you use table-label in a l3vpn, then it gets re-classified
 after the label POP.

Intresting. However, my question is not about l3vpn, it is about plain 
old IPv4 packet with one MPLS header entering PHP router programmed to Pop 
this header and forward this packet towards next (egress) router..

Example: 

ingress router:

AA.BBB.205.0/25*[BGP/170] 6w1d 22:28:33, MED 100, localpref 200, from 
AA.BBB.224.5
 to AA.BBB.233.133 via ae2.6, Push 604050

(BA-classification is done on ipprec/dscp of ingress packet)

PHP router: 

604050 *[LDP/9] 4d 00:37:22, metric 1
 to AA.BBB.233.13 via ae4.9, Pop  
604050(S=0)*[LDP/9] 4d 00:37:22, metric 1
 to AA.BBB.233.13 via ae4.9, Pop  

(BA-classification is most possibly done on ip-prec after Pop is done, 
but that's the point where I'm not sure Classification on EXP may be 
more accurate: as there are no payload type field in MPLS header, this 
router just can't know that packet's content is IPv4).


 On 2/3/13 6:03 PM, Chris Kawchuk wrote:
  It was my understanding that the label was logically popped on
  Egress (in terms of how one would envision the packet flow); hence
  the outer label EXP bits were evaluated by the BA classifier on
  ingress properly. (Whether it's popped on ingress, yet evaluated
  prior-to-pop is a mechanics thing..)
  
  But yes, I have no documentation I can point to; off the top of my
  head that the above is indeed true. I would be interested to know for
  future information sake that the JNPR box is indeed doing the right
  thing so to speak? i.e. since the PIC/MPC pops the Layer-2
  information as well, it needs to be able to read the 802.1P bits, if
  there is a 1p-VLAN tag BA applied to the interface. Hopefully we're
  also reading the outer EXP label at the same time; as this would make
  sense.
  
  i.e. if you're doing VLAN pop/swapping, you'd need to retain any
  BA-p-tag specific classification there as well, prior to any tag
  manipulation.
  
  400 quatloos says it's done on ingress before the label is popped.
  
  - Ck.
  
  
  
  Simple question I'm not able to find answer for: what is the order
   of label pop operation and BA classification on penultimate router
  ?
  
  I have a gut feeling that label is stripped first and then BA 
  classification is done on a naked packet, f.e., ipprec-based in
  case of IP packet, without taking (already stripped) EXP bits into
   account, but I can't find any documentation proving or disproving
  it...
  
  
  ___ juniper-nsp mailing
  list juniper-nsp@puck.nether.net 
  https://puck.nether.net/mailman/listinfo/juniper-nsp
  
 
 
 -- 
 
 Christopher E. Brown   chris.br...@acsalaska.net   desk (907) 550-8393
  cell (907) 632-8492
 IP Engineer - ACS
 
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MPLS and QoS at penultimate hop ?

[Alexandre Snarskii]

Hi!

Simple question I'm not able to find answer for: what is the order 
of label pop operation and BA classification on penultimate router ? 

I have a gut feeling that label is stripped first and then BA 
classification is done on a naked packet, f.e., ipprec-based
in case of IP packet, without taking (already stripped) EXP bits into 
account, but I can't find any documentation proving or disproving it... 

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] curious optic issue

[Alexandre Snarskii]

On Mon, Jan 28, 2013 at 09:50:06AM +0200, Saku Ytti wrote:
 I've seen at least twice now issues on XFP where temperature starts to draw
 weird saw-tooth, like this http://ytti.fi/ddm2.png

About the same issue here: http://snar.spb.ru/xe.png. 

Differences between our and your cases: 
- we observed this behaviour on SFP+ (MPC-3D-16XGE, MX960 and MX480,
JunOS 11.4 and 10.4), not on XFP/MX80.
- other ports were not affected by this temperature shift in our case.
Similarities: 
- SFP+ removal/re-insertion is the easiest way to fix SFP+, MPC reboot 
helps too.
- No JTAC case, third-party DWDM SFP+. 

Some months ago we observed even more interesting situation: seven SFP+ 
in DWDM trunk (10xSFP+) started freezing in about the same time. 
All freezing SFPs were from the same vendor, and one of non-freezing 
SFPs was from the same vendor, whith the only difference - this SFP was 
removed and re-inserted into trunk in summer, while other SFPs in trunk 
worked since end of the March 
So, now I'm waiting for May when this SFP should freeze too and prove 
my hypothesis: there is some monotonically increasing counter (not sure 
if it is on SFP or in JunOS code) that messes up with temperature 
readings.

[]
 At least now I can go to DC, plug with my JNPR-crash-tool and crash
 competitors routers with no traces in syslogs.

If my hypothesis is true, you have to wait for about eight months
before crash happens :) 

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] FPC CPU

[Alexandre Snarskii]

On Mon, Sep 24, 2012 at 02:41:46PM +0400, Nick Kritsky wrote:
 Dear j-nsp,
 
 Apologies, if this is a trivial FAQ - but I cannot find the
 information anywhere.
 For M, MX, EX series there is an OID for monitoring FPC CPU.
 Question - what is this CPU for? What are we measuring here?

Short answer: it depends. 

Longer answer: if you using jnxOperatingCPU (.1.3.6.1.4.1.2636.3.1.13.1.8)
for CPU monitoring, you may use corresponding jnxOperatingDescr OID
(.1.3.6.1.4.1.2636.3.1.13.1.5) to determine which one CPU you're 
monitoring.

For example, closest MX reports following operating entries: 

snar@fri:~snmpbulkwalk -v2c some MX960 .1.3.6.1.4.1.2636.3.1.13.1.5
SNMPv2-SMI::enterprises.2636.3.1.13.1.5.1.1.0.0 = STRING: midplane
SNMPv2-SMI::enterprises.2636.3.1.13.1.5.2.1.0.0 = STRING: PEM 0
SNMPv2-SMI::enterprises.2636.3.1.13.1.5.2.2.0.0 = STRING: PEM 1
SNMPv2-SMI::enterprises.2636.3.1.13.1.5.2.3.0.0 = STRING: PEM 2
SNMPv2-SMI::enterprises.2636.3.1.13.1.5.2.4.0.0 = STRING: PEM 3
SNMPv2-SMI::enterprises.2636.3.1.13.1.5.4.1.0.0 = STRING: Top Fan Tray
SNMPv2-SMI::enterprises.2636.3.1.13.1.5.4.1.1.0 = STRING: Top Tray Fan 1
SNMPv2-SMI::enterprises.2636.3.1.13.1.5.4.1.2.0 = STRING: Top Tray Fan 2
SNMPv2-SMI::enterprises.2636.3.1.13.1.5.4.1.3.0 = STRING: Top Tray Fan 3
[...]
SNMPv2-SMI::enterprises.2636.3.1.13.1.5.7.10.0.0 = STRING: FPC: MPC 3D 16x 
10GE @ 9/*/*
[...]
SNMPv2-SMI::enterprises.2636.3.1.13.1.5.9.1.0.0 = STRING: Routing Engine 0
SNMPv2-SMI::enterprises.2636.3.1.13.1.5.9.2.0.0 = STRING: Routing Engine 1
[...]

So monitoring of Routing Engines CPU should be set up using following OIDs: 

.1.3.6.1.4.1.2636.3.1.13.1.8.9.1.0.0 (RE0)
.1.3.6.1.4.1.2636.3.1.13.1.8.9.2.0.0 (RE1)

and for FPC9 .1.3.6.1.4.1.2636.3.1.13.1.8.7.10.0.0 should be used.

 Is it raw throughput stats of an ASIC, or CPU time that is used for
 some FPC-level tasks by some utility processor (BFD? LACP? STP?
 J-Flow?).
 What happens when this value reaches 100% (card freeze, drops, LACP link 
 loss)?

The same answer: it depends [on CPU you're monitoring]. 

 Appreciate your help.
 
 Thanks
 Nick
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] bgp, attribute flags error...

[Alexandre Snarskii]

Hi!

Yesterday some BGP sessions with our clients started flapping with the 
following messages in logs: 

Jul 26 13:07:58.240  RT.LVI.UA rpd[1472]: bgp_read_v4_message:9945: 
  NOTIFICATION received from client's ip (External AS client's AS): 
  code 3 (Update Message Error) subcode 4 (attribute flags error), 
  Data:  c8 07 08 00 00 c0

Well, c8 in Data: is clearly 'not too correct', '8' is the 'lower-order
bits' with one bit set to one, while RFC clearly says that They MUST be
zero when sent: 

The lower-order four bits of the Attribute Flags octet are unused.  
They MUST be zero when sent and MUST be ignored when received.

but looks like JunOS sends flags byte just as received, without 
re-generating or zeroizing, and customer's software (openbgpd)
is a bit buggy and does not ignores these bits but resets session
instead[1]. 

Right now I had to shut down peering with neighbor sending these
prefixes, but may be there are other workarounds ? 

[1] bgpd/rde.c CHECK_FLAGS macro should be redefined as 
(((s  0xf0)  ~(ATTR_EXTLEN | (m))) == (t))
instead of just 
(((s)  ~(ATTR_EXTLEN | (m))) == (t))

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] General BGP question, single asn multi location

[Alexandre Snarskii]

On Wed, Jul 25, 2012 at 10:41:56AM +0200, Daniel Roesen wrote:
 On Wed, Jul 25, 2012 at 01:32:50AM -0700, Morgan McLean wrote:
  So I have a single ASN and two sites that do not peer directly with each
  other, but have eBGP with providers.
  
  Site A takes full routes, advertises a /24
  Site B takes defaults only, advertises a /24
  
  I notice I do not get the route advertised at site B by any of my providers
  at site A. Is this due to a general misconfiguration of BGP? Are they not
  sending me routes from my own ASN?
 
 You're hitting BGP loop prevention by means of AS_PATH.
 
 Solution:
 http://www.juniper.net/techpubs/en_US/junos11.4/topics/reference/configuration-statement/loops-edit-protocols-bgp-family.html
 
 loops 2 is your friend.

and one more point - the same loop prevention technique may be employed
at your provider's routers (juniper by default does not announce routes
learned from ASn to the peers in the same ASn). 

Solution: 

http://www.juniper.net/techpubs/software/junos/junos94/swconfig-routing/disabling-suppression-of-route-advertisements.html

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Woot. Updated MX software recommendation

[Alexandre Snarskii]

On Wed, Apr 11, 2012 at 02:05:52PM +, OBrien, Will wrote:
 I got on TAC about the fact that they were recommending 10.4 code 
 for the MX when it doesn't support the Enhanced SCB at all.
 I don't know if it was my case or just enough people giving them a 
 hard time, but they notified me that they've updated KB21476.
 
 There is now an entry for the MX series and the MX series with the 
 Enhanced SCB. (11.2R5.4 at this time.)

11.4R2.14 this article says to me :) 

PS: to whom it may concern: SNMP counters in 11.4R2 broken even worse 
than in 11.4R1. Looks like the same PR/731833, 
http://puck.nether.net/pipermail/juniper-nsp/2012-February/022369.html

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Resource Temporarily Unavailable - Juniper MX

[Alexandre Snarskii]

On Mon, Dec 05, 2011 at 07:48:22AM -0500, Paul Stewart wrote:
 Can anyone shed some light on these log messages?
 
  
 
 Nov 30 04:48:21  core2.toronto1 rpd[1359]: bgp_send: sending 19 bytes to
 xx.xxx.52.50 (External AS x) blocked (no spooling requested): Resource
 temporarily unavailable
 
 We get these every so often .. Presuming it has to due with load on the
 system for a short period of time?

More possibly it's caused by remote system load (or link congestion
or whatever other reason for remote system not able to receive updates
fast enough). Then, when socket buffer is full with unacknowledged data,
your system tries to send another update/keepalive message and it 
results in write(2) syscall returning EAGAIN error (actually, not
an error, just and indication of 'no data sent, try again later'),
which translates to Resource temporarily unavailable message. 

 
 Platform is Juniper MX boxes running 10.0R3.10
 
  
 
 Thanks,
 
  
 
 Paul
 
  
 
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] JUNOS and 128.0.0.0 martian (JFYI)

[Alexandre Snarskii]

On Wed, Oct 12, 2011 at 11:59:14AM +0400, Tima Maryin wrote:
 
 RIPE NCC was awared about this issue and now reallocate blocks to those 
 who got addrs from 128.0.0.0/16

One more update on this topic: RIPE started debogonisation for
128.0.0.0/16, so it looks like this network will be allocated
again in the future: 

route:   128.0.0.0/21
descr:   RIPE-NCC-RIS debogon prefix
origin:  AS12654
pingable:128.0.0.1

I hope all networks will implement advice from PSN-2011-10-393
before this happens. 

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX series - LACP flapping during ethernet storm.

[Alexandre Snarskii]

On Thu, Oct 20, 2011 at 10:05:58PM +0800, Mark Tinka wrote:
 On Thursday, October 20, 2011 09:18:06 PM Chuck Anderson 
 wrote:
 
  Not true according to these:
 
 Not according to what we actually saw in the field.
 
 We configured LAG's with LACP and our EX4200 couldn't load 
 balance any of the traffic.

My experience significantly differs here. 

Well, there are scenarios when load-balancing will not happen
(for example, if LAG carries point-to-point link between routers,
and traffic is MPLS-encapsulated), but this is expected behaviour
(S/D mac's are always the same in this case, and that's the
only option for non-ip traffic on EX series).

On the other hand, for generic ip traffic (consisting of many parallel 
flows) balancing is good enough: 

Physical interface: ge-0/0/2, Enabled, Physical link is Up
  Output rate: 534986336 bps (65259 pps)
Protocol aenet, AE bundle: ae1.0
Physical interface: ge-0/0/3, Enabled, Physical link is Up
  Output rate: 520550560 bps (65363 pps)
Protocol aenet, AE bundle: ae1.0

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] JUNOS 10.4S6 for EX8200 - PR/676826

[Alexandre Snarskii]

On Thu, Sep 01, 2011 at 11:48:36AM -0400, Paul Stewart wrote:
 Actually I'm curious as well - RAS is not typically wrong though about this
 kind of stuff ;)

Someday he explained his setup here: 

http://puck.nether.net/pipermail/juniper-nsp/2010-February/015599.html

and, i think, running bgp [over] ipsec with multiple uplinks over 
different media is just not that typical use case for srx-210 :) 

Fortunately, all use cases I know about are much simplier than RAS's 
basement (at least all cases are ethernet-only), and, while there were 
some glitches at early stages, no serious complaints here too. 

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] policers on LAG

[Alexandre Snarskii]

On Thu, Apr 07, 2011 at 08:40:59PM +0400, Pavel Lunin wrote:
 
 Hi all,
 
 Anyone here uses policers on LAGs with member interfaces, bound to 
 different PFE? MX Trio in my case, but same for i-chip would also be 
 interesting.
 
 There is some rumor that in such a case policer rate is individually 
 applied several times to each of the member interfaces meaning actual 
 rate for the whole LAG depends on no-one knows what.

Rule of thumb: policing is done on a chip closest to customer,
and if a link to customer terminated on more than one chip (like in your 
case - multichip LAG) - policing will be performed on every chip 
separately without any knowledge on how many traffic to this customer
already came through other chips. Well, with normal IMIX this means
that if you have two interfaces in LAG your customer theoretically
can get up to 2x configured policer rate, if you have four interfaces 
in LAG - up to 4x and so on.

PS: those observations were done on older M320 and I-chip based
MX-series. Do not have Trio-based devices, so may be I'm wrong here.
Still do not believe that intrachip communications were introduced
to aid exact policing anyway.

 Too many things get broken in my mind, if this assumption is correct. 
 Please, tell me it's wrong )

It's absolutely normal :(

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] ex4200 vc and jumbo frames ?

[Alexandre Snarskii]

Hi!

I'm facing a strange limitation on ex-4200 virtual-chassis: 
vcp-interfaces are configured with mtu 1500: 

s...@vsw02# run show interfaces vcp-0   
Physical interface: vcp-0, Enabled, Physical link is Up
  Type: 105, Link-level type: 70, MTU: 1514, Speed: 32000mbps

and not reconfigureable to use jumbo frames: 

s...@vsw02# show | compare 
[edit interfaces]
+   vcp-0 {
+   mtu 9216;
+   }
s...@vsw02# commit check 
[edit interfaces]
  'vcp-0'
 Interface is not user configurable
error: configuration check-out failed

As a result, hosts within the same vlan but connected to different
VC members is not able to reach each other with big packets :( 

Are there any way to overcome this limitation ? 

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ex4200 vc and jumbo frames ?

[Alexandre Snarskii]

On Tue, Dec 28, 2010 at 04:14:10PM +0300, Alexandre Snarskii wrote:
 
 Hi!
 
 I'm facing a strange limitation on ex-4200 virtual-chassis: 
 vcp-interfaces are configured with mtu 1500: 

False alert. Colleague messed up with interface names :( 
After setting correct mtu on edge ports everything works fine, 
so looks like actual MTU on vcp interfaces is at least 9216. 

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4200: VC incremental upgrade ?

[Alexandre Snarskii]

On Mon, Oct 25, 2010 at 03:31:47PM +0200, Philipp Geschke wrote:
 On Mon, 25 Oct 2010 17:10:46 +0400, Alexandre Snarskii s...@snar.spb.ru
 wrote:
  Hi!
  
  Silly question: is it possible to perform incremental upgrade
  on ex-series virtual-chassis ? I.e., upgrade some switches
  (using 'request system software add member NN'), switchover
  master to 'upgraded' part, then upgrade remaining switches ? 
 
 no, that is currently not possible.
 You can always take single switches out of the stack and upgrade them
 outside of the stack, however, a hitless upgrade is not really possible.

Looks like it is possible. In progress of building new virtual-chassises
I found that one of VC's periodically flapped (pfem coredumps with 
corresponding interface flaps) right after commits.
Investigation shown that it was because of version mismatch 
on one of stack members: 

s...@vsw02# run show version | match Base OS boot|fpc
fpc0:
--
JUNOS Base OS boot [10.3R2.11]
fpc1:
--
JUNOS Base OS boot [10.3R2.11]
fpc2:
--
JUNOS Base OS boot [10.3R2.11]
fpc3:
--
JUNOS Base OS boot [10.3R2.11]
fpc4:
--
JUNOS Base OS boot [10.3R1.9]

and after upgrading JunOS on fpc4 to match others I see no more
errors. However, the fact that 10.3R1 switch was able to join 10.3R2
virtual-chassis leads me to interesting conclusion - looks like
incremental upgrade within the same major version, like 10.3R1 to 
10.3R2 to 10.3R3 is possible, while upgrade from 10.3 to 10.4 is not. 
And, of course, there must be no configuration changes during upgrade.

PS: or it is well-known bug to be fixed in some next release ? 

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Strange behavior of BGP policy

[Alexandre Snarskii]

On Tue, Nov 09, 2010 at 12:18:37PM +0200, Alexander Shikoff wrote:
 
 Filtering of outgoing prefixes is performed via to-MHost policy:
 minot...@br1-gdr.ki# show policy-options policy-statement to-MHost 
 term Default {
 from {
 route-filter 0.0.0.0/0 exact;
 }
 then reject;
 }
 term Itself {
 from {
 protocol static;
 route-filter 178.214.192.0/19 exact;
 }
 then accept;
 }
 then accept;
 
 
 As you can see only route 178.214.192.0/19 from static routes should be 
 redistributed into BGP, but I see another routes (direct, static, OSPF) 
 also being redistributed:

Because other direct/static/ospf routes match final 'then accept' statement.
You may either just change 'then accept' to 'then reject', or, if
you need to provide full-view to your customer, rewrite final term as

 term transit { 
from protocol bgp;
then accept;
 }
 then reject;

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] EX4200: VC incremental upgrade ?

[Alexandre Snarskii]

Hi!

Silly question: is it possible to perform incremental upgrade
on ex-series virtual-chassis ? I.e., upgrade some switches
(using 'request system software add member NN'), switchover
master to 'upgraded' part, then upgrade remaining switches ? 

Juniper documentation is not so clear on this topic - on one hand we 
have command that allows upgrade of selected chassis member and KB10840 
suggests that Virtual Chassis software can be upgraded for the entire VC 
or you can upgrade one individual member of the VC, on other - KB16756 
suggests that for a standalone EX4200 switch to join an existing Virtual 
Chassis configuration, it had to be running the same version of software 
that was running on the Virtual Chassis master and that since 10.0 master 
switch has ability to ability to automatically update the software on a new 
member switch so that it can join the Virtual Chassis configuration
(i.e., in this application fresh upgraded switch will be automatically
downgraded back to the version master running).

Or am I missing something ? 

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MPLSoMPLS - horrible?

[Alexandre Snarskii]

On Thu, Sep 30, 2010 at 05:52:56PM +1000, Dale Shaw wrote:
 Hi all,
 
 I'm pondering my first production use of MPLS and I'm looking for some
 free advice.
 
 I'm looking at building a new 'enterprise' network - an extranet of
 sorts - *on top of* a NSP's L3VPN service. It's all Ethernet. I'd like
 to be able to build my own pseudowires and create my own L3VPNs on top
 of the NSP's platform and without their involvement. In effect, my CE
 routers (from the NSP's perspective) become PE routers to *my*
 customers (3rd parties, e.g. business partners and suppliers).

It's called CsC - Carrier Supporting Carrier, and this technique is
known for years. 
 
 I suppose this means doing MPLSoMPLS, and actually depending on the
 upper layers in the protocol stack, it could end up looking pretty
 scary if you looked at what was being shifted around in the NSP's core
 :-)  (over and above MPLS, I'm thinking about how the stack looks when
 further encapsulation, such as IPSec, is used.)
 
 So, noting the protocol stack size and potential MTU issues, is anyone
 doing this? How are you distributing labels?

Right question would be 'How do you exchange labels with your NSP?'.
Because if there are no such exchange your NSP will not know what to 
do with MPLS packet entering his network and will just drop it at 
ingress. 
 
 Is it too horrible to even contemplate?

It's hardly possible without setting CsC with your NSP. 

With L3VPN all you have is IP[v6] connectivity between your CE routers,
so the only way to run MPLS without NSP support is to run GRE tunnels
between your CE's and then run MPLS over these GRE tunnels. And, yes,
it is horrible: ethernet frame passing your pseudowire will become
ethernet over MPLS over GRE over IP over MPLS over ethernet with terrific 
overhead and lots of MTU issues :) 

 I'd be looking at using J and/or SRX as the CE-pseudo-PE devices.
 
 Any pointers would be appreciated. I've only just embarked on this
 little adventure and I'm still relative new to Juniper platforms.
 
 Cheers,
 Dale
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Inter provider LDP based L2VPN between a Juniper network and a Cisco network

[Alexandre Snarskii]

On Wed, Jul 28, 2010 at 11:10:12PM +0300, Amos Rosenboim wrote:
 Hello All,
 
 I'm trying to configure an inter provider LDP based L2VPN between a  
 Juniper network and a Cisco network.
 The topology is roughly as follows:
 
 Cisco PE-Cisco P--Cisco P--Cisco ASBR--Juniper  
 ASBR---Juniper P---Juniper P---Juniper PE.
 
 In order to achieve this I need to establish the tunnel LSP between  
 the PEs in both networks and than establish the LDP signaled VC on top  
 of the tunnel LSP.
 To establish the tunnel LSP the two ASBRs exchange IPv4+label (or  
 labeled unicast in Junos language ) routes between them and advertise  
 to each other the loopback IP of the PEs.
 On the Cisco ASBR we simply redistribute the Juniper PE loopback into  
 the igp and thus the PE has both a route and a label to reach the  
 Juniper PE
 However on the Juniper side I cannot do the same.
 My question is what is the alternative method to achieve the same  
 result on the Juniper side?
 The solution I can think of is to use labeled unicast routes over iBGP  
 between the Juniper ASBR and the Juniper PE but I'm not sure it will  
 work (the Juniper network is not under my control so I cannot test).

At my past work we did inter-AS l2circuits exactly that way - eBGP with 
labeled-unicast between AS (one ASBR is Juniper, other is Cisco), 
then iBGP with labeled-unicast inside. 
Works fine. 

One of reasons of not to redistribute eBGP into OSPF is a lots of 
horror stories on what happens when you're entering 
router ospf  
 no redistrubute bgp route-map LOOPBACKS-TO-BE-REDISTRIBUTED
on Cisco routers. 

 If this is the solution than should the Juniper P routers also get  
 this route or would the Juniper PE impose two labels for the address  
 of the Cisco PE (the label derived from BGP for the Cisco PE + the  
 label to reach the Juniper ASBR)

IIRC, ingress PE will have to push three labels - internal label
to reach ASBR, then label to PE and then l2circuit label. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] CFEB restart due to incorrect temperature reading ?

[Alexandre Snarskii]

Hi!

Some days ago one of our M10i's CFEB restarted with strange diagnostics - 
in the same second when BFD sessions get down there were following
line in chassisd log: 

Jul  2 14:03:08 CFEB 0 temperature is -60 degrees C, which is outside operating 
range

(not sure if it appeared before or after BFD failures though, 
these lines found in different log files. BFD messages timestamped
as 14:03:08.695, and no messages logged to remote syslog server since
14:01, so it's quite possible that CFEB failed first). 

Then there are lots of messages about CFEB not running/FPC restarts
and so on messages, ends with CFEB restart and finally everything
stabilised: 


Jul  2 14:03:12.663 2010  alarmd[1278]: Alarm set: CFEB color=RED, 
class=CHASSIS, reason=CFEB not online, the box is not forwarding
Jul  2 14:03:12.672 2010  /kernel: rdp keepalive expired, connection dropped - 
src 0x0001:1021 dest 0x0002:2048
Jul  2 14:03:12.663 2010  chassisd[1277]: CHASSISD_SHUTDOWN_NOTICE: Shutdown 
reason: CFEB connection lost
Jul  2 14:03:12.669 2010  craftd[1279]:  Major alarm set, CFEB not online, the 
box is not forwarding

There are no coredumps and no logs about reason of restart, 
just power-on notice in internal CFEB log: 

[0+00:00:00.255 LOG: Info] CSBR: Reset reason (0x4): Power On
[0+00:00:00.255 LOG: Info] On-board NVRAM contains diagnostic information.

and last logs in NVRAM is just 

CSBR: Reset reason (0x4): Power On

Routing engine was not reset during this failure, and temperature 
readings shows just normal datacenter temperature of 22C/71F...

Any ideas on what had happened ? 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4200 MPLS Label Stacks

[Alexandre Snarskii]

On Tue, Jun 08, 2010 at 07:25:47AM +0100, Matthew Walster wrote:
 I'm aware that the Juniper EX4200 can do MPLS - indeed, I've used it
 with RSVP signalled LSPs using CCC encapsulation. It's been made clear
 to me that the EX series can only operate on 1 label, which completely
 rules out most MPLS scenarios such as Fast Reroute, Martini/Kompella
 L2VPNs, VPLS etc, leaving it just with the CCC capabilities, with
 extreme loose possibilities of LDP support in the distant future.
 
 What I'm interested in is if the EX4200 can be used as a P router,
 just for RSVP LSPs, regardless of how many labels there are. That is,
 if an MPLS encapsulated packet comes in with two labels, providing the
 operation RSVP calls for is only a swap on the outer label, will that
 work? Presumably as the inner labels are not touched/inspected except
 for the L2 checksum, so it *should* work?

Theoretically, yes, it should. But last time I checked it (9.5R1
or some, first version with MPLS support), label swap operation 
was completely broken: when packet with two labels arrives to switch 
and top label should be swapped leaving other labels untouched, 
switch swapped all the label stack to the single label instead: 

ingress packet: 

16:45:51.826995 00:23:9c:7d:fa:03  00:23:9c:03:57:c2, ethertype MPLS unicast
(0x8847), length 124: MPLS (label 299808, exp 0, ttl 255)
(label 114576, exp 0, [S], ttl 255)

operation: 

s...@sw0001 show route table mpls.0 label 299808 extensive
[...]
Next hop: XX.XXX.XXX.XXX via ge-0/0/1.0 weight 0x1, selected
Label-switched-path N-NNN
Label operation: Swap 102080

egress packet: 

16:45:51.827002 00:23:9c:03:57:c1  00:19:e2:45:e3:82, ethertype MPLS unicast
 (0x8847), length 120: MPLS (label 102080, exp 0, [S], ttl 64)

Juniper confirmed that it is hardware limitation.

 The scenario I'm envisioning is that the two XFP slots can act as a
 pass-through and the 48 ports act as an MPLS CCC injector at a POP,
 saving the necessity to use large amounts of rack space and cash on
 MX80/240s when the EX4200 should cope.

I was interested in the same scenario. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] XNM Reverse DNS lookup

[Alexandre Snarskii]

On Fri, May 07, 2010 at 02:33:10PM +0200, Thomas Eichhorn wrote:
 Hi all,
 
 I currently run into the next problem with xnm, maybe
 you have an idea:
 
 If I do a login via xnm, the login takes about 30 secs - which is a
 little bit long.
 
 My idea behind this is, that the router tries to do a reverse lookup
 of the connecting ip.
 
 This fails/runs into an timeout because the router uses the nearest-by
 nameserver, but the xnm connect comes from a RFC1918 IP on the
 management interface - the nameserver usually don't know about
 this and tries to resolve it - up to a timeout.
 
 Do you have any idea howto disable reverse lookups on the router?

set system static-host-mapping xnm-hostname inet rfc1918 address ? 
 
 I have no problem to do it globally - but I do not want to remove
 the nameservers completely..
 
 Thanks for you help,
 Tom
 ___
 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] ex-series and RSPAN ?

[Alexandre Snarskii]

On Fri, Feb 12, 2010 at 04:29:30PM +0300, Alexandre Snarskii wrote:
 
 In my case, i'm trying to configure remote span, with output set to vlan: 
 
 s...@us-smf-csw02 show configuration ethernet-switching-options analyzer 
 Analyzer2 
 loss-priority high;
 input {
 ingress {
 interface ge-0/0/12.0;
 interface ge-0/0/13.0;
 interface ge-0/0/14.0;
 interface ge-0/0/16.0;
 interface ge-0/0/17.0;
 interface ge-0/0/19.0;
 }
 }
 output {
 vlan {
 Analyzer2;
 }
 }
 
 And it seems that my problem may be related to the fact that
 this vlan exits this switch and enters next one via aggregated 
 ethernet: 

Just to confirm this idea: 10.0R3 refuses this configuration with 
the following error: 

s...@us-smf-csw02# commit check 
[edit ethernet-switching-options]
  'analyzer'
Aggregated interface ae2.0 cannot be configured as a member of Analyzer 
output VLAN Analyzer2
error: configuration check-out failed

 
 s...@us-smf-csw02 show vlans Analyzer2 extensive 
 VLAN: Analyzer2, Created at: Fri Feb 12 02:46:45 2010
 802.1Q Tag: 999, Internal index: 18, Admin State: Enabled, Origin: Static
 Protocol: Port Mode
 Number of interfaces: Tagged 1 (Active = 1), Untagged  0 (Active = 0)
   ae2.0*, tagged, trunk
 
 Will check next week.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] M10i, 10.0R3: IQ2E PIC not initialized correctly.

[Alexandre Snarskii]

Hi!

During upgrade of one of our M10i's to 10.0R3 IQ2E PIC refused
to start at boot time: 

chassisd[1277]: %DAEMON-3-CHASSISD_PIC_CMD_TIMEOUT: pic_ready_timer_expired: 
 attempt to bring PIC 0 in FPC 1 online timed out
cfeb CM: %PFE-6: Bouncing PIC 1/0 for reconfiguration 

Reboot did not helped (with the same logs) however after manual
issuing 'request chassis pic ... online' PIC came up. 

Other modules (IQ2-nonE and plain GE) came up correctly both times.

Anyone seen this (or like) behaviour ? Wandering what may be a
cause - some software bug, badly seated PIC, something else ? 

PS: log excerpts: 

initialization timout: 

18:47:17 (FPC Slot 1, PIC Slot 0) cosman_fpc_init: %PFE-6: FC based rewrite is 
OFF for fpc 
18:47:18 (FPC Slot 1, PIC Slot 0) PFEMAN: %PFE-6: server_addr 0x8001 
soft_restart 1 
18:47:18 (FPC Slot 1, PIC Slot 0) Version 10.0R3.10 by builder on 2010-04-16 
07:05:06 UTC 
18:48:18 chassisd[1277]: %DAEMON-3-CHASSISD_PIC_CMD_TIMEOUT: 
pic_ready_timer_expired: attempt to bring PIC 0 in FPC 1 online timed out
18:48:18 cfeb CM: %PFE-6: Bouncing PIC 1/0 for reconfiguration 
18:48:18 chassisd[1277]: %DAEMON-5-CHASSISD_IFDEV_DETACH_PIC: 
ifdev_detach_pic(1/0)

normal startup: 

18:48:51 (FPC Slot 1, PIC Slot 0) cosman_fpc_init: %PFE-6: FC based rewrite is 
OFF for fpc 
18:48:52 (FPC Slot 1, PIC Slot 0) PFEMAN: %PFE-6: server_addr 0x8001 
soft_restart 1 
18:48:52 (FPC Slot 1, PIC Slot 0) Version 10.0R3.10 by builder on 2010-04-16 
07:05:06 UTC 
18:48:52 (FPC Slot 1, PIC Slot 0) SNTP: %PFE-7: Daemon created 
18:48:53 (FPC Slot 1, PIC Slot 0) PFEMAN: %PFE-6: Session manager active 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] In-service security upgrade ?

[Alexandre Snarskii]

Hi!

Yesterday there were some security-related technical bulletins
published by Juniper. Well, I like that some bugs were fixed,
but I personally hate the idea that I have to reboot routers and
switches to fix bug in ntpd (for example). 

That's why this question arises: did anyone tried the hard way
of upgrading one device, taking fixed ntpd (or whatever) from it 
and distributing it over all other devices without having to reboot 
them ? Or software signatures will prevent code compiled for some 
specific version to run on other version ? Even in minor version 
change cases like 9.3Ssmth code vs. 9.3Rsmth kernel ? 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] ex-series and ifOutDiscards ?

[Alexandre Snarskii]

Hi!

Another story about ex-series and counters: packets that is 
dropped due to lack of buffer space is not reported neither
in Output errors nor as ifOutDiscards: 

s...@us-sjc-csw01 show interfaces ge-0/0/3 extensive 
Physical interface: ge-0/0/3, Enabled, Physical link is Up
[...]
  Statistics last cleared: 2010-03-24 01:29:02 PDT (1w5d 02:53 ago)
[...]
  Output errors:
Carrier transitions: 0, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 
0, FIFO errors: 0, HS link CRC errors: 0,
MTU errors: 0, Resource errors: 0
  Queue counters:   Queued packets  Transmitted packets  Dropped packets
0 best-effort0363320017 2131

s...@us-sjc-csw01 show snmp mib walk .1.3.6.1.2.1.2.2.1 | match 140 
ifIndex.140   = 140
ifDescr.140   = ge-0/0/3
[...]
ifOutOctets.140 = 2774285894
ifOutOctets.144 = 1407151110
ifOutUcastPkts.140 = 2951634080
ifOutNUcastPkts.140 = 523582805
ifOutDiscards.140 = 0
ifOutErrors.140 = 0
ifOutQLen.140 = 0

That's from EX-3200 running 9.3R4.4, the same error still present in 9.3S7.2.

Does anybody knows if it fixed in more recent JunOS ? 

PS: JTAC-EX is not able to answer this question for a three weeks
(#2010-0314-00NN). 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX 8200 deployment

[Alexandre Snarskii]

On Mon, Mar 22, 2010 at 02:16:36PM -0500, Richard A Steenbergen wrote:
 On Mon, Mar 22, 2010 at 05:31:38PM +0300, Alexandre Snarskii wrote:
  I suppose you can use good old hairpin cable trick to have both
  egress policers (converted to ingress ones on switched side of
  hairpin) and counters on Vlan's (actually on subinterfaces on routed
  side).  Not checked with ex-82xx, but it works for ex-[34]200.
 
 I'm trying to picture the exact configuration you're talking about, but
 I'm not sure I get it. If you hairpined a trunk port, wouldn't you still
 have to configure the layer 2 vlans on the other side to do anything
 with them, and wouldn't they then be the same vlans as the originals? 

EX-series (at least [34]200) has the same local vlan significance 
principle that applies, for example, to OSM-equipped 6500/Sup2: 
you can create chassis-wide vlan, and it will be used on all LAN 
cards, but you still can reuse the same vlan id on OSM subinterface, 
and the idea is actually stolen from some old recipe on how to run 
6500/sup2 Vlan as a part of VRF. 
In case of ex-series it's even better - there are no 'internal vlan'
allocation that happens in case of 65xx/76xx. 

 Or were you saying that when you do a subinterface style it doesn't 
 actually use the vlan chassis-wide like it would if you did this 
 subinterface style config on a 6509 for example, and you were 
 proposing this:

Yes, you got the idea. 

 interface xe-1/0/0 {
 vlan-tagging;
 unit 101 {
 vlan-id 101;
 family inet {
 address 1.2.3.4/24;
 }
 }
 }
 
 interface xe-2/0/0 {
 unit 0 {
 family ethernet-switching {
 port-mode trunk;
 vlan {
 members VLAN101;
 }
 }
 }
 }
 
 vlans {
 VLAN101 {
 vlan-id 101;
 }
 }
 
 With a hairpin between xe-1/0/0 and xe-2/0/0, and then you could use 
 VLAN101 in whatever other configuration you wanted while still using 
 xe-1/0/0.101 for the counting?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] mysterious microbursts ?

[Alexandre Snarskii]

On Sun, Mar 14, 2010 at 01:18:39PM +, chrisccnpsp...@gmail.com wrote:
 One thing I would check for first is unicast flooding.  It sounds like 
 the backup router is flooding all traffic as it doesn't have any arp/mac 
 tables created for traffic that comes ingress to it. Would be hard to 
 pinpoint the issue unless you can provide some traffic flow stats. 
 
 Unicast flooding is a common problem with active/backup switching 
 environments. If this is the case we can work on modifying the mac 
 and arp timers to resolve it. 
 
 Hope this helps

Thanks, you described my problem mostly exactly, with the only 
difference: actually my backup router had correct arp table, with 
default arp aging-time of 20min, but mac-table-aging-time on second 
core switch was (by default) just 300sec, so in five minutes after 
backup router passive-learned some arp entry switch had to flood traffic 
in unknown-unicast mode, thus affecting only ports on even access-switches.

Thanks again. 

 Sent via BlackBerry by ATT
 
 -Original Message-
 From: Alexandre Snarskii s...@snar.spb.ru
 Date: Sun, 14 Mar 2010 14:25:49 
 To: Juniper-NSP Mailing listjuniper-nsp@puck.nether.net
 Subject: [j-nsp] mysterious microbursts ?
 
 
 Hi!
 
 During routine maintenance on my ex-3200 switches I found that 
 some devices, connected with 100mbit/full-duplex observe minor
 packet loss. Well, there is nothing too unexpected, you can 
 see it mostly every time when traffic enters switch using 1ge (2x1ge
 aggregate in my case) link and exits using 100mbit, switch ports
 just do not have enough buffer space to handle bursts well, but... 
 That's where the strangeness begins: 
 a) these 100mbit ports used to connect VoIP devices handling RTP 
 traffic, so there should be no bursts at all.
 b) there are more than 30 such devices in my network, and I see 
 that loss only on half of them - on that half that is connected 
 to even-numbered switches, there are no packet loss on devices 
 connected to odd-numbered ones.
 
 Logical topology is just a vlan connected to a router (two routers
 in VRRP master/slave scenario), physical is classic ring (some rings 
 actually, each odd-numbered access switch connected to coresw1, 
 even-numbered - to coresw2): 
 
   router1  router2(backup, no traffic right now)
 ||
   coresw1  coresw2
 ||
 ||
   accsw1  x -- accsw2
 
 link between core switches is 10ge, links core-access and access-access
 is 2x ge aggregated ethernet, access-access links are blocked by STP. 
 Switches is ex3200-24t(core) and ex3200-48t(access), running 9.3R4.4.
 
 Well, these losses is about 0.1% and I can live with that, but
 I'd like to have any idea on why it happens only on half of 
 devices, and I don't have one :( 
 Any clue ? 
 
 Example interface with errors: 
 
 Physical interface: ge-0/0/26, Enabled, Physical link is Up
   Interface index: 165, SNMP ifIndex: 174, Generation: 168
   Link-level type: Ethernet, MTU: 1514, Speed: 100mbps, Duplex: Full-Duplex, 
 MAC-REWRITE Error: None,
   Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, 
 Auto-negotiation: Disabled,
   Remote fault: Online
   Device flags   : Present Running
   Interface flags: SNMP-Traps Internal: 0x0
   Link flags : None
   CoS queues : 8 supported, 8 maximum usable queues
   Hold-times : Up 0 ms, Down 0 ms
   Current address: 00:19:e2:53:66:9a, Hardware address: 00:19:e2:53:66:9a
   Last flapped   : 2010-03-05 04:36:34 PST (1w1d 22:21 ago)
   Statistics last cleared: 2010-03-11 06:44:54 PST (2d 20:13 ago)
   Traffic statistics:
Input  bytes  :  883122567900 bps
Output bytes  :  88616684644 5984 bps
Input  packets:4437977020 pps
Output packets:412072442   10 pps
IPv6 transit statistics:
 Input  bytes  :   0 
 Output bytes  :   0
 Input  packets:   0
 Output packets:   0
   Input errors:
 Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0, L3 
 incompletes: 0, L2 channel errors: 0,
 L2 mismatch timeouts: 0, FIFO errors: 0, Resource errors: 0
   Output errors:
 Carrier transitions: 0, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 
 0, FIFO errors: 0, HS link CRC errors: 0,
 MTU errors: 0, Resource errors: 0
   Egress queues: 8 supported, 4 in use
   Queue counters:   Queued packets  Transmitted packets  Dropped 
 packets
 0 best-effort0411934501   
 454642
 
 1 assured-forw   00   
  0
 5 expedited-fo   00   
  0

[j-nsp] mysterious microbursts ?

[Alexandre Snarskii]

Hi!

During routine maintenance on my ex-3200 switches I found that 
some devices, connected with 100mbit/full-duplex observe minor
packet loss. Well, there is nothing too unexpected, you can 
see it mostly every time when traffic enters switch using 1ge (2x1ge
aggregate in my case) link and exits using 100mbit, switch ports
just do not have enough buffer space to handle bursts well, but... 
That's where the strangeness begins: 
a) these 100mbit ports used to connect VoIP devices handling RTP 
traffic, so there should be no bursts at all.
b) there are more than 30 such devices in my network, and I see 
that loss only on half of them - on that half that is connected 
to even-numbered switches, there are no packet loss on devices 
connected to odd-numbered ones.

Logical topology is just a vlan connected to a router (two routers
in VRRP master/slave scenario), physical is classic ring (some rings 
actually, each odd-numbered access switch connected to coresw1, 
even-numbered - to coresw2): 

  router1  router2(backup, no traffic right now)
||
  coresw1  coresw2
||
||
  accsw1  x -- accsw2

link between core switches is 10ge, links core-access and access-access
is 2x ge aggregated ethernet, access-access links are blocked by STP. 
Switches is ex3200-24t(core) and ex3200-48t(access), running 9.3R4.4.

Well, these losses is about 0.1% and I can live with that, but
I'd like to have any idea on why it happens only on half of 
devices, and I don't have one :( 
Any clue ? 

Example interface with errors: 

Physical interface: ge-0/0/26, Enabled, Physical link is Up
  Interface index: 165, SNMP ifIndex: 174, Generation: 168
  Link-level type: Ethernet, MTU: 1514, Speed: 100mbps, Duplex: Full-Duplex, 
MAC-REWRITE Error: None,
  Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, 
Auto-negotiation: Disabled,
  Remote fault: Online
  Device flags   : Present Running
  Interface flags: SNMP-Traps Internal: 0x0
  Link flags : None
  CoS queues : 8 supported, 8 maximum usable queues
  Hold-times : Up 0 ms, Down 0 ms
  Current address: 00:19:e2:53:66:9a, Hardware address: 00:19:e2:53:66:9a
  Last flapped   : 2010-03-05 04:36:34 PST (1w1d 22:21 ago)
  Statistics last cleared: 2010-03-11 06:44:54 PST (2d 20:13 ago)
  Traffic statistics:
   Input  bytes  :  883122567900 bps
   Output bytes  :  88616684644 5984 bps
   Input  packets:4437977020 pps
   Output packets:412072442   10 pps
   IPv6 transit statistics:
Input  bytes  :   0 
Output bytes  :   0
Input  packets:   0
Output packets:   0
  Input errors:
Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0, L3 
incompletes: 0, L2 channel errors: 0,
L2 mismatch timeouts: 0, FIFO errors: 0, Resource errors: 0
  Output errors:
Carrier transitions: 0, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 
0, FIFO errors: 0, HS link CRC errors: 0,
MTU errors: 0, Resource errors: 0
  Egress queues: 8 supported, 4 in use
  Queue counters:   Queued packets  Transmitted packets  Dropped packets
0 best-effort0411934501   454642

1 assured-forw   000
5 expedited-fo   000
7 network-cont   0   1373360
  Active alarms  : None
  Active defects : None
  MAC statistics:  Receive Transmit
Total octets   88312256790  88616684644
Total packets443797702412072442
Unicast packets  443796941410096125
Broadcast packets  761   447035
Multicast packets0  1529282
CRC/Align errors 00
FIFO errors  00
MAC control frames   00
MAC pause frames 00
Oversized frames 0
Jabber frames0
Fragment frames  0
Code violations  0
  Autonegotiation information:
Negotiation status: Incomplete
  Packet Forwarding Engine configuration:
Destination slot: 0
Direction : Output 
CoS transmit queue   Bandwidth   Buffer Priority   
Limit
  %bps %   usec
0 best-effort95   9500  

Re: [j-nsp] EX-series automation, NETCONF woes

[Alexandre Snarskii]

On Wed, Jan 28, 2009 at 03:40:10PM -0500, Ross Vandegrift wrote:
 On Wed, Jan 28, 2009 at 11:17:11AM -0800, Derick Winkworth wrote:
  xpath notation can help you find junos-interface:interfaces no
  matter where its located.
 
 Can you do that without providing a map that maps the abbreviated
 namespace back to the fully-qualified namespace?  If so, I'd love to
 know how.

Just run into the same problem myself, and workaround is here:
you can use local-name() function to do namespace-agnostic 
searches, and you can use partial checks on namespaces to be
sure that you getting what you want. 

Example: iterate over physical interfaces:  

xsl:for-each select=//*[local-name()='physical-interface' and 
starts-with(namespace-uri(), 'http://xml.juniper.net/junos/')]

Select operational state: 

xsl:variable name=oper
select=normalize-space(*[local-name()='oper-status'])/

Select dropped packets for first queue: 


select=normalize-space(*[local-name()='queue-counters']/*[local-name()='queue' 
and 
*[local-name()='queue-number']=0]/*[local-name()='queue-counters-red-packets'])/


Syntax is ugly, but it works... 


 In my understanding, the XPath query .//junos-interface:interfaces [1]
 only matches
 http://xml.juniper.net/junos/9.3R2/junos-interface:interfaces if I
 can somewhere say that
 junos-interface = http://xml.juniper.net/junos/9.3R2/junos-interface;.
 
 That just moves the problem to one of making a namespace map.
 
 
 Ross
 
 [1] - that's the XPath to find the element named interfaces from the
 namespace that's been abbreviated junos-interface in any subtree.
 
 -- 
 Ross Vandegrift
 r...@kallisti.us
 
 If the fight gets hot, the songs get hotter.  If the going gets tough,
 the songs get tougher.
   --Woody Guthrie
 ___
 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] SSH PKA for system archival.

[Alexandre Snarskii]

On Tue, Feb 16, 2010 at 09:59:35PM -0600, Bill Marquette wrote:
  
  You can of course send syslog messages to syslog-ng and have syslog-ng
  call mail or a mail wrapper. I would prefer to have simple syslog
  messages (ie. log of some event or state) and then have additional
  functionality in parsing at a central location.
 
 Sure and we do, but I was trying to build a process that allowed my 
 SRX to push a diff of a given commit back to our ticketing system 
 (which already processes emails) rather than send an event offbox 
 that requires me to then somehow retrieve that change.  
 Yes, I'm aware I can transfer the files, but there are a couple 
 issues with that, the first being transfer-on-commit doesn't appear 
 to support alternate SSH ports, nor does it appear to support RSA 
 private keys, which puts this into an event script at best, the 

'system archival' uses bundled ssh, which, of course, supports
RSA/DSA private keys. Only thing you have to do to get this support
is to 'start shell user root' and then simply run 'ssh-keygen' :) 
Keys stored in ~root/.ssh/, and then following configuration works: 

archival {
configuration {
transfer-on-commit;
archive-sites {
scp://username@host/home/username/uploads;
}
}
}


Well, there is an issue with these keys on EX-series - during system
upgrade these keys got wiped and have either regenerated or restored 
from backup (if there is any known workaround - would like to hear). 
Not sure about SRX, though.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] ex-series and RSPAN ?

[Alexandre Snarskii]

Hi!

Does anybody know, is it works at all ? And if so, in what
version it fixed ? 
In my experiments (9.3S7.2) i do not see captured traffic at all,
and PR/309624 is still 'open'...

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Tunnel services on the DPCE-R-20GE-2XGE

[Alexandre Snarskii]

On Mon, Jan 04, 2010 at 12:31:38PM +0100, Tore Anderson wrote:
  fpc 0 {
  pic 1 {
  tunnel-services {
  bandwidth 1g;
  
  Interface will be: ip-0/1/10
 
 Interesting.  So you're still able to use all physical ports (ge-0/1/0
 through ge-0/1/9) as before;  you've actually oversubscribed the PFE by
 11:10?

No, as i-chip actually can handle 11Gbit no oversubscription is done. 

There is a wonderful article by Richard Steenbergen that explains a lot: 
http://puck.nether.net/pipermail/juniper-nsp/2009-February/012459.html

 That can't be done on the 10 GbE PFE, enabling tunnel services
 deactivates the physical port completely.  :-(

That is a known limitation. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] srx-210 ipsec performance ?

[Alexandre Snarskii]

Hi!

Specification says that SRX210 is able to do 75Mbit 
AES256+SHA-1/3DES+SHA-1 VPN performance, but I'd like to know, 
if anybody running them in production and is that number
is really can be achieved with IMIX traffic, or that is 
some marketing number, f.e., achievable only with large
frames ? 


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] flow-route questions.

[Alexandre Snarskii]

Hi!

While thinking about using RFC5575 (flow routes), i found at 
least some questions that i'm not able to answer.

a) RFC clearly states that 'flow routes must be validated' 
and describes validation procedure using destination-prefix 
attribute. But at the same time RFC does not enforce
destination-prefix attribute to be present in flow specifications,
and does not provide any detail on how to validate flow specifications
missing destination-prefix - i.e., should validation procedure
drop them all or should it accept all such flowspecs ? 
I suppose that as the latter case opens a too large security hole
(imagine customer that blackholes all google.com by setting only
source-address), JunOS implements former case at least on eBGP links, 
but that behaviour is not confirmed in documentation... 

b) As far as flow specs are the part of the same BGP session
as the usual inet-unicast routes - are they subject of the 
same import policy configured for peer/peer-group or the 
validation procedure is the only import policy for these NLRI ? 
If the former case is correct - are there any way to distinguish
inet-unicast and inet-flow NLRI ? (Why it's important for us: 
we're using prefix-filters to filter our client announces, 
and, as far as we should not require explicit route-object 
configured for any destination client may wish to filter - inet-unicast
routes should proceed filtered as usually, but for flowspec's
there is prefix-limit and validation procedure, and that seems
to be enough). 

c) Is there any way to filter some flow specifications from 
client announces ? F.e., i do not like idea that my customer 
may request mapping some traffic to network-control priority 
by the means of flowspecs... 

d) And, finally: unfortunately, not all our customers runs Juniper :( 
Is there any way to 'translate' some customer updates (classic 
blackhole by /32 route with specific community) into flow routes ? 


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] bad packets

[Alexandre Snarskii]

On Thu, Sep 10, 2009 at 01:06:16PM +0200, Bit Gossip wrote:
 Experts,
 on the ground that only the following protocols are allowed to reach the
 RE:
 - BGP (runs PMTU so should not fragment packets)
 - ISIS is only L2 so it is not blocked by a firewall filter
 - OSPF, LDP, RSVP, PIM, IGMP, BFD, VRRP: don't know about them
 - ssh, snmp, tacacs, ntp, Icmp, domain
 
 Is it correct to assume that for none of them is necessary to allow
 fragmens and packet with IP options?
 This way it is possible and safe to immediately reject on a loopback
 inbound filter all fragments and packets with IP options?

At least IGMP packets usually have Router-Alert option set. 
Not sure about VRRP (tcpdump shows no options) and BFD.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX-series: SHEAF: possible leak ...

[Alexandre Snarskii]

On Fri, Aug 28, 2009 at 03:18:01AM -0700, Nilesh Khambal wrote:
 Hi Alex,
 
 Sometimes, these messages also suggest a transient spike in the 
 sheaf memory utilization on the FPC for one of sheaves. It may not 
 be necessarily a memory leak. Sheaf memory is used for sending and 
 receiving the control and data packets between RE and the PFE.

Thanks, that explains a lot - looks like we have too much
of that 'cosmetic' messages 'jtree app NH negative' to 
overflow all the message queue: 

Aug 27 12:42:29 rt077-201 xntpd[80154]: bind() fd 243, family 2, port 123, addr 
10.0.0.1, in_classd=0 flags=0: Can't assign requested address
Aug 27 12:42:29 rt077-201 Stats bucket for jtree app NH negative.. 
Aug 27 12:42:33 rt077-201 last message repeated 57 times
Aug 27 12:42:33 rt077-201 SYSLOG: 13065 messages lost, message queue 
overflowed. 
and if this message queue is located on same sheaf memory
that might be a cause for SHEAF error messages. 

Anyway, after JunOS upgrade all those messages disappeared, 
but I start getting new one (and another interesting ungoogleable
messages) considering the same ICHIP: 

[Aug 31 10:18:05.078 LOG: Err] ICHIP(0):Packet drop in Ichip pktwr,rate: 1, 
total: 93963

and 'show pfe statistics error' shows me that there are errors
on this one ichip: 

s...@rt077-201 show pfe statistics error 
Slot 3
ICHIP Error statistics:
ICHIP 0123
-
Iwo DESRD:0000
Iwo HDRF:  359724673  2965007   103588 1530
Ipktwr Drops: 93988000

other fpc shows Iwo HDRF errors too, but not Ipktwr drops. 

Well, 94000 packets dropped out of 50408188862 passed on 
this interface since upgrade may be considered negligible,
but as far as they started mostly immediately after upgrade,
and as far as interface is far from saturation - may be there
is some problem with that I-Chip/fabric/fabric connection ? 
And are there any good documentation on what these errors mean ? 

 
 Seeing the SHEAF and NH App messages together in this scenario suggests 
 too many nexthop related operations in the PFE. If those messages started 
 after adding the new customer, you might want to check if this customer 
 is receiving any kind attack traffic. 

This customer was even disconnected for debugging purposes, but
error messages appeared right before JunOS upgrade. 
And no, this customer does not had no attack traffic, and did
not participate in multicast exchanges. 

 This may also include the traffic for non-existing destinations 
 which are directly connected to this new customer interface. 
 Are there any PFE_NH_RESOLVE_THROTTLED messages seen as well 
 in the logs along with these SHEAF messages?

There are some PFE_NH_RESOLVE_THROTTLED messages on same
(and others) fpc's of that box, but not on the same I-Chip. 

 Please get the below command outputs from FPC3 and get in touch 
 with JTAC by opening a case. Provide them with these outputs with 
 answers to above queries.

Tried to open case, but looks like our CTO forgot to extend 
our support contract :( 
Anyway, logs are saved, and if you want to take a look at - you may 
contact me directly. 

 
 From FPC3:
 ++
 
  *   show  route summary
  *   show route manager statistics
  *   show nhdb management operations
  *   show packet
  *   show packet statistics
  *   show jtree [0-3] memory extensive composition
  *   show jtree [0-3] memory extensive
  *   show rsmon
 
 Take at least 2-3  snapshots of these commands when these syslog messages are 
 seen.
 
 Thanks,
 Nilesh.
 
 
 
 On 8/28/09 2:25 AM, Alexandre Snarskii s...@snar.spb.ru wrote:
 
 
 
 Hi!
 
 Since yesterday one of our MX-series routers started logging
 next messages:
 
  fpc3 SHEAF: possible leak, ID 5 (packet(600)) (10563/512/1024)
  Stats bucket for jtree app NH negative..
 
 (both are logged by fpc3, another fpc's not affected), and after some
 googling I started worrying, because first message (SHEAF leak) is only
 mentioned in j-nsp some years ago in context of PFE memory leak that can
 stop your router forwarding (PSN-2004-06-009), and the second is cosmetic
 bug closed in PR/400917, concerning PFE memory leak too.
 
 So, the question is: do you think that fpc reload may help with
 this issue or i should plan JunOS upgrade in next maintenance
 window ? (now this router running JunOS 8.4R4.2 that is EOE/EOL
 anyway).
 
 PS: messages starter right after provisioning another client's
 interface, nothing special:
 
 cvs diff -u -D '2009-08-27 13:00' -D '2009-08-27 14:00' rt077-201
 [...]
 +unit 2103 {
 +description censored
 +vlan-id 2103;
 +family inet {
 +mtu 1500;
 +policer {
 +input 512Kbit;
 +output 512Kbit;
 +}
 +address censored

[j-nsp] j-series: EoMPLS vc goes mad after overheating ?

[Alexandre Snarskii]

Hi!

May be it sounds crazy, but situation is repeated... 

After overheating (temperature on RE got to 54C/129F due to air 
condition failure), our j-2320 stopped to encapsulate unicast 
ethernet frames into EoMPLS vc.

Symptoms: DHCP over EoMPLS vc working (because requests sent 
broadcast), ARP works, but client is unable to ping gateway,
and on gateway I can see both DHCP and ARP(broadcast) packets 
but no pings(unicast). 
PPPoE client is able to receive offer (PADO), but gateway never 
sees PADR that is sent unicast. 
When trying to ping 255.255.255.255 over the link - other
side receives that packets (sent broadcast). 
More than, counter of received frames does not increments
when there should be unicast frames received, looks like
port does not hear unicast on this port anymore...

Well, first time when I saw such behaviour (also after overheating), 
reboot helped, and i considered it as 'curious madness', but now 
situation is repeated.. 

PS: J-2320, JunOS 9.3R3.8 classic (non-ES). Situation is 
on only one port, ge-0/0/3, other ports working well. 
However, ge-0/0/3 is configured for EoMPLS edge only, 
and other interfaces configured as IP/MPLS core and IP/L3VPN Edge,
so I cannot be sure is it hardware or software problem. 

PPS: configuration of ge-0/0/3 is pretty straightforward: 

s...@rt100-001 show configuration interfaces ge-0/0/3
description DOWNLINK EoMPLS;
vlan-tagging;
mtu 4470;
encapsulation extended-vlan-ccc;
unit 451 {
vlan-id 451;
family ccc;
}
unit 913 {
vlan-id 913;
family ccc;
}
unit 3007 {
vlan-id 3007;
family ccc;
}

all three vc's is up/up, and all three shows the same symptoms. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX3200/4200 Uplink modules NOT hot swappable

[Alexandre Snarskii]

On Fri, Jul 31, 2009 at 04:02:25PM +0200, Malte von dem Hagen wrote:
 Hi there, I just like to share with you:
 
 It may be, the one or other of you reads the datasheet of EX3200/4200 switches
 and runs over the following, unspectacular and expected passage with just a
 slight nod:
 
 Uplink modules can be installed without powering down the switch, enabling
 users to add high-speed connectivity at any time or migrate from one uplink 
 type
 to the other to deliver the ultimate in flexible, high-performance
 interconnectivity.
 
 from http://www.juniper.net/us/en/local/pdf/datasheets/1000215-en.pdf
 
 The above is wrong and promises, what J can't keep:
 http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/uplink-module-ex3200-ex4200.html#jd0e161

Yeah, for ex-series OIR still means Online Insert and Reboot, 
just like with old cisco's 7500... However, as far as I know, 
true OIR (without reboot) is roadmapped to Q4 2009. 

 
 Very evil when you build Virtual Chassis and keep in mind well, if I need 
 more
 Uplink, I'll extend later
 
 Lesson learned: Don't believe just data sheets. Good to have redundant 
 switches.
 
 rgds,
 
 .m
 



 ___
 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] MPLS CCC on EX4200

[Alexandre Snarskii]

On Thu, Jul 30, 2009 at 09:22:18AM +0100, Matthew Walster wrote:
 I'm trying to set up a point-to-point link between two sites using EX4200s,
 joining several ports at one site to several ports at the other site. It
 seems like the ideal way to do this would be with a layer 2 encapsulation
 technique such as CCC, tied in with MPLS - especially if the system was
 expanded to multiple sites.
 I have configured this with RSVP for label distribution, and OSPF for
 loopback distribution. When the link between the two sites comes up, it
 takes quite a while (more than a minute) for the MPLS labels to be
 distributed, but I presume this is either normal behaviour or I need to
 set something to speed this up. That's not my problem, however.
 
 The intermediate link is a plain old standard ethernet circuit. When I

Have you tried to raise MTU on that ethernet circuit ? :) 

Something like: 

interface ge-A/B/C { 
  mtu 9012;
  unit 0 { 
  family inet { 
 mtu 1500;
 address . ;
  }
  family mpls { 
 mtu 4470;
  }
  }
}

actual numbers for interface and mpls mtu's may vary, but if you're
trying to achieve CCC connections it MUST NOT be less than 1540: 
1518(inner ethernet frame) + 4 (mpls label) + 18 (outer ethernet header).

 connect two laptops, one to each end of the MPLS circuit, then can ping each
 other fine. They can't seem to do HTTP traffic. I can login with WinSCP but
 it won't download the directory listing. Running several pings from the
 Windows laptop tells me that the maximum buffer size it can use is 1458,
 leading me to believe that this is an MTU issue, and the packets aren't
 being fragmented correctly.

Those packets are ethernet, and ethernet packets cannot be fragmented
easily... That's why you must run raised MTU on every MPLS link. 

 
 Is there a common solution to this problem? Any advice appreciated.
 
 Matthew Walster
 ___
 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] EX Feedback

[Alexandre Snarskii]

On Thu, Jul 23, 2009 at 01:30:56PM -0600, Brandon Bennett wrote:
 On Thu, Jul 23, 2009 at 11:26 AM, Paul Stewart p...@paulstewart.org wrote:
 
  Considering the idea of 5 48 port EX4200 switches with 10GE uplinks in a
  ring type setup or use the 5m cables on the back to do the same and save
  the 10GE ports on the front.  The two end switches would have GigE
  connections going to our distribution layer switches (Cat6500's).
 
 
 If you can do the virtual-chassis uplink ports in the back (up to 5m apart
 with a braided ring) then do it.  Like you said you will save the 10G
 uplinks and 128Gbps(marking performance included) vs 10Gbps.

Just a note: that 128Gbps looks to me like a 'true marketing number', 
because of what ex-series show in cli is 32Gbps: 

s...@switch show interfaces vcp-0
Physical interface: vcp-0, Enabled, Physical link is Down
  Type: 105, Link-level type: 70, MTU: 1514, Speed: 32000mbps

Well, there are two virtual-chassis interfaces, and they have
both input and output directions, and 32G * 2 * 2 is really 128Gbps
of marketing... 

Or am I wrong, and virtual-chassis really can do 128Gbps full-duplex 
on both ports ? And, anyway, 32Gbps is still better than 10Gbps
and saves uplink ports. 


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] PPPOE Termination - J2320?

[Alexandre Snarskii]

On Thu, Jun 04, 2009 at 12:35:49PM -0400, Paul Stewart wrote:
 Hi folks.
 
 I'm wondering if the J2320 or other J series routers can act as an access
 concentrator for PPPOE clients?  According to the docs it appears this
 platform can only act as a PPPOE client but looking to confirm.

J-series cannot work as PPPoE concentrator. 

The only Juniper aside Juniper/Unisphere E-/ERX-series that can work as 
PPPoE concentrator for now is M120, however, our SE claims that PPPoE
concentrator functionality will be added to M320 and MX-series later 
this year, and at least for MX-series it will require MS-DPC to handle 
this role. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ex-series: etherchannel bpdu loop ?

[Alexandre Snarskii]

On Wed, Mar 18, 2009 at 02:38:39PM -0800, Christopher E. Brown wrote:
 
 
 Check your cisco side configs, that config looks like a cisco 
 unconditional channel, not a lacp channel.

Yes, on Cisco side it's unconditional etherchannel. 
But on Juniper side it's unconditional etherchannel too: 

interface ge-0/0/15 {
 802.3ad ae0; /* no lacp involved */
} 

We're using lots of those unconditional links between Cisco and
M/MX-series and never had problems like that one.


 
 channel-group 1 mode on == HARD ETHER CHANNEL
 channel-group 1 mode active == Active LACP or PAGP (depends on platform)
 
 
 Some will need
 
 channel-protocol lacp
 channel-group 1 mode active
 
 others default to lacp


 
 
 
 
 keegan.hol...@sungard.com wrote:
 I'm not terribly well versed in ex configuration, ( I think we're still 
 evaluating them) but it looks like you are trying to negotiate on the ex 
 end and then have it set on the cisco side so there may be a point in time 
 when the links aren't aggergated on the juniper side where traffic is 
 looped.
 
 
 
 
 
 From:
 Alexandre Snarskii s...@snar.spb.ru
 To:
 Juniper-NSP Mailing list juniper-nsp@puck.nether.net
 Date:
 03/18/2009 01:43 PM
 Subject:
 [j-nsp] ex-series: etherchannel bpdu loop ?
 Sent by:
 juniper-nsp-boun...@puck.nether.net
 
 
 
 
 Hi!
 
 After power failure on one of our pop's we faced strange problem: 
 etherchannel between juniper ex-4200 and cisco 2960g started to 
 flap. By logs I saw that Cisco determined 'etherchannel 
 misconfiguration' condition, shuts down both ports of channel,
 then, after errdisable timeout, tried to set them up, but then 
 again detects etherchannel misconfiguration and so on and on... 
 
 By Cisco documentation, etherchannel misconfiguration means 
 that BPDU's sent on one ports of etherchannel returned back 
 via another port. And forwarding of those BPDU from one
 LAG member interface to another (rstp is disabled on juniper)
 smells like an error in JunOS... 
 
 Workaround: delete interfaces from LAG on Juniper, commit,
 add interfaces to LAG, commit. 
 
 PS: Configuration is pretty straightforward on both sides: 
 
 Juniper: 
 
 s...@sw006-201 show configuration interfaces ae0 
 aggregated-ether-options {
 minimum-links 1;
 link-speed 1g;
 }
 unit 0 {
 family ethernet-switching {
 port-mode trunk;
 vlan {
 members all;
 }
 }
 }
 s...@sw006-201 show configuration interfaces ge-0/0/15 
 ether-options {
 speed {
 1g;
 }
 802.3ad ae0;
 }
 s...@sw006-201 show configuration protocols 
 []
 stp {
 disable;
 }
 rstp {
 disable;
 }
 mstp {
 disable;
 }
 
 
 Cisco: 
 
 Cisco#show runn int po1
 interface Port-channel1
  switchport mode trunk
  mvr type source
 Cisco#show runn int gi 0/23
 interface GigabitEthernet0/23
  switchport mode trunk
  load-interval 30
  channel-group 1 mode on
 
 
 ___
 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] ex-series: etherchannel bpdu loop ?

[Alexandre Snarskii]

On Wed, Mar 18, 2009 at 02:35:11PM -0400, Jeff S Wheeler wrote:
 On Wed, 2009-03-18 at 20:39 +0300, Alexandre Snarskii wrote:
  After power failure on one of our pop's we faced strange problem: 
  etherchannel between juniper ex-4200 and cisco 2960g started to 
  flap. By logs I saw that Cisco determined 'etherchannel 
 Are you on 9.2R2.15 or earlier?  I believe this is a bug on the EX.

No, it's 9.4R1.8. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] ex-series: etherchannel bpdu loop ?

[Alexandre Snarskii]

Hi!

After power failure on one of our pop's we faced strange problem: 
etherchannel between juniper ex-4200 and cisco 2960g started to 
flap. By logs I saw that Cisco determined 'etherchannel 
misconfiguration' condition, shuts down both ports of channel,
then, after errdisable timeout, tried to set them up, but then 
again detects etherchannel misconfiguration and so on and on... 

By Cisco documentation, etherchannel misconfiguration means 
that BPDU's sent on one ports of etherchannel returned back 
via another port. And forwarding of those BPDU from one
LAG member interface to another (rstp is disabled on juniper)
smells like an error in JunOS... 

Workaround: delete interfaces from LAG on Juniper, commit,
add interfaces to LAG, commit. 

PS: Configuration is pretty straightforward on both sides: 

Juniper: 

s...@sw006-201 show configuration interfaces ae0 
aggregated-ether-options {
minimum-links 1;
link-speed 1g;
}
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members all;
}
}
}
s...@sw006-201 show configuration interfaces ge-0/0/15
ether-options {
speed {
1g;
}
802.3ad ae0;
}
s...@sw006-201 show configuration protocols
[]
stp {
disable;
}
rstp {
disable;
}
mstp {
disable;
}


Cisco: 

Cisco#show runn int po1
interface Port-channel1
 switchport mode trunk
 mvr type source
Cisco#show runn int gi 0/23
interface GigabitEthernet0/23
 switchport mode trunk
 load-interval 30
 channel-group 1 mode on


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Upgrade from M10i?

[Alexandre Snarskii]

On Fri, Mar 13, 2009 at 09:10:04PM -0500, Richard A Steenbergen wrote:
 On Wed, Feb 11, 2009 at 05:05:52PM +0300, Alexandre Snarskii wrote:
  That is not an rlimit, that is MAXDSIZ parameter of JUNIPER-EX kernel 
  configuration. And while it hardcoded to kernel, it can be tweaked 
  with the help of loader.conf. 
  
  While this hack works, it has at least one major drawback: loader.conf 
  is rewritten during JunOS upgrade, so, I'd prefer not to use it on
  production networks.. 
 
 Actually it looks like Juniper has further crippled things in rpd now. I 
 just tested this on 9.4R1 and there is now a hard-coded max-prefix which 
 doesn't seem to be turned off by any of the usual prefix-limit 
 configurations:
 
 rpd[755]: %DAEMON-3-RPD_RT_PREFIX_LIMIT_REACHED: Number of prefixes 
 (12288) in table inet.0 still exceeds or equals configured maximum (12288)
 rpd[755]: %DAEMON-3-RPD_RT_PREFIX_LIMIT_REACHED: Number of prefixes (1024) 
 in table inet6.0 still exceeds or equals configured maximum (1024)

Looks like you have reached routing-options maximum-prefixes safe
default. And it is configurable too :)  
Not able to reproduce it now, but when I had ex-switch in my lab, 
I was able to get ~220k prefixes into RIB with JunOS 9.4R1. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX routed VLAN counters and other issues

[Alexandre Snarskii]

On Thu, Mar 05, 2009 at 08:49:10PM -0800, w...@loopfree.net wrote:
 I have been eval'ing an EX3200 for use as a small datacenter 
 distribution switch. The idea was to have a routed uplink to a bigger 
 router and routed VLANs to handoff to customers, using the EX as a 
 cheap router with a bunch of gig-e ports.
 
 It appears that the switch doesn't consistently count traffic on the 
 RVI interfaces -- in a test enivronment with a routed VLAN uplink and a 
 separate routed VLAN to a customer, one of the RVIs counts transit 
 traffic while the other counts traffic to the local IP only (IP 
 actually on the switch interface).

The lack of statistics on RVI is my most hated misfeature of EX 
series too.. :( 

Well, there is a workaround - if you need to count bytes you can do 
it with the help of l3-subinterfaces, something like that: 

interface ge-0/0/1 { 
vlan-tagging;
uint 10 { 
vlan-id 10;
family inet { . }

One of disadvantages of this workaround is that in this config you 
are not able to switch vlans from that interface (all vlans must be 
terminated and routed locally), but there is workaround for that too: 
if you need to have both routed and switched vlans on interface - 
you may use hairpin connection, fortunately, vlan-ids is interface-
significant in vlan-tagging mode. 

 
 FWIW it looks like Cisco 3550 counts local traffic only, but 3560  
 newer supposedly get it right and count transit traffic like a real 

No, that behaviour is not changed even in 35[67]0E.. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Upgrade from M10i?

[Alexandre Snarskii]

On Tue, Feb 03, 2009 at 12:49:10PM -0600, Richard A Steenbergen wrote:
 On Tue, Feb 03, 2009 at 06:35:34PM +0100, sth...@nethelp.no wrote:
  Given the requirement of full BGP routes, I don't believe the EX
  platform is an acceptable alternative...
 
 Well, that all depends what you want to do with the BGP routes. The EX
 has more than enough CPU and RAM to take a full table or two and do
 something useful with it, you just can't install more than 12k unicast
 routes into TCAM for hardware forwarding. Of course since Juniper has a
 policy-statement option sitting between the RIB to FIB export, you could 
 very easily export a limited number of routes to hw (i.e. default 
 routes) while still handling full BGP at a protocol level.
 
 Or at least you could, if this functionality wasn't crippled in
 software. Even though the small EX's have 1GB of DRAM, there is a rlimit
 on rpd memory somewhere around 80MB which causes it to coredump if you
 use too much memory. I can't quite tell if this is just someone being
 silly (assuming you'll never need more ram with only 12k routes), or if
 this is being done intentionally to cripple the product so it can't be
 used as a route reflector (*) (even after you buy a BGP license). Either
 way it's a horrible disservice to the product, since this could be used
 to solve the classic how to support full bgp on a top-of-rack L3
 aggregation switch problem without resorting to ghetto Cogentesque 2
 BGP session hackery. If you think this would be useful, please ask 
 Juniper to remove the crippling rlimit and let the device handle full 
 routes.

That is not an rlimit, that is MAXDSIZ parameter of JUNIPER-EX kernel 
configuration. And while it hardcoded to kernel, it can be tweaked 
with the help of loader.conf. 

While this hack works, it has at least one major drawback: loader.conf 
is rewritten during JunOS upgrade, so, I'd prefer not to use it on
production networks.. 


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Upgrade from M10i?

[Alexandre Snarskii]

On Tue, Feb 03, 2009 at 05:23:27PM -, michael.fi...@bt.com wrote:
  Hi,
  
  We have a number of M7i's and an M10i and are very happy with them.
  
  However, we need to go to 10Gig shortly and I wondered if 
  anyone could 
  suggest what options are available. I understand Juniper have 
  some new 
  switches and wonderd if they might be suitable.
  
  We need at least 4 x 10G ports and 8 x 1G ports, IPv4/IPv6, 
  OSPFv2/OSPFv3, full BGP (peering/transit), no MPLS and that's about 
  it.
  
[...]
 
 The second option is the EX platform, if you make 2 EX 4200-24s into a 
 virtual chassis, and put the 2x10GigE uplink module into each one, you 
 can create a router / switch with 48 GigE ports and 4 10GigE ports. 
 This will be the cheapest option, but the code is still maturing, 
 and I'm not sure its capable of handling a full BGP table (I think 
 theres a sub-100,000 route limit).

There is 12.000 route-limit on small EX-switches, so they are not an 
option here... 
Well, there are 'big' EX-series switches (EX-8200) announced in December, 
and (by specifications) they will be able to hold a full-view, but as far 
as i know, they're not shipping yet. 

 The final, and probably best option, is the MX series. I don't have 
 any direct experience with this platform (yet), but you could use an 
 MX240 with a 10GigE and a GigE DPC-R which would meet your needs. 
 As others have said, and as with the EX option, you will have rather 
 more GigE ports than you wanted - 40 instead of 8.

I'm second for that option. May be not MX-240 but MX-480, that 
depends mostly on available power and rack space... 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Why should I *not* buy an MX?

[Alexandre Snarskii]

On Sat, Nov 08, 2008 at 04:15:21PM -0600, Richard A Steenbergen wrote:
 
 If you want a Juniper product that has the same limitations as a
 traditional hacked up L2 switching CAM platform, look at the EX. You'll
 quickly start to see the same limitations I mentioned above. Don't think
 of the MX as a switch, think of it as a better T-series without SONET or
 multichassis support for 1/4 the price. What I tell people is this: If

Well, MX is still like T-Series without multichassis, but the SONET
capability will be available with MX-FPC (really, DPC) soon: 

cite
The MX-series will also be enhanced with the addition of a new Flexible PIC 
Concentrator that provides packet over SONET capabilities, leveraging the 
same OC-48 and OC-192 Physical Interface Cards (PICs) used for M- and 
T-series platforms.
/cite

(c) http://www.juniper.net/company/presscenter/pr/2008/pr_2008_10_20-14_7.html

PS: Another new DPC announced in the same press-release is MultiService
DPC (MS-DPC): 

cite
MS-DPCs are full slot modules that supply hardware acceleration for an 
array of packet processing-intensive services for the MX-series portfolio -
the MX960, MX480, and MX240. These services include advanced SBC functions, 
stateful firewall, NAT, IPsec, anomaly detection, J-Flow accounting, and 
tunnel services. 
/cite

(c) http://www.juniper.net/products/modules/100258.pdf

Of course, all those functions are considered value-added services,
and require licenses :) (I do not blame Juniper for that, they are
really introducing new value to MX). 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Meaning of except in firewall filters

[Alexandre Snarskii]

On Wed, Oct 29, 2008 at 11:24:36PM +0100, Tore Anderson wrote:
 Hi,
 
 I'm trying to restrict SSH access on some of my routers to allow 
 connections from just a few known source networks (defined in a prefix 
 list called ssh-allowed).  I then came up with the following, and 
 applied it as an input filter on lo0.0:

you should add 0.0.0.0/0 as matching entry, and then your ssh-allowed
host will be excepted :)

Like that:  

 
 [edit firewall filter lo0-input]
 term restrict-ssh {
 from {
 source-prefix-list {

  0.0.0.0/0;
 ssh-allowed except;
 }
 protocol tcp;
 destination-port ssh;
 }
 then {
 syslog;
 reject;
 }
 }
 term fallthrough {
 then accept;
 }
 
 This didn't work as expected, SSH connections was still allowed from any 
 host (both from inside networks found inside ssh-allowed as well as from 
 outside).  It seems like the restrict-ssh term never matched.
 
 If I removed the except, it worked as I would have thought - 
 connections from hosts inside prefixes found in the ssh-allowed prefix 
 list was denied, while connections from the rest of the internet was 
 allowed.  Of course, this is the opposite behaviour of what I want.
 
 I can work around it by making first a term that accepts SSH from the 
 known prefixes, then another term that rejects all other SSH 
 connections, and finally the fallthrough that accepts the rest.  However 
 this behaviour made me really curious...  Isn't except supposed to 
 invert the logic of the match?  That's how I understand the help text, 
 at least:
 
 except   Match addresses not in this prefix list
 
 It doesn't seem to work that way, though.  Does anyone know how it's 
 supposed to be used?
 
 Regards 
 -- 
 Tore Anderson
 ___
 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] MX sw license

[Alexandre Snarskii]

On Fri, Oct 17, 2008 at 05:50:04PM -0700, Marlon Duksa wrote:
 Does anyone know if sw license is required for a lab use on MX in 9.2? These
 are the messages that we are getting:
 [EMAIL PROTECTED] show system alarms
 2 alarms currently active
 Alarm time   Class  Description
 2008-10-17 17:24:30 PDT  Minor  License grace period for feature 31 is about
 to expire
 2008-10-17 17:23:29 PDT  Minor  Radius/SDX Address Pool Assignment usage
 requires a license
 
 Is this licensing honorary based or does it actually prevent  a feature from
 working?

License enforcement for Subscriber access and related features is described 
here: 

http://www.juniper.net/techpubs/software/junos/junos92/swconfig-install/license-enforcement.html#jN12F73

and, as far as I can understand, if you are not abused by warning messages
on commit and not requesting official support for licenseable features - 
you can use licenseable features even after grace period... 

At least for now...

Sometimes that may change - f.e., J-Flow and Andvanced BGP (route-reflection)
licenses were not enforced for J-Series for before JunOS 8.5, and enforcement 
of them were clearly outlined in release notes: 

 From JUNOS Release 8.5 onwards, if you have not installed a 
valid license, the BGP router reflectors and J-Flow traffic 
analysis features do not function.

(http://www.juniper.net/techpubs/software/jseries/junos85/rn-jseries-85/changes-in-default-behavior.html)

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] system maximums for the M and MX series routers

[Alexandre Snarskii]

On Sun, Oct 12, 2008 at 11:24:08AM +0200, [EMAIL PROTECTED] wrote:
   I need to know the maximum number of L2 and L3VPN supported on MX and M
  series routers.
 
 There is no System maximums document for the M / MX series, as far as
 I know. We use both M, MX and ERX, and our experience is that parts of
 the ERX System maximums should be taken with a large grain of salt.

I'd rather disagree with last statement. 
Well, our setup is quite different, we're using ERX'es just as they 
supposed to be used (BRAS, PPPoE concentrators in our case), and, as far 
as we can see their System Maximums is quite accurate in that setup.. 

And I appreciate Juniper for publishing them - well, every piece of 
hardware has it's hardware limitations, and to know what are they before
real-life deployment is much better then discovering 'ad hoc'.. 

Back to System Maximum for M-/MX-series: I'd also be interested
in that document, especially in the part concerning new (JunOS 9.1+) 
'Subscriber Access' feature. Just some quick questions, which are
covered fully (and accurately, as far as I can tell) for ERX, but
not for J/M/MX series: 
- how many subscribers can be hadled per chassis (or per fpc, or per
port if it's fpc/port-wide parameter) ? 
- how many policers can be attached to subscribers (again, per fpc/port) ? 

 On the other hand, for those cases where we have been able to get real
 numbers from Juniper for the M / MX series, our experience is that these
 numbers reflect reality much better than the ERX numbers.
 
 For an ERX example, the System maximums for JunOSe 9.2.0 states that
 the ERX-310 supports a maximum of 1000 virtual routers (or 1000 VRFs)
 per chassis. Our experience is that with anything close to a realistic
 configuration, where some of the VRFs use DHCP relay, this limit is much
 lower, on the order of 150 or so.
 
 Getting back to the M / MX: The maximum number of L2 and L3VPN supported
 will depend on a number of factors, for instance number of prefixes and
 nexthops, and also on the amount of memory in your forwarding complex
 (M7i / M10i can have either 128 MB or 256 MB on the CFEB. The difference
 is rather significant).
 
 The only simple answer is, it depends
 
 Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
 ___
 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] pppoe on e320

[Alexandre Snarskii]

On Wed, Oct 01, 2008 at 08:40:38AM -0700, Marlon Duksa wrote:
 
 B-RAS licenses are available in various sizes to enable subscriber access
 for up to one of the following maximum number of simultaneous active IP,
 LAC, and bridged Ethernet interfaces:
 
 * 4000
 * 8000
 * 16,000
 * 32,000
 * 48,000
 
 Do we need to install a license to configure this or is BRAS functionality
 supported by default?

Generally speaking, yes, you have to install BRAS license. 
However, you can configure and even use BRAS features (in a very limited 
way, just up to 10 pppoe sessions, useful for testing, but not in real life) 
without installing license (at least at ERX-310, not tested with E320).  

Yet another interesting feature: BRAS license for 4k users allows 
you to run not 4000 subscribers, but 4196.. 

-- 
Alexandre Snarskii

If you ask a stupid question, you may feel stupid. 
If you don't ask a stupid question, you remain stupid.
   -Tony Rothman, Ph.D.U. Chicago, Physics
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ex-series: counters for transit traffic ?

[Alexandre Snarskii]

On Fri, Aug 01, 2008 at 06:39:22PM +0400, Alexandre Snarskii wrote:
 
 Hi!
 
 It looks like ex-series switches does not count nor packets nor
 bytes, nor ingress nor egress, for transit traffic. 
 
 For example, on physical interfaces all I can get is Local statistics: 

Well, for physical interfaces it was my fault (detailed statistics
is may be too detailed): counters are ok for the interface:

  Traffic statistics:
   Input  bytes  : 989129150 bps
   Output bytes  : 235515820 bps
   Input  packets:695950 pps
   Output packets:   2796090 pps

and the only (cosmetic) bug is that they are not counted as 
'Transit statistics' for unit 0. 

Thanks to everybody who pointed me to that. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] ex-series: counters for transit traffic ?

[Alexandre Snarskii]

Hi!

It looks like ex-series switches does not count nor packets nor
bytes, nor ingress nor egress, for transit traffic. 

For example, on physical interfaces all I can get is Local statistics: 

snar show interfaces ge-0/0/0 detail statistics
[...]
Traffic statistics:
 Input  bytes  :   121945
 Output bytes  :   883419
 Input  packets: 1248
 Output packets:10316
Local statistics:
 Input  bytes  :   121945
 Output bytes  :   883419
 Input  packets: 1248
 Output packets:10316
Transit statistics:
 Input  bytes  :00 bps
 Output bytes  :00 bps
 Input  packets:00 pps
 Output packets:00 pps

and for logical interfaces situation is even worse: 

snar show interfaces vlan.69 detail statistics 
  Logical interface vlan.69 (Index 90) (SNMP ifIndex 90) (Generation 156)
Description: Management
Flags: SNMP-Traps 0x0 Encapsulation: Unspecified
Traffic statistics:
 Input  bytes  :0
 Output bytes  :0
 Input  packets:0
 Output packets:0
Local statistics:
 Input  bytes  :0
 Output bytes  :0
 Input  packets:0
 Output packets:0

however, attached filter (with counter and policer) shows that there
were some transit traffic (from vlan.69 over ge-0/0/23 to vlan.901 over
ge-0/0/0): 

snar show firewall filter inbound  

Filter: inbound
Counters:
NameBytes  Packets
v901-ingress-policer 1548076110191
Policers:
Name  Packets 
512k 1461

Can anybody enlighten me, is it hardware limitation, software bug (running 
9.1R2.10) or something other (like some feature not configured) ? 

Configuration is pretty straightforward: 

snar show configuration vlans v69 
description Management;
vlan-id 69;
interface {
ge-0/0/23.0;
}
l3-interface vlan.69;

snar show configuration interfaces ge-0/0/23
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members all;
}
}
}

snar show configuration interfaces vlan unit 69 
description Management;
family inet {
filter {
input inbound;
}
address 10.0.88.231/24;
}

snar show configuration firewall family inet filter inbound 
term v901 {
from {
destination-address {
10.1.89.0/24;
}
}
then {
policer 512k;
count v901-ingress-policer;
}
}
term final {
then accept;
}

PS: snmp counters (both 32- and 64-bit ones) also shows zero. 

PS: yet another interesting feature of that platform/JunOS is that even 
firewall counters unable to count traffic destined to or generated 
by vlan.N interfaces.. 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] asn32: as-path formatting ?

[Alexandre Snarskii]

Hi!

Since JunOS 9.1, Juniper supports 32-bit AS Numbers (RFC 4893), and release 
notes states that: 
cite
Support for 4-byte AS numbers is also extended to the AS extended-community 
attribute and AS-path regular expressions 
/cite
but documentation on defining AS Path regular expressions does not provide 
any examples using 32-byte asn's. 

So, I'm just curious, how should they be formatted ? 

For example, If I want to filter paths originated by Gert Doering's AS3.3,
should I set up filter as 'as-path as33 3.3$, or it will be interpreted
by old rules as 'anything 3 any as 3' and I need to use some other 
syntax ? 

PS: and, Gert, thanks for providing AS3.3, AS-SPACENET and route-object
with origin: AS3.3 for real-life testing :) 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Which Router

[Alexandre Snarskii]

On Wed, May 14, 2008 at 09:06:27AM -0400, Jose Madrid wrote:
 I think I am the only one having issues with my J2320.  I use it as a
 peering device and have 91 BGP peers on there.  It has 1GB of RAM,
 about 492K routes, and it averages 72% CPU utilization.  Traffic-wise,
 it does about 38Mbps to one peering point and 55Mbps to another.  It
 is holding up surprisingly well, but to be honest I expected a bit
 more.  Maybe sometimes I am too demanding, and this was a $2000
 device, so I shouldnt complain much :)

You're not the only one... :) However, my complaint is quite
different - my J6350/1G RAM is unable to run full-view :) 
Sessions just drops due to low memory... 

Well, based on others experience I can suggest that it's because
I run lots of 'not-so-standard' stuff, like all my iBGP sessions
configured for 'family inet labeled-unicast resolve-vpn', 'family
inet-vpn' and 'family inet6'... And, anyway, full-view is never
considered something I must run on that router. 

PS: no problems with traffic. Right now it runs ~700Mbit at 50% idle. 
And costs much less than c7301 it replaced :) 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] j-series vs. short pings ?

[Alexandre Snarskii]

On Fri, Feb 29, 2008 at 09:31:42AM -0800, Paul Goyette wrote:
   If your traffic is transiting an IPsec tunnel, please have
   a look at the following tech bulletin:
  
  IPSec is not involved in this setup, lab topology is as simple as
  notebook(freebsd) - switch(catalyst 2960) - juniper 6350. 
 
 Hmmm.  Sounds like something isn't padding the Ethernet frame
 to the minimum frame-length of 64 bytes, or is ignoring the
 VLAN tag when calculating the minimum acceptable frame length.
 
   MAC header   14
   IP header20
   ICMP header  12
   ICMP payload 17
   ---
   Total63
 
 Check for runts on the J-6350 router, as well as verify that
 frames are arriving.  Also check to see if it still fails with
 non-VLAN-tagged interface.  And maybe put a sniffer on the
 line to see if the frames are being padded, and by how much.

Frames arriving to J6350 well. No problems with padding found. 
No problems with runtime errors too. Have'nt checked untagged
packets yet...

Interesting enough, that when I make interface member of vrf-type 
routing-instance - problem disappears... 
And, I can confirm that I have no problems with transit packets, 
and that I have no problems with 'unrouteable'/'firewalled' frames 
(in that case I'm getting RE(or fwdd?)-generated ICMP host unreachables, 
just as I should). So, the problem is limited to: short frames AND destined 
to routing engine AND arriving in 'default' routing table. Put any reason
off - and problem disappears. 
Looks much more likely that there is some bug in JUNOS (8.3R1.5, export 
edition) than any other reason...

PS: example of broken packet: 

19:48:54.250389  In PFE proto 2 (ipv4): (tos 0x0, ttl  64, id 26604, offset 0, 
flags [none], proto: ICMP (1), length: 28) 10.11.12.14  10.11.12.13: ICMP echo 
request, id 35437, seq 1, length 8 (wrong icmp cksum 0 (-6d91)!)
 0200  4500 001c 67ec  4001 e6c4
 0a0b 0c0e 0a0b 0c0d 0800  8a6d 0001
        c1fd
 684d

shows that ICMP checksum is really wrong. May be it's just stripped
off by Marvel chip or by fwdd before forwarding to RE and RE code
is not expecting it to be stripped in some (rare enough, I admit) 
situations. 

PPS: example of 'firewalled' ping and ICMP response:
ping packet: 

21:41:01.954515 00:e0:00:82:34:c6  00:19:e2:45:e3:82, ethertype IPv4 (0x0800), 
length 59: (tos 0x0, ttl 64, id 6924, offset 0, flags [none], proto ICMP (1), 
length 45) 10.11.12.14  10.21.88.100: ICMP echo request, id 49494, seq 0, 
length 25
0x:  4500 002d 1b0c  4001 e732 0a0b 0c0e  [EMAIL PROTECTED]
0x0010:  0a15 5864 0800 dbfb c156  47cc 463d  ..Xd.V..G.F=
0x0020:  000e 9065 0809 0a0b 0c0d 0e0f 10 ...e.

response packet: 

21:41:01.977917 00:19:e2:45:e3:82  00:e0:00:82:34:c6, ethertype IPv4 (0x0800), 
length 70: (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), 
length 56) 10.11.12.13  10.11.12.14: ICMP host 10.21.88.100 unreachable - 
admin prohibited filter, length 36
(tos 0x0, ttl 64, id 6924, offset 0, flags [none], proto ICMP (1), 
length 45) 10.11.12.14  10.21.88.100: ICMP echo request, id 49494, seq 0, 
length 25
0x:  4500 0038   fe01 9094 0a0b 0c0d  E..8
0x0010:  0a0b 0c0e 030d 57a0   4500 002d  ..W.E..-
0x0020:  1b0c  4001 e732 0a0b 0c0e 0a15 5864  [EMAIL PROTECTED]
0x0030:  0800 dbfb c156   .V..

- you can see, that in response at offset 0x32 there is correct checksum,
0xdfdb, copied from original packet (originally at offset 0x16).

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] j-series vs. short pings ?

[Alexandre Snarskii]

Hi!

During narrowing down one of our problems, I found, that I'm able 
to ping juniper from directly connected (vlan) subinterface only 
when ICMP payload size is more or equal 18 bytes... 

Example:

[EMAIL PROTECTED]:~ping -s 17 10.21.88.100
PING 10.21.88.100 (10.21.88.100): 17 data bytes
^C
--- 10.21.88.100 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss

but when size is 18 (or more) - everything is fine: 

[EMAIL PROTECTED]:~ping -s 18 10.21.88.100
PING 10.21.88.100 (10.21.88.100): 18 data bytes
26 bytes from 10.21.88.100: icmp_seq=0 ttl=64 time=0.435 ms
26 bytes from 10.21.88.100: icmp_seq=1 ttl=64 time=0.395 ms


At the same time, doing 
monitor traffic interface ge-0/0/2.468 detail no-resolve matches icmp
I can see, that when I'm pinging with 17-byte (or less) sized packets,
juniper sees them with 'broken' ICMP checksum: 

17:36:39.959518  In IP (tos 0x0, ttl  64, id 15916, offset 0, flags [none], 
proto: ICMP (1), length: 45) 10.21.88.99  10.21.88.100: ICMP echo request, id 
13318, seq 0, length 25 (wrong icmp cksum 0 (-d452)!)
17:36:40.970227  In IP (tos 0x0, ttl  64, id 15918, offset 0, flags [none], 
proto: ICMP (1), length: 45) 10.21.88.99  10.21.88.100: ICMP echo request, id 
13318, seq 1, length 25 (wrong icmp cksum 0 (-d1a6)!)
17:36:41.949567  In IP (tos 0x0, ttl  64, id 15920, offset 0, flags [none], 
proto: ICMP (1), length: 45) 10.21.88.99  10.21.88.100: ICMP echo request, id 
13318, seq 2, length 25 (wrong icmp cksum 0 (-ce47)!)

but when I'm tcpdumping those pings on sending side or on SPAN port
at the egress from switch to juniper - everything is OK 

Details: Juniper is J6350 running [8.3R1.5] (Export edition), interface 
is onboard GE-TX, configuration is pretty simple: 

[EMAIL PROTECTED] show configuration interfaces ge-0/0/2   
description DOWNLINK to SW088-001 inet;
vlan-tagging;
mtu 9018;
unit 468 {  
description IP-MUX;
vlan-id 468;
family inet {   
mtu 1500;   
address 10.21.88.100/24;
}   
}   

Question: is there any way to fix this behaviour ? (short ICMP pings
is the way the RAD IPMux verifies mac-address of his gateway, and
we're just unable to use IPMux'es as downlinks to Juniper)..

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] j-series vs. short pings ?

[Alexandre Snarskii]

On Fri, Feb 29, 2008 at 08:18:22AM -0800, Paul Goyette wrote:
 If your traffic is transiting an IPsec tunnel, please have
 a look at the following tech bulletin:

IPSec is not involved in this setup, lab topology is as simple as
notebook(freebsd) - switch(catalyst 2960) - juniper 6350. 

 http://alerts-int.juniper.net/pa/viewalert.jsp?actionBtn=SearchtxtAlert
 Number=PSN-2008-02-017viewMode=Return
 
 Paul Goyette
 Juniper Networks Customer Service
 JTAC Senior Escalation Engineer
 PGP Key ID 0x53BA7731 Fingerprint:
   FA29 0E3B 35AF E8AE 6651
   0786 F758 55DE 53BA 7731 
 
  -Original Message-
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of 
  Alexandre Snarskii
  Sent: Friday, February 29, 2008 6:51 AM
  To: Juniper-NSP Mailing list
  Subject: [j-nsp] j-series vs. short pings ?
  Importance: High
  
  
  
  Hi!
  
  During narrowing down one of our problems, I found, that I'm able 
  to ping juniper from directly connected (vlan) subinterface only 
  when ICMP payload size is more or equal 18 bytes... 
  
  Example:
  
  [EMAIL PROTECTED]:~ping -s 17 10.21.88.100
  PING 10.21.88.100 (10.21.88.100): 17 data bytes
  ^C
  --- 10.21.88.100 ping statistics ---
  4 packets transmitted, 0 packets received, 100.0% packet loss
  
  but when size is 18 (or more) - everything is fine: 
  
  [EMAIL PROTECTED]:~ping -s 18 10.21.88.100
  PING 10.21.88.100 (10.21.88.100): 18 data bytes
  26 bytes from 10.21.88.100: icmp_seq=0 ttl=64 time=0.435 ms
  26 bytes from 10.21.88.100: icmp_seq=1 ttl=64 time=0.395 ms
  
  
  At the same time, doing 
  monitor traffic interface ge-0/0/2.468 detail no-resolve matches icmp
  I can see, that when I'm pinging with 17-byte (or less) sized packets,
  juniper sees them with 'broken' ICMP checksum: 
  
  17:36:39.959518  In IP (tos 0x0, ttl  64, id 15916, offset 0, 
  flags [none], proto: ICMP (1), length: 45) 10.21.88.99  
  10.21.88.100: ICMP echo request, id 13318, seq 0, length 25 
  (wrong icmp cksum 0 (-d452)!)
  17:36:40.970227  In IP (tos 0x0, ttl  64, id 15918, offset 0, 
  flags [none], proto: ICMP (1), length: 45) 10.21.88.99  
  10.21.88.100: ICMP echo request, id 13318, seq 1, length 25 
  (wrong icmp cksum 0 (-d1a6)!)
  17:36:41.949567  In IP (tos 0x0, ttl  64, id 15920, offset 0, 
  flags [none], proto: ICMP (1), length: 45) 10.21.88.99  
  10.21.88.100: ICMP echo request, id 13318, seq 2, length 25 
  (wrong icmp cksum 0 (-ce47)!)
  
  but when I'm tcpdumping those pings on sending side or on SPAN port
  at the egress from switch to juniper - everything is OK 
  
  Details: Juniper is J6350 running [8.3R1.5] (Export edition), 
  interface 
  is onboard GE-TX, configuration is pretty simple: 
  
  [EMAIL PROTECTED] show configuration interfaces ge-0/0/2   
  description DOWNLINK to SW088-001 inet;
  vlan-tagging;
  mtu 9018;
  unit 468 {  
  description IP-MUX;
  vlan-id 468;
  family inet {   
  mtu 1500;   
  address 10.21.88.100/24;
  }   
  }   
  
  Question: is there any way to fix this behaviour ? (short ICMP pings
  is the way the RAD IPMux verifies mac-address of his gateway, and
  we're just unable to use IPMux'es as downlinks to Juniper)..
  
  ___
  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] The Switch is ON !!!

[Alexandre Snarskii]

On Tue, Jan 29, 2008 at 04:55:38PM +0100, Sabri Berisha wrote:
 On Tue, Jan 29, 2008 at 06:47:59PM +0300, Alexandre Snarskii wrote:
 
 Hi,
 
  noting that these 'switches' will be MPLS-able in this year, so
  it can be used not only as 'enterprise switch', but as SP one.
  And their EX 4200-24F is always ideally suited for metro ethernet 
  distribution/access levels...
 
 http://www.juniper.net/switch/products.html
 
 The specs say:
 
 Layer 3 Features: IPv4
 Max number of ARP entries: 16,000
 Max number of IPv4 unicast routes in hardware: 12,000
 Max number of IPv4 multicast routes in hardware: 2,000
 Routing protocols: RIPv1/v2, OSPF, BGP, ISIS
 
 12k of routes would work 25 years ago for a service provider :)

Yes, this switch will not be able to run full-view. So what ? :) 
Most (98%) of our customers dont need it, and those in need will
have their vlan terminated not on that switch but on some router... 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] The Switch is ON !!!

[Alexandre Snarskii]

On Tue, Jan 29, 2008 at 12:32:37PM -0200, GIULIANO (UOL) wrote:
 Be welcome to the new Juniper EX-Series Family of Enterprise
 Class Switches:
 
 http://www.juniper.net/index.html

Impressive. Especially footnote about Advanced Feature License: 

AFL including IPv6 Routing, IS-IS, BGP, MBGP, MPLS, Enhanced GRE Tunnels (7)
available for purchase with JUNOS 9.1 in Q2'08.

noting that these 'switches' will be MPLS-able in this year, so
it can be used not only as 'enterprise switch', but as SP one.
And their EX 4200-24F is always ideally suited for metro ethernet 
distribution/access levels...

PS: if anybody knows, what MPLS features it will support - can you
share it to me ? :) 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp