[j-nsp] ISIS (ref-bw & L1 metric)

[Jking T]

Hi Experts,

I have couple of queries on IS-IS

1) Just 
wondering what reference-bandwidth value in "show isis overview" 
indicates?? 
We have set reference-bandwidth as 1000g for ISIS. (We 
dont see this output with routers not having reference-bandwidth 
command)

l...@mumbdst1> show isis overview 
Instance: master
 
 Router ID: x.x.x.x
  Adjacency holddown: enabled
  Maximum Areas:
 3
  LSP life time: 65535
  Reference bandwidth: 3567587328  <<<---
 
 Attached bit evaluation: enabled
  SPF delay: 200 msec, SPF 
holddown: 5000 msec, SPF rapid runs: 3
  IPv4 is enabled, IPv6 is 
enabled
  Traffic engineering: enabled
  Restart: Enabled
    
Restart duration: 200
 sec
    Helper mode: Enabled
  Level 1
    Internal route 
preference: 15
    External route preference: 160
    Wide metrics are enabled, Narrow metrics are 
enabled
  Level 2
    Internal route preference: 18
    
External route preference: 165
    Wide metrics are enabled

2)
 We have few routers in the setup & all in Level-2. (Level1 
disabled). In that case, shouldnt we expect not to see Level1 Metric 
information in both the outputs???

l...@mumbdst1> show isis 
interface 
IS-IS interface database:
Interface L CirID
 Level 1 DR    Level 2 DR    L1/L2
 Metric
lo0.0    0   0x1 Passive   
Passive 0/0
xe-0/0/0.0    2   0x1 
Disabled  Point to Point    100/10 
 
ge-1/0/0.0    2   0x1 Disabled  Point to 
Point    100/1000

Any
 thoughts??

Thank you.

Regards,
JK

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

Re: [j-nsp] Auto-bandwidth Accuracy

[Richard A Steenbergen]

On Tue, May 25, 2010 at 03:23:51PM -0400, Olson, Martin wrote:
> Yeah, I found the same behavior.  Sometimes the Max AvgBW would go up
> by 5X-7X the value it should've, which would lead to really high
> reservations after the next adjust-interval.  I opened case
> 2009-0610-0697 about the issue, and after a while they traced the
> problem to PRs 438157 and 457767.  The first code with the fix for
> both PRs is 9.6R2/9.5R3/9.4R4/9.3R5.  They told us that if we disabled
> the adjust-threshold-overflow-limit in the meantime, that would
> alleviate the problem until we upgrade code.

Hrmmm interesting. That would definitely explain a few things, since the
router I noticed that issue on was running 9.4R3. The funny thing is, I
think I'm actually seeing another different bug on 9.5R4 too. I'm
watching one particular interface which is actually doing about 4.5Gbps,
but the RSVP reservations keep jumping between ~4.5G (accurate), ~6.5G,
and ~8.5G.  The LSPs themselves are all staying put, it's just the
reservations that are changing.

The two biggest LSPs going over this interface are two parallel LSPs
ingressing on this router, and going to the same destination (so they
should be roughly balancing. The actual traffic passing through each of
the LSPs is ~1.8G, but when autobw runs it sees a value of 3.6G for LSP
1, and 1.8G for LSP 2. The next time autobw runs, it sees 1.8G for LSP 1
and 3.6G for LSP 2. Sometimes it will see 3.6G for both, but mostly it
flips back and forth between double-counting or counting correctly. But
if you watch the ~2 sec updates in monitor label-switched-path, 1.8G is
definitely the accurate number and it doesn't actually swing traffic one
direction or the other. The MPLS stats file shows:

xxx.-xxx.-BRONZE-1104486155 pkt   105218354455 Byte 205197 pps 
212583416 Bps Util 46.00%
xxx.-xxx.-BRONZE-2105659898 pkt   107686862770 Byte 209566 pps 
217065966 Bps Util 45.73%
xxx.-xxx.-BRONZE-1 21935227 pkt22685800299 Byte
xxx.-xxx.-BRONZE-2 21461156 pkt22692594499 Byte
xxx.-xxx.-BRONZE-1 52299821 pkt54299830347 Byte 206561 pps 
215061428 Bps Util 106.20%
xxx.-xxx.-BRONZE-2 53080366 pkt56207186696 Byte 215096 pps 
227990423 Bps Util 108.82%
xxx.-xxx.-BRONZE-1 86602166 pkt90675115910 Byte 221305 pps 
234679261 Bps Util 115.88%
xxx.-xxx.-BRONZE-2 86986993 pkt92238787605 Byte 218752 pps 
232461941 Bps Util 110.95%
xxx.-xxx.-BRONZE-1117133847 pkt   122194831966 Byte 204910 pps 
211541718 Bps Util 104.46%
xxx.-xxx.-BRONZE-2117353905 pkt   123860169099 Byte 203804 pps 
212224036 Bps Util 101.29%
xxx.-xxx.-BRONZE-1 21913950 pkt22743057380 Byte
xxx.-xxx.-BRONZE-2 20881955 pkt21600868242 Byte
xxx.-xxx.-BRONZE-1 55061824 pkt57134656425 Byte 211132 pps 
219054770 Bps Util 48.40%
xxx.-xxx.-BRONZE-2 55272067 pkt57108577385 Byte 217658 pps 
224732336 Bps Util 93.56%
xxx.-xxx.-BRONZE-1 86342525 pkt7335246 Byte 211356 pps 
214545127 Bps Util 47.40%
xxx.-xxx.-BRONZE-2 86516244 pkt88738005437 Byte 212545 pps 
215166177 Bps Util 89.58%
xxx.-xxx.-BRONZE-1118927914 pkt   122308515694 Byte 217235 pps 
222807869 Bps Util 49.23%
xxx.-xxx.-BRONZE-2118667459 pkt   121951530715 Byte 214341 pps 
221423501 Bps Util 92.18%
xxx.-xxx.-BRONZE-1 22959765 pkt23199542774 Byte
xxx.-xxx.-BRONZE-2149388166 pkt   153557687831 Byte 213338 pps 
219487202 Bps Util 91.38%
xxx.-xxx.-BRONZE-1 56033558 pkt56192853447 Byte 209327 pps 
208818421 Bps Util 91.08%
xxx.-xxx.-BRONZE-2183035335 pkt   187926595586 Byte 212956 pps 
217524732 Bps Util 90.56%
xxx.-xxx.-BRONZE-1 87924814 pkt87973385065 Byte 216947 pps 
216194092 Bps Util 94.30%
xxx.-xxx.-BRONZE-2214599264 pkt   219857751942 Byte 214720 pps 
217218750 Bps Util 90.43%
xxx.-xxx.-BRONZE-1121190549 pkt   121835543642 Byte 220302 pps 
224252705 Bps Util 97.81%
xxx.-xxx.-BRONZE-2248148738 pkt   254423414558 Byte 222181 pps 
228911672 Bps Util 95.30%
xxx.-xxx.-BRONZE-1152810797 pkt   154153805842 Byte 219585 pps 
224432376 Bps Util 97.89%
xxx.-xxx.-BRONZE-2 22968975 pkt23490382846 Byte
xxx.-xxx.-BRONZE-1184734907 pkt   186441578904 Byte 207299 pps 
209660864 Bps Util 91.45%
xxx.-xxx.-BRONZE-2 55927141 pkt57401286923 Byte 214014 pps 
220200675 Bps Util 50.62%
xxx.-xxx.-BRONZE-1217200366 pkt   219434061321 Byte 213588 pps 
217055805 Bps Util 94.67%
xxx.-xxx.-BRONZE-2 88453546 pkt90549599056 Byte 212590 pps 
216655634 Bps Util 49.81%
xxx.-xxx.-BRONZE-1249255138 pkt   251947784814 Byte 215132 pps 
218212909 Bps Util 95.18%
xxx.-xxx.-BRONZE-2120676066 pkt   123570161138 Byte 217719 pps 
223111905 Bps Util 51.29%

Note that th

[j-nsp] no family inet6 for vlan.*-interfaces on 10.1R2.8?

[Volker D. Pallas]

Hi,

I just realized that there seems to be no "family inet6" anymore for 
vlan-interfaces since upgrading to junos 10.1R2.8.
Fortunately my old config is still active and working, but I cannot 
modify it:


# show interfaces vlan unit 10
family inet {
address 172.23.5.1/25;
}
family inet6 {
address 2001:4dd0:ff08:10::1/64;
}

# set interfaces vlan unit 10 family ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
> inet IPv4 parameters
> mpls MPLS protocol parameters
> tcc  Translational cross-connect parameters
> vpls Virtual private LAN service parameters

Is this a new feature or a bug?
For interfaces other than vlan.* this is still working as expected.

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

Re: [j-nsp] Auto-bandwidth Accuracy

[Olson, Martin]

Yeah, I can't view that PR either, and it was our JTAC case that
triggered it to be opened.  I don't remember all the details of the
trigger mechanism.  Can anybody get Juniper to make the PR public?

-MO


-Original Message-
From: Phil Bedard [mailto:phil...@gmail.com] 
Sent: Tuesday, May 25, 2010 4:05 PM
To: Olson, Martin
Cc: Danny Vernals; Richard A Steenbergen; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Auto-bandwidth Accuracy

Do you have the detail on PR 457767, it doesn't seem to show up in the
system.   I tried to duplicate 438157 and could never successfully do
so.  

Thanks, 
Phil  

On May 25, 2010, at 3:23 PM, Olson, Martin wrote:

> Yeah, I found the same behavior.  Sometimes the Max AvgBW would go up
by 5X-7X the value it should've, which would lead to really high
reservations after the next adjust-interval.  I opened case
2009-0610-0697 about the issue, and after a while they traced the
problem to PRs 438157 and 457767.  The first code with the fix for both
PRs is 9.6R2/9.5R3/9.4R4/9.3R5.  They told us that if we disabled the
adjust-threshold-overflow-limit in the meantime, that would alleviate
the problem until we upgrade code.
> 
> -MO
> 
> 
> -Original Message-
> From: Danny Vernals [mailto:danny.vern...@gmail.com] 
> Sent: Tuesday, May 25, 2010 5:18 AM
> To: Richard A Steenbergen
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Auto-bandwidth Accuracy
> 
> On Sun, May 23, 2010 at 7:52 AM, Richard A Steenbergen
 wrote:
>> Recently I've been noticing some really odd auto-bandwidth behavior
on
>> several different routers, and I'm wondering if anybody knows if this
is
>> a known bug or if I'm doing something really wrong in my autobw
config.
>> 
>> Specifically, I'm seeing many cases where the rsvp reservations on an
>> interface are vastly higher than the actual traffic going over it. I
>> started comparing autobw measures bandwidth value vs rsvp resv
bandwidth
>> across my LSPs (with an op script :P), and noticed that a large
number
>> of LSPs that were ingress on Juniper routers were consistently
reserving
>> more bandwidth than they were actually passing.
>> 
>> To troubleshoot this further, I picked one LSP at random and followed
it
>> through the course of an entire adjust-interval. I also watched it in
>> "monitor label-switched-path", and followed the bandwidth recorded
for
>> it in the mpls stats file. The mpls stats file pretty consistently
>> recorded a bandwidth of around 900Mbps. Some samples were up to 1G,
some
>> were down in the 800Mb's, but nothing was significantly outside this
>> range:
>> 
>> xxx.-xxx.-BRONZE-1 20442770 pkt21800398308 Byte
91864 pps 97826023 Bps Util 43.47%
>> xxx.-xxx.-BRONZE-1 25748678 pkt27500224526 Byte
89930 pps 96607224 Bps Util 42.93%
>> xxx.-xxx.-BRONZE-1 31309754 pkt33516047564 Byte
95880 pps 103721086 Bps Util 46.09%
>> xxx.-xxx.-BRONZE-1 36934965 pkt39389728013 Byte
90729 pps 94736781 Bps Util 42.10%
>> xxx.-xxx.-BRONZE-1 41323164 pkt44001156442 Byte
86043 pps 90420165 Bps Util 40.18%
>> xxx.-xxx.-BRONZE-1 46229207 pkt49166295068 Byte
84586 pps 89054114 Bps Util 39.58%
>> xxx.-xxx.-BRONZE-1 51764861 pkt55023074603 Byte
92260 pps 97612992 Bps Util 43.38%
>> xxx.-xxx.-BRONZE-1 57091315 pkt60691783494 Byte
90278 pps 96079811 Bps Util 42.70%
>> xxx.-xxx.-BRONZE-1 62138489 pkt66009079194 Byte
90128 pps 94951708 Bps Util 42.20%
>> xxx.-xxx.-BRONZE-1 67697838 pkt72030553645 Byte
92655 pps 100357907 Bps Util 44.60%
>> xxx.-xxx.-BRONZE-1 73083250 pkt77870203449 Byte
89756 pps 97327496 Bps Util 43.25%
>> xxx.-xxx.-BRONZE-1 78530642 pkt83799427998 Byte
90789 pps 98820409 Bps Util 43.91%
>> xxx.-xxx.-BRONZE-1 84166327 pkt89767404007 Byte
85389 pps 90423878 Bps Util 40.18%
>> xxx.-xxx.-BRONZE-1 89990750 pkt96052103366 Byte
85653 pps 92422049 Bps Util 41.07%
>> xxx.-xxx.-BRONZE-1 94808838 pkt   101299936674 Byte
87601 pps 95415151 Bps Util 42.40%
>> xxx.-xxx.-BRONZE-1100044983 pkt   106918990604 Byte
83113 pps 89191332 Bps Util 39.64%
>> xxx.-xxx.-BRONZE-1104706036 pkt   111928263183 Byte
86315 pps 92764307 Bps Util 41.22%
>> xxx.-xxx.-BRONZE-1109664547 pkt   117256403183 Byte
81287 pps 87346557 Bps Util 38.82%
>> xxx.-xxx.-BRONZE-1115001230 pkt   123065374817 Byte
84709 pps 92205898 Bps Util 40.98%
>> xxx.-xxx.-BRONZE-1120197917 pkt   128761293505 Byte
85191 pps 93375716 Bps Util 41.50%
>> xxx.-xxx.-BRONZE-1124790487 pkt   133783111501 Byte
79182 pps 86583068 Bps Util 38.48%
>> xxx.-xxx.-BRONZE-1129450091 pkt   138908431043 Byte
84720 pps 93187628 Bps Util 41.41%
>> xxx.-xxx.-BRONZE-1134048794 pkt   143940227806 Byte
82119 pps 89853513 Bps Util 39.93%
>> xxx.-xxx.-BRONZE-1138900130 pkt   1

Re: [j-nsp] l2circuit communities

[Phil Bedard]

On May 25, 2010, at 3:21 AM, Richard A Steenbergen wrote:

> On Mon, May 24, 2010 at 07:46:17PM -0400, Phil Bedard wrote:
>> A little different scenario but I'm using CBF with a cos next-hop-map
>> to set specific lsp-next-hops for CoS classes, also using autobw, and
>> I'm not seeing similar behavior. 
>> 
>> One thing I noticed is while the router is doing the MBB/re-signal the
>> "ActiveRoute" value will drop to 0, but then it immediately goes back
>> up to the prior value, so it makes you wonder what's going on behind
>> the scenes. 
>> 
>> I'm using 9.3R3.8, hope thing isn't something introduced later... 
>> 
>> Are your paths actually changing output interfaces/paths or is it just
>> a BW re-signal? 
> 
> Just doing a bandwidth resignal, nothing else is changing. I see the 
> same behavior with the ActiveRoute count, it drops to 0 for about 14 
> seconds after the resignal, then pops back up to where it was before.
> 
> I don't have anything in the 9.3's to test, but 9.6S5 is definitely
> doing the same thing. I also confirmed that the route changes in
> rtsockmon are from routes pointing to LSPs which just resignaled, which
> stops as soon as the install-nexthop config goes away. I'm not
> particularly interested in going to a full cos next-hop-map setup, but
> this is definitely broken as-is. :)
> 

I ran some tests with autobw, cos next-hop map, and your method of installing 
lsp next-hops 
based on communities to see what the CPU looked like.  I tested this against 
9.3R3.8 on an M320 and 10.2R1.3 on an MX960.  

With the cos next-hop map the RPD CPU usage was roughly double what it was 
without the cos next-hop map.  Without it, the M320 hit 
10-12% CPU during a re-signal and the MX960 was 15-18%.   With the cos 
next-hop-map I'd see it jump to ~24% on the M320 and hit a 
peak of 40% on the MX960.  
 
Both normal autobw and the cos next-hop-map consistently used more CPU on the 
MX960 with the RE-2000 than 
the M320 with the RE-1600.  One thing I noticed is on the 10.2 MX960 box I saw 
more change messages via rtsockmon 
than with the 9.3R3.8 box.  I had static routes pointed to the LSPs in order to 
vary the BW on them and every time 
one re-signaled I'd see a nh change for the static route.  I also saw indirect 
nh changes.   On the 9.3R3.8 box I 
never saw the change messages.  

The test installing the lsp next-hop via communities would bring both boxes up 
to 70-95% during LSP re-signals and 
result in seeing a change for each individual route using the LSP.   

The tests were done with 400k BGP prefixes reachable via a set of 10 LSPs with 
autobw enabled.  Traffic was varied 
across the LSPs to get them to re-signal every 5 minutes.   

Phil 










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

Re: [j-nsp] Auto-bandwidth Accuracy

[Phil Bedard]

Do you have the detail on PR 457767, it doesn't seem to show up in the system.  
 I tried to duplicate 438157 and could never successfully do so.  

Thanks, 
Phil  

On May 25, 2010, at 3:23 PM, Olson, Martin wrote:

> Yeah, I found the same behavior.  Sometimes the Max AvgBW would go up by 
> 5X-7X the value it should've, which would lead to really high reservations 
> after the next adjust-interval.  I opened case 2009-0610-0697 about the 
> issue, and after a while they traced the problem to PRs 438157 and 457767.  
> The first code with the fix for both PRs is 9.6R2/9.5R3/9.4R4/9.3R5.  They 
> told us that if we disabled the adjust-threshold-overflow-limit in the 
> meantime, that would alleviate the problem until we upgrade code.
> 
> -MO
> 
> 
> -Original Message-
> From: Danny Vernals [mailto:danny.vern...@gmail.com] 
> Sent: Tuesday, May 25, 2010 5:18 AM
> To: Richard A Steenbergen
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Auto-bandwidth Accuracy
> 
> On Sun, May 23, 2010 at 7:52 AM, Richard A Steenbergen  
> wrote:
>> Recently I've been noticing some really odd auto-bandwidth behavior on
>> several different routers, and I'm wondering if anybody knows if this is
>> a known bug or if I'm doing something really wrong in my autobw config.
>> 
>> Specifically, I'm seeing many cases where the rsvp reservations on an
>> interface are vastly higher than the actual traffic going over it. I
>> started comparing autobw measures bandwidth value vs rsvp resv bandwidth
>> across my LSPs (with an op script :P), and noticed that a large number
>> of LSPs that were ingress on Juniper routers were consistently reserving
>> more bandwidth than they were actually passing.
>> 
>> To troubleshoot this further, I picked one LSP at random and followed it
>> through the course of an entire adjust-interval. I also watched it in
>> "monitor label-switched-path", and followed the bandwidth recorded for
>> it in the mpls stats file. The mpls stats file pretty consistently
>> recorded a bandwidth of around 900Mbps. Some samples were up to 1G, some
>> were down in the 800Mb's, but nothing was significantly outside this
>> range:
>> 
>> xxx.-xxx.-BRONZE-1 20442770 pkt21800398308 Byte  91864 pps 
>> 97826023 Bps Util 43.47%
>> xxx.-xxx.-BRONZE-1 25748678 pkt27500224526 Byte  89930 pps 
>> 96607224 Bps Util 42.93%
>> xxx.-xxx.-BRONZE-1 31309754 pkt33516047564 Byte  95880 pps 
>> 103721086 Bps Util 46.09%
>> xxx.-xxx.-BRONZE-1 36934965 pkt39389728013 Byte  90729 pps 
>> 94736781 Bps Util 42.10%
>> xxx.-xxx.-BRONZE-1 41323164 pkt44001156442 Byte  86043 pps 
>> 90420165 Bps Util 40.18%
>> xxx.-xxx.-BRONZE-1 46229207 pkt49166295068 Byte  84586 pps 
>> 89054114 Bps Util 39.58%
>> xxx.-xxx.-BRONZE-1 51764861 pkt55023074603 Byte  92260 pps 
>> 97612992 Bps Util 43.38%
>> xxx.-xxx.-BRONZE-1 57091315 pkt60691783494 Byte  90278 pps 
>> 96079811 Bps Util 42.70%
>> xxx.-xxx.-BRONZE-1 62138489 pkt66009079194 Byte  90128 pps 
>> 94951708 Bps Util 42.20%
>> xxx.-xxx.-BRONZE-1 67697838 pkt72030553645 Byte  92655 pps 
>> 100357907 Bps Util 44.60%
>> xxx.-xxx.-BRONZE-1 73083250 pkt77870203449 Byte  89756 pps 
>> 97327496 Bps Util 43.25%
>> xxx.-xxx.-BRONZE-1 78530642 pkt83799427998 Byte  90789 pps 
>> 98820409 Bps Util 43.91%
>> xxx.-xxx.-BRONZE-1 84166327 pkt89767404007 Byte  85389 pps 
>> 90423878 Bps Util 40.18%
>> xxx.-xxx.-BRONZE-1 89990750 pkt96052103366 Byte  85653 pps 
>> 92422049 Bps Util 41.07%
>> xxx.-xxx.-BRONZE-1 94808838 pkt   101299936674 Byte  87601 pps 
>> 95415151 Bps Util 42.40%
>> xxx.-xxx.-BRONZE-1100044983 pkt   106918990604 Byte  83113 pps 
>> 89191332 Bps Util 39.64%
>> xxx.-xxx.-BRONZE-1104706036 pkt   111928263183 Byte  86315 pps 
>> 92764307 Bps Util 41.22%
>> xxx.-xxx.-BRONZE-1109664547 pkt   117256403183 Byte  81287 pps 
>> 87346557 Bps Util 38.82%
>> xxx.-xxx.-BRONZE-1115001230 pkt   123065374817 Byte  84709 pps 
>> 92205898 Bps Util 40.98%
>> xxx.-xxx.-BRONZE-1120197917 pkt   128761293505 Byte  85191 pps 
>> 93375716 Bps Util 41.50%
>> xxx.-xxx.-BRONZE-1124790487 pkt   133783111501 Byte  79182 pps 
>> 86583068 Bps Util 38.48%
>> xxx.-xxx.-BRONZE-1129450091 pkt   138908431043 Byte  84720 pps 
>> 93187628 Bps Util 41.41%
>> xxx.-xxx.-BRONZE-1134048794 pkt   143940227806 Byte  82119 pps 
>> 89853513 Bps Util 39.93%
>> xxx.-xxx.-BRONZE-1138900130 pkt   149257983679 Byte  80855 pps 
>> 88629264 Bps Util 39.39%
>> xxx.-xxx.-BRONZE-1143665805 pkt   154447812210 Byte  79427 pps 
>> 86497142 Bps Util 38.44%
>> xxx.-xxx.-BRONZE-1148501587 pkt   159667032930 Byte  80596 pps 
>> 86987012 Bps Util 38.66%
>> xxx.-xxx.-BRONZE-1153971586

Re: [j-nsp] Auto-bandwidth Accuracy

[Olson, Martin]

Yeah, I found the same behavior.  Sometimes the Max AvgBW would go up by 5X-7X 
the value it should've, which would lead to really high reservations after the 
next adjust-interval.  I opened case 2009-0610-0697 about the issue, and after 
a while they traced the problem to PRs 438157 and 457767.  The first code with 
the fix for both PRs is 9.6R2/9.5R3/9.4R4/9.3R5.  They told us that if we 
disabled the adjust-threshold-overflow-limit in the meantime, that would 
alleviate the problem until we upgrade code.

-MO


-Original Message-
From: Danny Vernals [mailto:danny.vern...@gmail.com] 
Sent: Tuesday, May 25, 2010 5:18 AM
To: Richard A Steenbergen
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Auto-bandwidth Accuracy

On Sun, May 23, 2010 at 7:52 AM, Richard A Steenbergen  
wrote:
> Recently I've been noticing some really odd auto-bandwidth behavior on
> several different routers, and I'm wondering if anybody knows if this is
> a known bug or if I'm doing something really wrong in my autobw config.
>
> Specifically, I'm seeing many cases where the rsvp reservations on an
> interface are vastly higher than the actual traffic going over it. I
> started comparing autobw measures bandwidth value vs rsvp resv bandwidth
> across my LSPs (with an op script :P), and noticed that a large number
> of LSPs that were ingress on Juniper routers were consistently reserving
> more bandwidth than they were actually passing.
>
> To troubleshoot this further, I picked one LSP at random and followed it
> through the course of an entire adjust-interval. I also watched it in
> "monitor label-switched-path", and followed the bandwidth recorded for
> it in the mpls stats file. The mpls stats file pretty consistently
> recorded a bandwidth of around 900Mbps. Some samples were up to 1G, some
> were down in the 800Mb's, but nothing was significantly outside this
> range:
>
> xxx.-xxx.-BRONZE-1     20442770 pkt    21800398308 Byte  91864 pps 
> 97826023 Bps Util 43.47%
> xxx.-xxx.-BRONZE-1     25748678 pkt    27500224526 Byte  89930 pps 
> 96607224 Bps Util 42.93%
> xxx.-xxx.-BRONZE-1     31309754 pkt    33516047564 Byte  95880 pps 
> 103721086 Bps Util 46.09%
> xxx.-xxx.-BRONZE-1     36934965 pkt    39389728013 Byte  90729 pps 
> 94736781 Bps Util 42.10%
> xxx.-xxx.-BRONZE-1     41323164 pkt    44001156442 Byte  86043 pps 
> 90420165 Bps Util 40.18%
> xxx.-xxx.-BRONZE-1     46229207 pkt    49166295068 Byte  84586 pps 
> 89054114 Bps Util 39.58%
> xxx.-xxx.-BRONZE-1     51764861 pkt    55023074603 Byte  92260 pps 
> 97612992 Bps Util 43.38%
> xxx.-xxx.-BRONZE-1     57091315 pkt    60691783494 Byte  90278 pps 
> 96079811 Bps Util 42.70%
> xxx.-xxx.-BRONZE-1     62138489 pkt    66009079194 Byte  90128 pps 
> 94951708 Bps Util 42.20%
> xxx.-xxx.-BRONZE-1     67697838 pkt    72030553645 Byte  92655 pps 
> 100357907 Bps Util 44.60%
> xxx.-xxx.-BRONZE-1     73083250 pkt    77870203449 Byte  89756 pps 
> 97327496 Bps Util 43.25%
> xxx.-xxx.-BRONZE-1     78530642 pkt    83799427998 Byte  90789 pps 
> 98820409 Bps Util 43.91%
> xxx.-xxx.-BRONZE-1     84166327 pkt    89767404007 Byte  85389 pps 
> 90423878 Bps Util 40.18%
> xxx.-xxx.-BRONZE-1     89990750 pkt    96052103366 Byte  85653 pps 
> 92422049 Bps Util 41.07%
> xxx.-xxx.-BRONZE-1     94808838 pkt   101299936674 Byte  87601 pps 
> 95415151 Bps Util 42.40%
> xxx.-xxx.-BRONZE-1    100044983 pkt   106918990604 Byte  83113 pps 
> 89191332 Bps Util 39.64%
> xxx.-xxx.-BRONZE-1    104706036 pkt   111928263183 Byte  86315 pps 
> 92764307 Bps Util 41.22%
> xxx.-xxx.-BRONZE-1    109664547 pkt   117256403183 Byte  81287 pps 
> 87346557 Bps Util 38.82%
> xxx.-xxx.-BRONZE-1    115001230 pkt   123065374817 Byte  84709 pps 
> 92205898 Bps Util 40.98%
> xxx.-xxx.-BRONZE-1    120197917 pkt   128761293505 Byte  85191 pps 
> 93375716 Bps Util 41.50%
> xxx.-xxx.-BRONZE-1    124790487 pkt   133783111501 Byte  79182 pps 
> 86583068 Bps Util 38.48%
> xxx.-xxx.-BRONZE-1    129450091 pkt   138908431043 Byte  84720 pps 
> 93187628 Bps Util 41.41%
> xxx.-xxx.-BRONZE-1    134048794 pkt   143940227806 Byte  82119 pps 
> 89853513 Bps Util 39.93%
> xxx.-xxx.-BRONZE-1    138900130 pkt   149257983679 Byte  80855 pps 
> 88629264 Bps Util 39.39%
> xxx.-xxx.-BRONZE-1    143665805 pkt   154447812210 Byte  79427 pps 
> 86497142 Bps Util 38.44%
> xxx.-xxx.-BRONZE-1    148501587 pkt   159667032930 Byte  80596 pps 
> 86987012 Bps Util 38.66%
> xxx.-xxx.-BRONZE-1    153971586 pkt   165650360517 Byte  78142 pps 
> 85476108 Bps Util 37.99%
>
> Next, I watched the output of "show mpls lsp name BLAH detail", looking
> at the autobw measured amount (Max AvgBW) and the reserved bandwidth.
> I'm using a stats interval of 60 seconds, an adjust-interval of 900
> seconds, and in this instance no overflow sample

Re: [j-nsp] WebVPN Problem / SRX

[Paul Stewart]

Thanks - yes, there is a policy almost identical to that.. Missed posting
that, sorry.

 

I think the problem has been discovered already though - it appears that
XAuth requires Radius and there is no way around it that I've been able to
find.  Due to the low volume of users on this box we wanted to just use
local users but looks like I'm SOL on that.;)

 

Paul

 

 

From: Tim Jackson [mailto:jackson@gmail.com] 
Sent: Tuesday, May 25, 2010 2:13 PM
To: Paul Stewart
Cc: jnsp
Subject: Re: [j-nsp] WebVPN Problem / SRX

 

Do you have a policy in place like:

 

security {

 policies {

  from-zone untrust to-zone trust {

   policy leo-vpn {

 match {

   source-address any;

   destination-address any;

   application any;

  }

  then {

permit {

  tunnel {

ipsec-vpn leo;

  }

 }

}

   }

}

}

 

 

  

 

On Tue, May 25, 2010 at 12:14 PM, Paul Stewart  wrote:

Anyone on here setup WebVPN on Juniper SRX?  I've had a JTAC ticket running
for quite a while and they haven't been able to figure out why we can't
connect.  according to the logs the username is getting authenticated and
then the session drops for some reason.. I'm about 6-7 hours on the phone
with JTAC so far - hoping someone has some ideas ;)



Thanks ;)





SRX210 running 10.0R3.10



access {

   profile user-auth-profile {

   client leo {

   firewall-user {

   password ""; ## SECRET-DATA

   }

   }

   }

   firewall-authentication {

   web-authentication {

   default-profile user-auth-profile;

   }

   }

}





security {

   ike {

   traceoptions {

   flag all;

   }

   proposal phase1-prop {

   authentication-method pre-shared-keys;

   dh-group group5;

   authentication-algorithm sha-256;

   encryption-algorithm aes-256-cbc;

   }

   policy ike-pol {

   mode aggressive;

   proposals phase1-prop;

   pre-shared-key ascii-text "xxx"; ##
SECRET-DATA

   }

   gateway leo {

   ike-policy ike-pol;

   dynamic hostname leo;

   external-interface ge-0/0/0.0;

   xauth access-profile user-auth-profile;

   }

   }

   ipsec {

   proposal phase2-prop {

   protocol esp;

   authentication-algorithm hmac-sha1-96;

   encryption-algorithm aes-256-cbc;

   }

   policy ipsec-pol {

   perfect-forward-secrecy {

   keys group2;

   }

   proposals phase2-prop;

   }

   vpn leo {

   ike {

   gateway leo;

   ipsec-policy ipsec-pol;

   }

   }

   }



  zones {

   security-zone untrust {

   screen untrust-screen;

   interfaces {

   ge-0/0/0.0 {

   host-inbound-traffic {

   system-services {

   dhcp;

   tftp;

   https;

   ssh;

   ping;

   snmp;

   ike;

   }

   }

   }

   }

   }

   }





   dynamic-vpn {

   access-profile user-auth-profile;

   clients {

   leo {

   remote-protected-resources {

   10.1.1.0/24;

   }

   remote-exceptions {

   0.0.0.0/0;

   }

   ipsec-vpn leo;

   user {

   leo;

   }

   }

   }

   }

}

___
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] WebVPN Problem / SRX

[Tim Jackson]

Do you have a policy in place like:

security {
 policies {
  from-zone untrust to-zone trust {
   policy leo-vpn {
 match {
   source-address any;
   destination-address any;
   application any;
  }
  then {
permit {
  tunnel {
ipsec-vpn leo;
  }
 }
}
   }
}
}




On Tue, May 25, 2010 at 12:14 PM, Paul Stewart  wrote:

> Anyone on here setup WebVPN on Juniper SRX?  I've had a JTAC ticket running
> for quite a while and they haven't been able to figure out why we can't
> connect.  according to the logs the username is getting authenticated and
> then the session drops for some reason.. I'm about 6-7 hours on the phone
> with JTAC so far - hoping someone has some ideas ;)
>
>
>
> Thanks ;)
>
>
>
>
>
> SRX210 running 10.0R3.10
>
>
>
> access {
>
>profile user-auth-profile {
>
>client leo {
>
>firewall-user {
>
>password ""; ## SECRET-DATA
>
>}
>
>}
>
>}
>
>firewall-authentication {
>
>web-authentication {
>
>default-profile user-auth-profile;
>
>}
>
>}
>
> }
>
>
>
>
>
> security {
>
>ike {
>
>traceoptions {
>
>flag all;
>
>}
>
>proposal phase1-prop {
>
>authentication-method pre-shared-keys;
>
>dh-group group5;
>
>authentication-algorithm sha-256;
>
>encryption-algorithm aes-256-cbc;
>
>}
>
>policy ike-pol {
>
>mode aggressive;
>
>proposals phase1-prop;
>
>pre-shared-key ascii-text "xxx"; ##
> SECRET-DATA
>
>}
>
>gateway leo {
>
>ike-policy ike-pol;
>
>dynamic hostname leo;
>
>external-interface ge-0/0/0.0;
>
>xauth access-profile user-auth-profile;
>
>}
>
>}
>
>ipsec {
>
>proposal phase2-prop {
>
>protocol esp;
>
>authentication-algorithm hmac-sha1-96;
>
>encryption-algorithm aes-256-cbc;
>
>}
>
>policy ipsec-pol {
>
>perfect-forward-secrecy {
>
>keys group2;
>
>}
>
>proposals phase2-prop;
>
>}
>
>vpn leo {
>
>ike {
>
>gateway leo;
>
>ipsec-policy ipsec-pol;
>
>}
>
>}
>
>}
>
>
>
>   zones {
>
>security-zone untrust {
>
>screen untrust-screen;
>
>interfaces {
>
>ge-0/0/0.0 {
>
>host-inbound-traffic {
>
>system-services {
>
>dhcp;
>
>tftp;
>
>https;
>
>ssh;
>
>ping;
>
>snmp;
>
>ike;
>
>}
>
>}
>
>}
>
>}
>
>}
>
>}
>
>
>
>
>
>dynamic-vpn {
>
>access-profile user-auth-profile;
>
>clients {
>
>leo {
>
>remote-protected-resources {
>
>10.1.1.0/24;
>
>}
>
>remote-exceptions {
>
>0.0.0.0/0;
>
>}
>
>ipsec-vpn leo;
>
>user {
>
>leo;
>
>}
>
>}
>
>}
>
>}
>
> }
>
> ___
> 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] What's the latest code you're running on a mx?

[Serge Vautour]

Hello,

I for one am happy to hear this. We're very close to deploying a new MPLS 
network all on MX960s. We did heavy testing on 10.0R2 earlier this year. Our 
lab gear has all been updated to 10.0R3 and so far everything seems to work. 
We're running:

-IGP: OSPF (1 area 0, no TED) with OSPF LFA
-L2VPN, VPLS, L3VPN with BGP signaling
-LDP for transport LSPs
-No RSVP
-Simple Core QoS model with edge BA pbit classifiers

Some interesting things to note:

-OSPF LFA: I had to open a case with JTAC on this. The "traceroute mpls ldp" 
command uses both the primary and backup LFA paths. JTAC thinks this is a 
problem with the traceroute command and not OSPF LFA. When I simulate traffic 
through the network, it does always appear to use the primary LFA path only. I 
wish I new their ECMP algorithm to know for sure...

-no-tunnel-services: I can consistently get the box to core dump by creating a 
VPLS Routing Instance without no-tunnel-services, adding no-tunnel-services and 
then doing a commit full. Case pending. Work around: using groups to make sure 
parameters like no-tunnel-services are always on first time around.

-l3vpn-composite: This is suppose to add efficiencies for L3VPN but it breaks 
VPLS & L2VPN. PR opened in 10.0R2. I don't think it's fixed yet.

-Egress PE custom MPLS exp Classifier is broke for VPLS & L3VPN. As a 
workaround, you have to apply your classifier like so:

show configuration class-of-service routing-instances 
all {
classifiers {
exp mpls-core-classifier;
}
}

Otherwise the default MPLS exp classifier is used. 

-We wanted to put fxp0 in a dedicated Logical System to solve return route 
problems (some traffic is InBand, some is Out of Band via fxp0 - don't ask). 
This solves the routing problem but breaks NSR. 


Everything else seems to be working as expected. The problems listed above are 
somewhat minor and we can work around them. 10.0R3 did core dump a few times 
during a training session. We had 8 people all making config changes at the 
same time in the same "edit". JTAC is analyzing. It's the only item that's 
making me a bit nervous. I'm hoping to limit simultaneous access (edit 
exclusive) in Prod to limit this.

Does anyone else have anything to share? I'd certain like to know if there's 
anybody else beating up 10.0R3 in the lab or running it in Prod. If we have a 
similar setup, I'd even be willing to replicate a problem anyone else might be 
having. Ping me off list if necessary.

Thanks,
Serge





- Original Message 
From: David Ball 
To: mti...@globaltransit.net
Cc: Richard A Steenbergen ; juniper-nsp@puck.nether.net
Sent: Tue, May 25, 2010 12:58:06 PM
Subject: Re: [j-nsp] What's the latest code you're running on a mx?

  Just a followup on this thread.  I've been testing 10.0R3.10 in the
lab with MX240, 480 and T640 and have had (somewhat surprisingly) good
results.  L2VPN, L2ckt, BGP-signalled VPLS (all w/QoS), L3VPN, LDP &
RSVP w/FRR (haven't tested much TE yet, mind you), even dabbled in
loop-free alternates (on the MX240 only), and haven't hit any
show-stoppers *yet*.  We're definitely SP-focused, not enterprise, so
YMMV.  They've even fixed (?) the functionality which broke (?) around
late 9.2 to early 9.3 timeframe which prevented you from doing 802.1p
BA classification on an outer VLAN tag if you were removing the outer
tag on ingress (they added a flag somewhere where you can specify
'inner' if you need to).

  It's said to have several fixes for the now infamous KRT Queue
issues as well, which have been discussed at length on the list.  I'm
cautiously optimistic about that one.

  That saideverything works in the lab, right?

David


On 1 May 2010 12:57, Mark Tinka  wrote:
> On Sunday 02 May 2010 01:31:44 am Richard A Steenbergen
> wrote:
>
>> Don't try to compare code between platforms, they're
>>  entirely different beasts. :) In my experience the
>>  answer for EX is almost always "run the latest and
>>  greatest", and our deployment tests w/EX8216s and 10.1S1
>>  have actually been much better than I expected.
>>
>> In the end it all comes down to which features are you
>>  using, and what expectations do you have from your
>>  router. Layer 2 is dirt simple, hell even Foundry
>>  managed to mostly get that one right, so I have no doubt
>>  that if your configuration and network are simple enough
>>  you'll probably never see an issue. Try running a full
>>  routing service provider config with bgp isis mpls rsvp
>>  l2circuits firewalls etc and it's completely different
>>  story. :)
>
> I probably should have stated that "any platform" was
> confined to the latter case you describe, service provider
> routing and friends.
>
> We've had luck running code on core and edge switches in
> pure Layer 2 mode that have brought other networks to tears
> when Layer 3 services are turned on. Code stability
> requirements between either paradigm is sufficiently
> distinguishable, most times :-).
>
> Even though the platforms have s

[j-nsp] WebVPN Problem / SRX

[Paul Stewart]

Anyone on here setup WebVPN on Juniper SRX?  I've had a JTAC ticket running
for quite a while and they haven't been able to figure out why we can't
connect.  according to the logs the username is getting authenticated and
then the session drops for some reason.. I'm about 6-7 hours on the phone
with JTAC so far - hoping someone has some ideas ;)

 

Thanks ;)

 

 

SRX210 running 10.0R3.10

 

access {

profile user-auth-profile {

client leo {

firewall-user {

password ""; ## SECRET-DATA

}

}

}

firewall-authentication {

web-authentication {

default-profile user-auth-profile;

}

}

}

 

 

security {

ike {

traceoptions {

flag all;

}

proposal phase1-prop {

authentication-method pre-shared-keys;

dh-group group5;

authentication-algorithm sha-256;

encryption-algorithm aes-256-cbc;

}

policy ike-pol {

mode aggressive;

proposals phase1-prop;

pre-shared-key ascii-text "xxx"; ##
SECRET-DATA

}

gateway leo {

ike-policy ike-pol;

dynamic hostname leo;

external-interface ge-0/0/0.0;

xauth access-profile user-auth-profile;

}

}

ipsec {

proposal phase2-prop {

protocol esp;

authentication-algorithm hmac-sha1-96;

encryption-algorithm aes-256-cbc;

}

policy ipsec-pol {

perfect-forward-secrecy {

keys group2;

}

proposals phase2-prop;

}

vpn leo {

ike {

gateway leo;

ipsec-policy ipsec-pol;

}

}

}

 

   zones {

security-zone untrust {

screen untrust-screen;

interfaces {

ge-0/0/0.0 {

host-inbound-traffic {

system-services {

dhcp;

tftp;

https;

ssh;

ping;

snmp;

ike;

}

}

}

}

}

}

 

 

dynamic-vpn {

access-profile user-auth-profile;

clients {

leo {

remote-protected-resources {

10.1.1.0/24;

}

remote-exceptions {

0.0.0.0/0;

}

ipsec-vpn leo;

user {

leo;

}

}

}

}

}

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

Re: [j-nsp] What's the latest code you're running on a mx?

[David Ball]

  Just a followup on this thread.  I've been testing 10.0R3.10 in the
lab with MX240, 480 and T640 and have had (somewhat surprisingly) good
results.  L2VPN, L2ckt, BGP-signalled VPLS (all w/QoS), L3VPN, LDP &
RSVP w/FRR (haven't tested much TE yet, mind you), even dabbled in
loop-free alternates (on the MX240 only), and haven't hit any
show-stoppers *yet*.  We're definitely SP-focused, not enterprise, so
YMMV.  They've even fixed (?) the functionality which broke (?) around
late 9.2 to early 9.3 timeframe which prevented you from doing 802.1p
BA classification on an outer VLAN tag if you were removing the outer
tag on ingress (they added a flag somewhere where you can specify
'inner' if you need to).

  It's said to have several fixes for the now infamous KRT Queue
issues as well, which have been discussed at length on the list.  I'm
cautiously optimistic about that one.

  That saideverything works in the lab, right?

David


On 1 May 2010 12:57, Mark Tinka  wrote:
> On Sunday 02 May 2010 01:31:44 am Richard A Steenbergen
> wrote:
>
>> Don't try to compare code between platforms, they're
>>  entirely different beasts. :) In my experience the
>>  answer for EX is almost always "run the latest and
>>  greatest", and our deployment tests w/EX8216s and 10.1S1
>>  have actually been much better than I expected.
>>
>> In the end it all comes down to which features are you
>>  using, and what expectations do you have from your
>>  router. Layer 2 is dirt simple, hell even Foundry
>>  managed to mostly get that one right, so I have no doubt
>>  that if your configuration and network are simple enough
>>  you'll probably never see an issue. Try running a full
>>  routing service provider config with bgp isis mpls rsvp
>>  l2circuits firewalls etc and it's completely different
>>  story. :)
>
> I probably should have stated that "any platform" was
> confined to the latter case you describe, service provider
> routing and friends.
>
> We've had luck running code on core and edge switches in
> pure Layer 2 mode that have brought other networks to tears
> when Layer 3 services are turned on. Code stability
> requirements between either paradigm is sufficiently
> distinguishable, most times :-).
>
> Even though the platforms have some key differences, I'd be
> just as cautious running JUNOS 10.x on the M320, T640, M10i,
> e.t.c., as much as I would on the MX. But I guess this goes
> without saying for many :-).
>
> Cheers,
>
> Mark.
>
> ___
> 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] ISIS Queries (ref-bw & L1 metric)

[Jking T]

Hi Experts,

I have couple of queries on IS-IS

1) Just wondering what reference-bandwidth value in "show isis overview" 
indicates?? 
We have set reference-bandwidth as 1000g for ISIS. (We dont see this output 
with routers not having reference-bandwidth command)

l...@mumbdst1> show isis overview 
Instance: master
  Router ID: x.x.x.x
  Adjacency holddown: enabled
  Maximum Areas: 3
  LSP life time: 65535
  Reference bandwidth: 3567587328  <<<---
  Attached bit evaluation: enabled
  SPF delay: 200 msec, SPF holddown: 5000 msec, SPF rapid runs: 3
  IPv4 is enabled, IPv6 is enabled
  Traffic engineering: enabled
  Restart: Enabled
    Restart duration: 200 sec
    Helper mode: Enabled
  Level 1
    Internal route preference: 15
    External route preference: 160
    Wide metrics are enabled, Narrow metrics are enabled
  Level 2
    Internal route preference: 18
    External route preference: 165
    Wide metrics are enabled

2) We have few routers in the setup & all in Level-2. (Level1 disabled). In 
that case, shouldnt we expect not to see Level1 Metric information in both the 
outputs???

l...@mumbdst1> show isis interface 
IS-IS interface database:
Interface L CirID Level 1 DR    Level 2 DR    L1/L2 Metric
lo0.0    0   0x1 Passive   Passive 0/0
xe-0/0/0.0    2   0x1 Disabled  Point to Point    
100/10  
ge-1/0/0.0    2   0x1 Disabled  Point to Point    100/1000

Any thoughts??

Thank you.

Regards,
JK


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

[j-nsp] Strange Link down problems on M-series

[Joerg Staedele]

Hi,

i currently don't have any more ideas on a really strange problem:

Router A is connected to Router B via a Colt Gigabit-Ethernet Link. The Link is 
on a dark fiber and only two ADVA converters are installed. The link was 
working for nearly two years now and suddenly we have big problems.

Router A and Router B tell that the link goes down very often, but only for 
some msecs (I checked that with setting hold-time down 1000 and the problem was 
"gone").

We already moved the link from Router B to Router C (same location) and the 
problem was still there, so Router B seems to be ok.

Then we moved the link from Router A to Switch A (same location) and then 
Router B told us again that the link is down but the Switch (in this case a 
Cisco 3550) didn’t show anything in the log (no interface down, crc errors 
etc.).

We also connected the link on another interface on Router A but the problem 
persists.

If I look on the ge-pic in the Junipers, I see that there are many interrupts 
("Normal interrupts are enabled, total count is 5412")

Colt already replaced their Converters and checked the link and they say 
everything is fine ... but it is not, at least not for our Juniper Routers.

Anyone has an idea or hint what else we can try?

Best regards and thanks,

 Joerg


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

Re: [j-nsp] Encrypt GRE tunnel with ipsec

[Nick Ryce]

Hi Ben,

Its 9.6 im using which I believe ES was rolled into this.  I will look at the 
docs provided :)  Sounds like exactly what I require.

Nick

-Original Message-
From: Ben Dale [mailto:bd...@comlinx.com.au]
Sent: 25 May 2010 12:03
To: Nick Ryce
Cc: Jonathan Looney; J NSP
Subject: Re: [j-nsp] Encrypt GRE tunnel with ipsec

Hi Nick,

> Im using a J6350.
>
> All im trying to to is create a secure tunnel between 2 juniper routers and 
> route traffic down the tunnel without having to specify what specific source 
> destination ranges to encrypt.  Ie if a packet is destined to go down the 
> tunnel then encrypt.

I'll assume you're using JUNOS-ES here so you don't require the use of GRE.  In 
a nutshell, set up your VPN, bind it to your st (secure tunnel) interface and 
place the st interface into it's own security-zone.  Then simply route traffic 
destined for the VPN to the st interface and have a policy to allow it with the 
action "permit".  You can also number the st0.0 interface and run an IGP across 
it.  There is a nice easy example in the following document:

http://www.juniper.net/us/en/local/pdf/app-notes/3500153-en.pdf

The use of GRE over IPSEC is to get around the limitation in IOS and others 
whereby a proxy-id needs to be configured for before a VPN tunnel will 
establish.  You specify a proxy ID to cover all traffic destined for the 
endpoint of the GRE tunnel so that the tunnel itself is encrypted, then you 
specify your traffic to be routed via the tunnel.  Juniper refers to this as 
policy-based VPN and there is a good document on it here:

http://www.juniper.net/us/en/local/pdf/app-notes/3500175-en.pdf

It differs from route-based in that instead of your policy just having an 
action "permit", you add "tunnel" to it, which establishes the VPN tunnel with 
a proxy-id matching your policy.

> From: Jonathan Looney [mailto:jonloo...@gmail.com]
> Sent: 24 May 2010 14:21
> To: Nick Ryce
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Encrypt GRE tunnel with ipsec
>
> Are you using SRX/J-series or AS PIC/MS PIC/ASM/Services DPC?  The 
> configuration will be different for those two classes of platform.
>
> -Jon
> On Mon, May 24, 2010 at 8:44 AM, Nick Ryce 
> mailto:nick.r...@lumison.net>> wrote:
> Hi Guys,
>
> Is there a way to set up a gre tunnel and then encrypt gre packets with 
> ipsec?  I know it can be done on a cisco but the juniper kb makes my eyes 
> bleed trying to find anything.
>
> I found the following config here 
> http://communities.juniper.net/jnet/attachments/jnet/srx/509/1/gre-ipsec-srx240.txt
>  but dont think that would encrypt everything going down the tunnelor 
> would it.
>
> Im using 9.6 at the moment.
>
> Any help appreciated
>
> --
> Nick Ryce
> Network Engineer
> Lumison
> 0845119
>
> P.S. do you love Lumison?  Why not take a moment and vote for us?
> http://bit.ly/Vote_Lumison
>
>
>
>
> --
>
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they are 
> addressed.
> If you have received this email in error please notify the sender. Any
> offers or quotation of service are subject to formal specification.
> Errors and omissions excepted.  Please note that any views or opinions
> presented in this email are solely those of the author and do not
> necessarily represent those of Lumison.
> Finally, the recipient should check this email and any attachments for
> the presence of viruses.  Lumison accept no liability for any damage
> caused by any virus transmitted by this email.
>
> ___
> juniper-nsp mailing list
> juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> 
> --
>
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they are 
> addressed.
> If you have received this email in error please notify the sender. Any
> offers or quotation of service are subject to formal specification.
> Errors and omissions excepted. Please note that any views or opinions
> presented in this email are solely those of the author and do not
> necessarily represent those of Lumison.
> Finally, the recipient should check this email and any attachments for
> the presence of viruses. Lumison accept no liability for any damage
> caused by any virus transmitted by this email.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


--

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender. Any
offers or quotation of service are subject to formal specification.
Errors and omissions excepted.  P

Re: [j-nsp] EX-4200 Firewall Filter Placement

[Emil Katzarski]

Hi,

Placing the firewall filter at the L3 interface will not affect any
traffic traversing the switch! As I understand there is only one VLAN
and only one L3 interface. That means that there is no L3 routing for
user traffic. All user traffic is forwarded via Ethernet switching.
Only traffic for the switch itself will be affected.

The place to put firewall filter to protect the control plane of the
switch is lo0. If you would like to filter transit traffic you should
place the firewall filter at the interfaces or on the VLAN.

On Tue, Apr 27, 2010 at 7:30 PM, Mark Tinka  wrote:
> On Tuesday 27 April 2010 07:00:43 pm Walaa Abdel razzak
> wrote:
>
>> I have EX-4200 switch with JUNOS 9.6R2.11. all interfaces
>>  are put in VLAN 1 and L3 interface is configured in the
>>  same VLAN for reachability. I need to know what is the
>>  best place to put the firewall filter on the switch (lo0
>>  or vlan.1 or uplink interface).
>
> If the firewall is meant to filter traffic destined for the
> switch, e.g., SSH, TACACS+, e.t.c., place it on the Loopback
> interface in the inbound direction.
>
> If the firewall is meant to filter traffic transiting the
> switch, e.g., BCP-38, filtering of user traffic, e.t.c.,
> place it on the l3 interface in the appropriate direction.
>
> Cheers,
>
> Mark.
>
> ___
> 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] Encrypt GRE tunnel with ipsec

[Ben Dale]

Hi Nick,

> Im using a J6350.
> 
> All im trying to to is create a secure tunnel between 2 juniper routers and 
> route traffic down the tunnel without having to specify what specific source 
> destination ranges to encrypt.  Ie if a packet is destined to go down the 
> tunnel then encrypt.

I'll assume you're using JUNOS-ES here so you don't require the use of GRE.  In 
a nutshell, set up your VPN, bind it to your st (secure tunnel) interface and 
place the st interface into it's own security-zone.  Then simply route traffic 
destined for the VPN to the st interface and have a policy to allow it with the 
action "permit".  You can also number the st0.0 interface and run an IGP across 
it.  There is a nice easy example in the following document:

http://www.juniper.net/us/en/local/pdf/app-notes/3500153-en.pdf

The use of GRE over IPSEC is to get around the limitation in IOS and others 
whereby a proxy-id needs to be configured for before a VPN tunnel will 
establish.  You specify a proxy ID to cover all traffic destined for the 
endpoint of the GRE tunnel so that the tunnel itself is encrypted, then you 
specify your traffic to be routed via the tunnel.  Juniper refers to this as 
policy-based VPN and there is a good document on it here:

http://www.juniper.net/us/en/local/pdf/app-notes/3500175-en.pdf

It differs from route-based in that instead of your policy just having an 
action "permit", you add "tunnel" to it, which establishes the VPN tunnel with 
a proxy-id matching your policy.

> From: Jonathan Looney [mailto:jonloo...@gmail.com]
> Sent: 24 May 2010 14:21
> To: Nick Ryce
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Encrypt GRE tunnel with ipsec
> 
> Are you using SRX/J-series or AS PIC/MS PIC/ASM/Services DPC?  The 
> configuration will be different for those two classes of platform.
> 
> -Jon
> On Mon, May 24, 2010 at 8:44 AM, Nick Ryce 
> mailto:nick.r...@lumison.net>> wrote:
> Hi Guys,
> 
> Is there a way to set up a gre tunnel and then encrypt gre packets with 
> ipsec?  I know it can be done on a cisco but the juniper kb makes my eyes 
> bleed trying to find anything.
> 
> I found the following config here 
> http://communities.juniper.net/jnet/attachments/jnet/srx/509/1/gre-ipsec-srx240.txt
>  but dont think that would encrypt everything going down the tunnelor 
> would it.
> 
> Im using 9.6 at the moment.
> 
> Any help appreciated
> 
> --
> Nick Ryce
> Network Engineer
> Lumison
> 0845119
> 
> P.S. do you love Lumison?  Why not take a moment and vote for us?
> http://bit.ly/Vote_Lumison
> 
> 
> 
> 
> --
> 
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender. Any
> offers or quotation of service are subject to formal specification.
> Errors and omissions excepted.  Please note that any views or opinions
> presented in this email are solely those of the author and do not
> necessarily represent those of Lumison.
> Finally, the recipient should check this email and any attachments for the
> presence of viruses.  Lumison accept no liability for any
> damage caused by any virus transmitted by this email.
> 
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 
> 
> --
> 
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender. Any
> offers or quotation of service are subject to formal specification.
> Errors and omissions excepted. Please note that any views or opinions
> presented in this email are solely those of the author and do not
> necessarily represent those of Lumison.
> Finally, the recipient should check this email and any attachments for the
> presence of viruses. Lumison accept no liability for any
> damage caused by any virus transmitted by this email.
> ___
> 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] Auto-bandwidth Accuracy

[Danny Vernals]

On Sun, May 23, 2010 at 7:52 AM, Richard A Steenbergen  
wrote:
> Recently I've been noticing some really odd auto-bandwidth behavior on
> several different routers, and I'm wondering if anybody knows if this is
> a known bug or if I'm doing something really wrong in my autobw config.
>
> Specifically, I'm seeing many cases where the rsvp reservations on an
> interface are vastly higher than the actual traffic going over it. I
> started comparing autobw measures bandwidth value vs rsvp resv bandwidth
> across my LSPs (with an op script :P), and noticed that a large number
> of LSPs that were ingress on Juniper routers were consistently reserving
> more bandwidth than they were actually passing.
>
> To troubleshoot this further, I picked one LSP at random and followed it
> through the course of an entire adjust-interval. I also watched it in
> "monitor label-switched-path", and followed the bandwidth recorded for
> it in the mpls stats file. The mpls stats file pretty consistently
> recorded a bandwidth of around 900Mbps. Some samples were up to 1G, some
> were down in the 800Mb's, but nothing was significantly outside this
> range:
>
> xxx.-xxx.-BRONZE-1     20442770 pkt    21800398308 Byte  91864 pps 
> 97826023 Bps Util 43.47%
> xxx.-xxx.-BRONZE-1     25748678 pkt    27500224526 Byte  89930 pps 
> 96607224 Bps Util 42.93%
> xxx.-xxx.-BRONZE-1     31309754 pkt    33516047564 Byte  95880 pps 
> 103721086 Bps Util 46.09%
> xxx.-xxx.-BRONZE-1     36934965 pkt    39389728013 Byte  90729 pps 
> 94736781 Bps Util 42.10%
> xxx.-xxx.-BRONZE-1     41323164 pkt    44001156442 Byte  86043 pps 
> 90420165 Bps Util 40.18%
> xxx.-xxx.-BRONZE-1     46229207 pkt    49166295068 Byte  84586 pps 
> 89054114 Bps Util 39.58%
> xxx.-xxx.-BRONZE-1     51764861 pkt    55023074603 Byte  92260 pps 
> 97612992 Bps Util 43.38%
> xxx.-xxx.-BRONZE-1     57091315 pkt    60691783494 Byte  90278 pps 
> 96079811 Bps Util 42.70%
> xxx.-xxx.-BRONZE-1     62138489 pkt    66009079194 Byte  90128 pps 
> 94951708 Bps Util 42.20%
> xxx.-xxx.-BRONZE-1     67697838 pkt    72030553645 Byte  92655 pps 
> 100357907 Bps Util 44.60%
> xxx.-xxx.-BRONZE-1     73083250 pkt    77870203449 Byte  89756 pps 
> 97327496 Bps Util 43.25%
> xxx.-xxx.-BRONZE-1     78530642 pkt    83799427998 Byte  90789 pps 
> 98820409 Bps Util 43.91%
> xxx.-xxx.-BRONZE-1     84166327 pkt    89767404007 Byte  85389 pps 
> 90423878 Bps Util 40.18%
> xxx.-xxx.-BRONZE-1     89990750 pkt    96052103366 Byte  85653 pps 
> 92422049 Bps Util 41.07%
> xxx.-xxx.-BRONZE-1     94808838 pkt   101299936674 Byte  87601 pps 
> 95415151 Bps Util 42.40%
> xxx.-xxx.-BRONZE-1    100044983 pkt   106918990604 Byte  83113 pps 
> 89191332 Bps Util 39.64%
> xxx.-xxx.-BRONZE-1    104706036 pkt   111928263183 Byte  86315 pps 
> 92764307 Bps Util 41.22%
> xxx.-xxx.-BRONZE-1    109664547 pkt   117256403183 Byte  81287 pps 
> 87346557 Bps Util 38.82%
> xxx.-xxx.-BRONZE-1    115001230 pkt   123065374817 Byte  84709 pps 
> 92205898 Bps Util 40.98%
> xxx.-xxx.-BRONZE-1    120197917 pkt   128761293505 Byte  85191 pps 
> 93375716 Bps Util 41.50%
> xxx.-xxx.-BRONZE-1    124790487 pkt   133783111501 Byte  79182 pps 
> 86583068 Bps Util 38.48%
> xxx.-xxx.-BRONZE-1    129450091 pkt   138908431043 Byte  84720 pps 
> 93187628 Bps Util 41.41%
> xxx.-xxx.-BRONZE-1    134048794 pkt   143940227806 Byte  82119 pps 
> 89853513 Bps Util 39.93%
> xxx.-xxx.-BRONZE-1    138900130 pkt   149257983679 Byte  80855 pps 
> 88629264 Bps Util 39.39%
> xxx.-xxx.-BRONZE-1    143665805 pkt   154447812210 Byte  79427 pps 
> 86497142 Bps Util 38.44%
> xxx.-xxx.-BRONZE-1    148501587 pkt   159667032930 Byte  80596 pps 
> 86987012 Bps Util 38.66%
> xxx.-xxx.-BRONZE-1    153971586 pkt   165650360517 Byte  78142 pps 
> 85476108 Bps Util 37.99%
>
> Next, I watched the output of "show mpls lsp name BLAH detail", looking
> at the autobw measured amount (Max AvgBW) and the reserved bandwidth.
> I'm using a stats interval of 60 seconds, an adjust-interval of 900
> seconds, and in this instance no overflow samples occured. After the
> previous adjust-interval completes the measured bw is reset to 0, and
> then starts updating again after the first 60 sec stats interval is up.
> For around the first 700 seconds the Max AvgBW was pretty close to what
> one would expect (around 900Mbps), then it jumped to ~1.6Gbps for no
> reason that I can determine. The stats file for this LSP (above) never
> showed anything above 1.0G, and a monitor of the lsp never showed any
> sample thatever got anywhere near that high (let alone enough to make an
> entire 60 sec sample interval report that high). At the end of the 900
> seconds, te 1.6G value is what was signaled to RSVP, and the cycle
> repeated itself. I watched it for several more cycles, and saw the

Re: [j-nsp] l2circuit communities

[Richard A Steenbergen]

On Mon, May 24, 2010 at 07:46:17PM -0400, Phil Bedard wrote:
> A little different scenario but I'm using CBF with a cos next-hop-map
> to set specific lsp-next-hops for CoS classes, also using autobw, and
> I'm not seeing similar behavior. 
> 
> One thing I noticed is while the router is doing the MBB/re-signal the
> "ActiveRoute" value will drop to 0, but then it immediately goes back
> up to the prior value, so it makes you wonder what's going on behind
> the scenes. 
> 
> I'm using 9.3R3.8, hope thing isn't something introduced later... 
> 
> Are your paths actually changing output interfaces/paths or is it just
> a BW re-signal? 

Just doing a bandwidth resignal, nothing else is changing. I see the 
same behavior with the ActiveRoute count, it drops to 0 for about 14 
seconds after the resignal, then pops back up to where it was before.

I don't have anything in the 9.3's to test, but 9.6S5 is definitely
doing the same thing. I also confirmed that the route changes in
rtsockmon are from routes pointing to LSPs which just resignaled, which
stops as soon as the install-nexthop config goes away. I'm not
particularly interested in going to a full cos next-hop-map setup, but
this is definitely broken as-is. :)

-- 
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp