Re: [j-nsp] EX 8200 deployment
Didn't word it right.. I meant shouldn't ... I was taking some example out from SRX.. where customers choose to log “session-init” and “session-close”, it could generates high rate of IO activity to /var/log/rtlogd. Though its not a problem logging all these; but on a compact flash when we have a life cycle of about 100k it might become an issue very soon. Do note that this may effect only event mode logs not the stream mode. -Hoogen On Wed, Mar 24, 2010 at 11:54 PM, Richard A Steenbergen wrote: > On Wed, Mar 24, 2010 at 10:45:07PM -0700, Hoogen wrote: > > I think flash isn't going to be considered... It has a finite > > erase/write cycles.. yeah but 8200 could have had more storage.. > > Erm... what do you think it uses currently, a 2GB hard drive? :) > > -- > 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
Re: [j-nsp] EX 8200 deployment
I think flash isn't going to be considered... It has a finite erase/write cycles.. yeah but 8200 could have had more storage.. -Hoogen On Wed, Mar 24, 2010 at 4:21 PM, Richard A Steenbergen wrote: > On Thu, Mar 25, 2010 at 12:31:15AM +0300, Pavel Lunin wrote: > > Richard, one more thing. What do you do with the crash dumps > > untarzipping them on the router/switch itself? I have never done > > anything with them but sending to JTA. I believe it can have a lot of > > sense to pick them and discover yourself (though I've never tried), > > but why on the switch itself? Am I missing something important? > > You can run gdb on the coredump files locally and get a pretty good idea > of what blew up and where, which is often quite helpful in working > around the original problem. Also, JTAC is far too often surprisingly > bad at working with coredumps, and without the ability to independently > verify things myself and tell them they were confused I've had some > cases which would probably never have been solved. > > The story that was explained to me was that JTAC has some point and > click tool that they load the core into, which parses it and searches > their PR database to find matching backtraces. The problem is I'm > convinced at this point nobody in JTAC actually knows what a backtrace > is or how to read it, they just match it to whatever their tool tells > them, and surprisingly often their tool is very very wrong. > > The other big problem of course is file size and compression. Apparently > their tool only works with .zip files not .tgz files (which is a small > bit of a problem, seeing as how the router only has gzip :P), so they > have to uncompress it locally first before they can load it. I've had > JTAC not know what a .tgz file was, I've had Advanced JTAC spend days > trying to figure out why they couldn't get any data out of a coredump > when the problem turned out to be their local filesystem quota wasn't > big enough to work with a large core file, etc, etc. Even when things > work "right" it seems to take them 12-72 hours to parse a coredump even > on a p1 case, and a healthy percentage of the time their analysis is > just flat out wrong. Without the ability to look at the dump yourself, > you'd never know they were barking up the wrong tree. > > Because EX uses PowerPC, it isn't even particularly easy to find a > FreeBSD ppc box where you can actually do any useful analysis of the > coredumps. That assumes of course that you have working connectivity on > the box in question and can quickly copy the sometimes very large files > off, which due to the original problem that caused the crash is often > times not the case. And where do they plan on writing a 2GB core dump > when there is an EX kernel panic and you only have 600MB of free space > on an "empty" box? You can bet there will be, I run into them at least > 2 or 3 times a year on MX easily, it's just a fact of life. I mean > seriously what does 32GB of flash cost, $100? Think about the amount of > grief that will be caused by this in comparison, and tell me it was a > smart move on their part. :) > > -- > 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 > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SRX deployment / issues
I think the EX thread was really good and the feedback was awesome. I would like hear about similar experiences while deploying SRX Series gateways, I am assuming I would hear a lot on the branch boxes SRX 210,240,650 I would also love to hear feedback on SRX 3000/5000 if people have been using it in their setup, problems that their facing, improvements and general deployment scenario that have been used. -Hoogen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Prefer RIP Neighbor
Config with a small snapshot of the routing table would be nice.. -Hoogen On Thu, Mar 11, 2010 at 6:58 PM, Stefan Fouant < sfou...@shortestpathfirst.net> wrote: > Show us your config for 'protocols rip'. > > Stefan Fouant > --Original Message-- > From: Shane Ronan > To: sfou...@shortestpathfirst.net > Cc: 'Juniper Puck' > Subject: Re: [j-nsp] Prefer RIP Neighbor > Sent: Mar 11, 2010 7:53 PM > > Neighbor level, this is not at all how I expected it to behave. > > On Mar 11, 2010, at 9:45 PM, Stefan Fouant wrote: > > > Are you setting the metric-in statement at the global level or the > > neighbor level? > > > > Stefan Fouant > > --Original Message-- > > From: Shane Ronan > > To: Stefan Fouant > > Cc: 'Juniper Puck' > > Subject: Re: [j-nsp] Prefer RIP Neighbor > > Sent: Mar 11, 2010 7:32 PM > > > > I did, and it seems to set the metric on the route, regardless of > > interface. > > > > On Mar 11, 2010, at 9:28 PM, Stefan Fouant wrote: > > > >>> -Original Message- > >>> From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- > >>> boun...@puck.nether.net] On Behalf Of Shane Ronan > >>> Sent: Thursday, March 11, 2010 4:53 PM > >>> To: Juniper Puck > >>> Subject: [j-nsp] Prefer RIP Neighbor > >>> > >>> Hello list, > >>> > >>> I have exhausted all of my capabilities to figure out the answer to > >>> this question, so I am hoping you can help. > >>> > >>> I have two connections to the same network, which both provide me > >>> routes via RIP for Multicast sources. > >>> > >>> Is there a way for me to prefer the routes I receive via one of the > >>> connections over there other? > >> > >> Real stupid question, but did you try the metric-in statement to > >> adjust the > >> metric for the route from one of the neighbors, assuming both > >> neighbors are > >> not on the same interface... > >> > >> Stefan Fouant, CISSP, JNCIE-M/T > >> www.shortestpathfirst.net > >> GPG Key ID: 0xB5E3803D > >> > > > > > > > > Sent from my Verizon Wireless BlackBerry > > > > Sent from my Verizon Wireless BlackBerry > > ___ > 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] L2VPN debugging...
Hi Dermot,
Thank you for the suggestion... I had done it.. but no change... I guess if
you see the output from l2vpn connections... It has detected the other site
id correctly... also I guess the ctrl status is up... It's just complaining
I am assuming about the data plane..
Thanks,
Hoogen
On Mon, Feb 15, 2010 at 12:36 AM, Dermot Williams <
dermot.willi...@imaginegroup.ie> wrote:
> Hi,
>
> Have you tried adding the appropriate remote site id to each of your
> routing-instances?
>
> vpnc-1 {
>instance-type l2vpn;
>interface ge-0/0/2.600;
>route-distinguisher 10.0.3.4:1;
>vrf-import c1-import;
>vrf-export c1-export;
>protocols {
>l2vpn {
>encapsulation-type ethernet-vlan;
>site c1 {
>site-identifier 1;
> interface ge-0/0/2.600 {
>remote-site-id 2;
>}
>}
>}
>}
> }
>
> Dermot
>
> > -Original Message-
> > From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
> > boun...@puck.nether.net] On Behalf Of Hoogen
> > Sent: 15 February 2010 07:11
> > To: Sean Clarke; mti...@globaltransit.net
> > Cc: juniper-nsp@puck.nether.net
> > Subject: Re: [j-nsp] L2VPN debugging...
> >
> > Connection is as follows
> >
> > C1--R4--R5--R6--C2... R4-R5 are cbgp connections.. R5-R6 is a ibgp
> > connections. R5 is a route reflector. R4 and R6 are PE's C1 and C2 are
> > CE's
> >
> > The topology is similar to the JNCIE book by Harry Reynolds..
> >
> > R4 Configuration
> >
> > l...@r4# show interfaces ge-0/0/2
> > vlan-tagging;
> > encapsulation vlan-ccc;
> > unit 0 {
> > bandwidth 100m;
> > vlan-id 1;
> > family inet {
> > address 172.16.0.5/30;
> > }
> > }
> > unit 600 {
> > encapsulation vlan-ccc;
> > bandwidth 100m;
> > vlan-id 600;
> > }
> >
> > [edit]
> > l...@r4#
> >
> > l...@r4# show protocols bgp
> > group cbgp {
> > type external;
> > export ibgp;
> > peer-as 65001;
> > neighbor 10.0.2.9 {
> > family inet {
> > unicast;
> > }
> > family inet-vpn {
> > unicast;
> > }
> > family l2vpn {
> > signaling;
> > }
> > }
> > }
> >
> > l...@r4# show routing-instances
> > vpnc-1 {
> > instance-type l2vpn;
> > interface ge-0/0/2.600;
> > route-distinguisher 10.0.3.4:1;
> > vrf-import c1-import;
> > vrf-export c1-export;
> > protocols {
> > l2vpn {
> > encapsulation-type ethernet-vlan;
> > site c1 {
> > site-identifier 1;
> > interface ge-0/0/2.600;
> > }
> > }
> > }
> > }
> >
> > l...@r4# run show interfaces terse ge-0/0/2
> > Interface Admin Link ProtoLocal
> > Remote
> > ge-0/0/2upup
> > ge-0/0/2.0 upup inet 172.16.0.5/30
> > ge-0/0/2.600upup ccc
> > ge-0/0/2.32767 upup
> >
> > [edit]
> > l...@r4#
> >
> > l...@r4# run show mpls lsp ingress
> > Ingress LSP: 2 sessions
> > To FromState Rt ActivePath P
> LSPname
> > *10.0.9.610.0.3.4Up 0 *
> r4-r6*
> > 10.0.9.710.0.3.4Up 0 * r4-r7
> > Total 2 displayed, Up 2, Down 0
> >
> > [edit]
> > l...@r4#
> >
> > l...@r4# show policy-options
> > policy-statement c1-export {
> > term 1 {
> > then {
> > community add c1-c2-rt;
> > accept;
> > }
> > }
> > }
> > policy-statement c1-import {
> > term 1 {
> > from {
> > protocol bgp;
> > community c1-c2-rt;
> > }
> > then accept;
> > }
> > }
> > community c1-c2-rt members target:65412:300;
> >
> > [edit]
> > l...@r4#
> >
> >
> > l...@r5# show routing-options
> > rib inet.3 {
> > static {
> > route 0.0.0.0/0 discard;
> > }
> > }
> > autonomous-system 65001;
> > confederation 65412 members [ 65000 65001 ];
> >
> > [edit]
> > l...@r5#
> >
> >
Re: [j-nsp] L2VPN debugging...
R5 and R6 are in sub confed 65001 and R4 is in subconfed 65000. l...@r6# run show route table vpnc extensive vpnc-1.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 10.0.3.4:1:1:1/96 (1 entry, 1 announced) *BGPPreference: 170/-101 Route Distinguisher: 10.0.3.4:1 Next-hop reference count: 4 Source: 10.0.3.5 *Protocol next hop: 10.0.2.10* Indirect next hop: 2 no-forward State: Local AS: 65001 Peer AS: 65001 Age: 5:08 Metric2: 1 Task: BGP_65001.10.0.3.5+2193 Announcement bits (1): 0-vpnc-1-l2vpn AS path: (65000) I Communities: target:65412:300 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0 Label-base: 82, range: 2, status-vector: 0x80 Localpref: 100 Router ID: 10.0.3.5 Primary Routing Table bgp.l2vpn.0 Indirect next hops: 1 Protocol next hop: 10.0.2.10 Metric: 30 Indirect next hop: 2 no-forward Indirect path forwarding next hops: 1 Next hop: 10.0.2.14 via ge-0/0/3.0 weight 0x1 10.0.2.10/32 Originating RIB: inet.3 Metric: 30 Node path count: 1 Forwarding nexthops: 1 Nexthop: 10.0.2.14 via ge-0/0/3.0 10.0.9.6:2:2:1/96 (1 entry, 1 announced) TSI: Page 0 idx 0 Type 1 val 87b0918 *L2VPN Preference: 170/-101 Next-hop reference count: 2 Protocol next hop: 10.0.9.6 Indirect next hop: 0 - State: Age: 12:56:45 Metric2: 1 Task: vpnc-1-l2vpn Announcement bits (1): 1-BGP RT Background AS path: I Communities: Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0 Label-base: 84, range: 1, status-vector: 0x0 [edit] l...@r6# l...@r6# run show route 10.0.2.10 inet.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.2.8/30*[IS-IS/15] 01:09:56, metric 20 > to 10.0.8.6 via ge-0/0/2.0 [edit] l...@r6# I then installed the 10.0.2.10 prefix into the LSP and the VC came up... l...@r6# run show route 10.0.2.10 inet.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.2.8/30*[IS-IS/15] 01:17:37, metric 20 > to 10.0.8.6 via ge-0/0/2.0 inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.2.10/32 *[RSVP/7] 00:07:03, metric 30 > to 10.0.2.14 via ge-0/0/3.0, label-switched-path r6-r4 [edit] l...@r6# l...@r6# run show route table vpnc vpnc-1.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.3.4:1:1:1/96 *[BGP/170] 00:07:19, localpref 100, from 10.0.3.5 AS path: (65000) I *> to 10.0.2.14 via ge-0/0/3.0, label-switched-path r6-r4* 10.0.9.6:2:2:1/96 *[L2VPN/170/-101] 12:58:56, metric2 1 Indirect [edit] l...@r6# Thank you for your help Nilesh. Do you have a link that I could read up for more troubleshooting tips on L3/L2 VPN's.. Thanks again. Hoogen On Mon, Feb 15, 2010 at 9:35 AM, Nilesh Khambal wrote: > Why is the below route on R6, isn’t pointing to any LSP towards R4? Is > route reflector changing the protocol next-hop of the route coming from R4? > > <...> > 10.0.3.4:1:1:1/96<Receiving the R4 loopback.. > *[BGP/170] 00:07:30, localpref 100, from 10.0.3.5 > AS path: (65000) I >> to 10.0.8.6 via ge-0/0/2.0 > <...> > > Thanks, > Nilesh. > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L2VPN debugging...
Hi Nilesh, I do have that configuration on all routers. I actually do have another L3VPN configured between the same routers R4 and R6 which is working fine.. [edit] l...@r4# run show bgp summary Groups: 3 Peers: 5 Down peers: 0 Table Tot Paths Act Paths SuppressedHistory Damp State Pending inet.0 0 0 0 0 0 0 bgp.l3vpn.0 35 35 0 0 0 0 bgp.l2vpn.01 1 0 0 0 0 Peer AS InPkt OutPktOutQ Flaps Last Up/Dwn State|#Active/Received/Damped... 172.16.0.6 65010 4318 4431 0 120:41:58 Establ vpna-1.inet.0: 11/11/0 10.0.2.965001 2924 2947 0 120:40:08 Establ inet.0: 0/0/0 bgp.l3vpn.0: 24/24/0 * vpna-1.inet.0: 12/12/0 <--- vpna is a L3 VPN routes that I receive from R5..Customer is able to see all these routes.* bgp.l2vpn.0: 1/1/0 * vpnc-1.l2vpn.0: 1/1/0 <-- vpnc routes that I receive from R5..* 10.0.3.365000 5417 5408 0 0 1d 8:31:44 Establ inet.0: 0/0/0 10.0.6.165000 4318 5409 0 0 1d 8:31:37 Establ inet.0: 0/0/0 10.0.6.265000 4319 5409 0 0 1d 8:31:33 Establ inet.0: 0/0/0 [edit] l...@r4# Hi Phil These are the route table output l...@r4# run show route table vpnc vpnc-1.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.3.4:1:1:1/96 *[L2VPN/170/-101] 17:12:27, metric2 1 Indirect *10.0.9.6:2:2:1/96<-Receiving the R6 loopback..* *[BGP/170] 00:06:18, localpref 100, from 10.0.2.9 AS path: (65001) I > via t1-2/0/0.0, label-switched-path r4-r6 [edit] l...@r4# l...@r6# run show route table vpnc vpnc-1.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both *10.0.3.4:1:1:1/96<Receiving the R4 loopback.. * *[BGP/170] 00:07:30, localpref 100, from 10.0.3.5 AS path: (65000) I > to 10.0.8.6 via ge-0/0/2.0 10.0.9.6:2:2:1/96 *[L2VPN/170/-101] 11:24:44, metric2 1 Indirect [edit] l...@r6# Hi Aditya, Yeah I was trying to see all the traces I can get by turning on and off the vpnc instance. But I couldn't comprehend why the vpn doesn't come up.. To me it looks like the control plane is up but the data plane is down...:( l...@r4# run show l2vpn connections Layer-2 VPN connections: Legend for connection status (St) EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLS EM -- encapsulation mismatch WE -- interface and instance encaps not same VC-Dn -- Virtual circuit downNP -- interface hardware not present CM -- control-word mismatch -> -- only outbound connection is up CN -- circuit not provisioned<- -- only inbound connection is up OR -- out of range Up -- operational OL -- no outgoing label Dn -- down LD -- local site signaled down CF -- call admission control failure RD -- remote site signaled down SC -- local and remote site ID collision LN -- local site not designated LM -- local site ID not minimum designated RN -- remote site not designated RM -- remote site ID not minimum designated XX -- unknown connection status IL -- no incoming label Legend for interface status Up -- operational Dn -- down Instance: vpnc-1 Local site: c1 (1) connection-site Type St Time last up # Up trans 2 rmt VC-Dn - 0 Local interface: ge-0/0/2.600, Status: Up, Encapsulation: VLAN Remote PE: 10.0.9.6, Negotiated control-word: Yes (Null) Incoming label: 83, Outgoing label: 84 [edit] l...@r4# Thanks, Hoogen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L2VPN debugging...
from {
protocol bgp;
community c1-c2-rt;
}
then accept;
}
}
community c1-c2-rt members target:65412:300;
[edit]
l...@r6#
Hopefully I have covered all the configurations here... It is a Juniper to
Juniper scenario.. I am using J-Series with code 8.3R4.3 . Do let me know if
you do need more information... VC-Dn status usually would mean lsp to
neighbor not present.. But that's not the case in my scenario... Any input
is highly appreciated...
l...@r4# run show l2vpn connections
Layer-2 VPN connections:
Legend for connection status (St)
EI -- encapsulation invalid NC -- interface encapsulation not
CCC/TCC/VPLS
EM -- encapsulation mismatch WE -- interface and instance encaps not
same
VC-Dn -- Virtual circuit downNP -- interface hardware not present
CM -- control-word mismatch -> -- only outbound connection is up
CN -- circuit not provisioned<- -- only inbound connection is up
OR -- out of range Up -- operational
OL -- no outgoing label Dn -- down
LD -- local site signaled down CF -- call admission control failure
RD -- remote site signaled down SC -- local and remote site ID collision
LN -- local site not designated LM -- local site ID not minimum designated
RN -- remote site not designated RM -- remote site ID not minimum designated
XX -- unknown connection status IL -- no incoming label
Legend for interface status
Up -- operational
Dn -- down
Instance: vpnc-1
Local site: c1 (1)
connection-site Type St Time last up # Up trans
2 rmt VC-Dn - 0
Local interface: ge-0/0/2.600, Status: Up, Encapsulation: VLAN
Remote PE: 10.0.9.6, Negotiated control-word: Yes (Null)
Incoming label: 83, Outgoing label: 84
[edit]
l...@r4#
Thanks,
Hoogen
On Sun, Feb 14, 2010 at 10:32 PM, Sean Clarke wrote:
>
> What are you connecting too ? Another Juniper ?
>
> Please send messages from both ends, also configs, and confirm interfaces
> are UP on each end of the circuit.
>
> cheers
> Sean
>
>
>
> On 2/15/10 2:43 AM, Hoogen wrote:
>
>> Hi All,
>>
>> I am having some issues with L2Vpn.. The circuit stays down.. and error
>> messages don't say much... Appreciate it if someone help out here..
>>
>> [edit]
>> l...@r4# Feb 15 01:44:04.829253 rt_flash_update_callback: flash
>> vpnc-1-l2vpn
>> (vpnc-1.l2vpn.0) start
>> Feb 15 01:44:04.829288 Flash call for L2VPN from vpnc-1.L2VPN.0
>> Feb 15 01:44:04.829300 Label-block (off 1, rng 1, label-base 80,
>> encaps
>> 4) add from remote site 2 (RD 10.0.9.6:2:)
>> Feb 15 01:44:04.829335 task_timer_ucreate: created timer vpnc-1-l2vpn_Site
>> change flags<>
>> Feb 15 01:44:04.829343 New site with site-id 2 configured on remote PE
>> (RD 10.0.9.6:2:)
>> Feb 15 01:44:04.829350 Remote Site 2 encaps type updated to 4
>> Feb 15 01:44:04.829359 Site ID 2: Starting timer for change
>> processing, change flags 1C, reason: remote adv recv -- RD 10.0.9.6:2:
>> Feb 15 01:44:04.829367 task_timer_reset: reset vpnc-1-l2vpn_Site change
>> Feb 15 01:44:04.829378 task_timer_set_oneshot_latest: timer
>> vpnc-1-l2vpn_Site change interval set to 0.046218
>> Feb 15 01:44:04.829385 Flash processing complete for L2VPN from
>> vpnc-1.L2VPN.0
>> Feb 15 01:44:04.829401 rt_flash_update_callback: flash vpnc-1-l2vpn
>> (vpnc-1.l2vpn.0) done
>> Feb 15 01:44:04.889158 task_timer_dispatch: calling vpnc-1-l2vpn_Site
>> change, late by 0.013
>> Feb 15 01:44:04.889166 Handling change processing for remote-site 2:
>> Feb 15 01:44:04.889172 Starting change processing for remote-site 2: flags
>> 0x1c
>> Feb 15 01:44:04.889181 Insert/update vc from local-site c1(1) to
>> remote-site 2
>> Feb 15 01:44:04.889186 new vc
>> Feb 15 01:44:04.889193 Insert/update vc (VPN : vpnc-1, local-site
>> :
>> 1, remote-site : 2)
>> Feb 15 01:44:04.889224 circuit 0 updated to ge-0/0/2.600
>> Feb 15 01:44:04.889230 updated circuit 0 to ge-0/0/2.600, status
>> UP
>> Feb 15 01:44:04.889236 add rti for ifl 300/16
>> Feb 15 01:44:04.889241 add nhi: ifl ge-0/0/2.600, cw action STRIP
>> Feb 15 01:44:04.889247Triggering VC status update timer for intf
>> ge-0/0/2.600
>> Feb 15 01:44:04.889257 Ingress label changed to (83)
>> Feb 15 01:44:04.889264 add rti for ifl 0 label 83 op 0/36
>> Feb 15 01:44:04.889275 add route with prefix ifl 0 label 83 op
>> 0/36 and nexthop: ifl ge-0/0/2.600, cw action STRIP
>> Feb 15 01:44:04.889299 updated ingress-label to 83
>> Feb 15
[j-nsp] L2VPN debugging...
tus (St) EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLS EM -- encapsulation mismatch WE -- interface and instance encaps not same VC-Dn -- Virtual circuit downNP -- interface hardware not present CM -- control-word mismatch -> -- only outbound connection is up CN -- circuit not provisioned<- -- only inbound connection is up OR -- out of range Up -- operational OL -- no outgoing label Dn -- down LD -- local site signaled down CF -- call admission control failure RD -- remote site signaled down SC -- local and remote site ID collision LN -- local site not designated LM -- local site ID not minimum designated RN -- remote site not designated RM -- remote site ID not minimum designated XX -- unknown connection status IL -- no incoming label Legend for interface status Up -- operational Dn -- down Instance: vpnc-1 Local site: c1 (1) Number of local interfaces: 1 Number of local interfaces up: 1 ge-0/0/2.6002 Interface flags: VC-Down 82 1 2 100 status-vector: 80 connection-site Type St Time last up # Up trans *2 rmt VC-Dn - 0 * Local interface: ge-0/0/2.600, Status: Up, Encapsulation: VLAN Remote PE: 10.0.9.6, Negotiated control-word: Yes (Null) Incoming label: 83, Outgoing label: 80 Time Event Interface/Lbl/PE Feb 15 01:44:04 2010 PE route changed Feb 15 01:44:04 2010 Out lbl Update80 Feb 15 01:44:04 2010 In lbl Update 83 Feb 15 01:44:04 2010 loc intf up ge-0/0/2.600 [edit] l...@r4# Thanks, Hoogen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] L2VPN error messages
Hi, Can someone point to a documentation that details l2vpn error messages. I just don't seem to debug this issue which I have l...@r4# run show l2vpn connections Layer-2 VPN connections: Legend for connection status (St) EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLS EM -- encapsulation mismatch WE -- interface and instance encaps not same VC-Dn -- Virtual circuit downNP -- interface hardware not present CM -- control-word mismatch -> -- only outbound connection is up CN -- circuit not provisioned<- -- only inbound connection is up OR -- out of range Up -- operational OL -- no outgoing label Dn -- down LD -- local site signaled down CF -- call admission control failure RD -- remote site signaled down SC -- local and remote site ID collision LN -- local site not designated LM -- local site ID not minimum designated RN -- remote site not designated RM -- remote site ID not minimum designated XX -- unknown connection status IL -- no incoming label Legend for interface status Up -- operational Dn -- down Instance: vpnc-1 Local site: c1 (12) connection-site Type St Time last up # Up trans 21rmt OR [edit] l...@r4# Thanks, Hoogen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] bfd = busted failure detection :)
Thanks for all the great info Richard... -Hoogen On Mon, Dec 14, 2009 at 1:23 AM, Richard A Steenbergen wrote: > On Sun, Dec 13, 2009 at 03:11:29AM -0600, Richard A Steenbergen wrote: > > That one is pretty different from the usual slowness issue that seems to > > be affecting most people. I just cleared bgp sessions on a router to > > demonstrate the issue, which you can portions of any time you make a > > major routing change. Unfortunately (for my demonstration) this router > > was pretty small and didn't exhibit any stalls in processing fib > > updates. The performance was pretty acceptable, fully syncing in under a > > minute. I'm sure the simultanious loss of IGP routes and having more > > complex routing protocol configurations has something to do with it too. > > Oh what good timing, just had to reboot a router tonight to recover from > a differnet Juniper bug (enabling graceful-switchover on a 9.5R3 box > caused blackholing of traffic, disabling it didn't fix it, had to reboot > the box to clear the issue which of course blew away all the state, so > there will be no finding the root cause). But it did provide a perfect > example of the FIB blocking issue, with the vast majority of the routing > table blocking for over 13 minutes before finally installing within a > few seconds. > > Here we are at just past the 13 minute mark, BGP fully synchronized, but > the vast majority of the routing table not actually installed to FIB: > > Groups: 65 Peers: 92 Down peers: 15 > Table Tot Paths Act Paths SuppressedHistory Damp State > Pending > inet.0 2793497 333891 0 0 0 > 292429 > inetflow.027 27 0 0 0 >4 > inet6.0 9438 2075 0 0 0 > 811 > > Here is the show krt queue from the same time, showing almost nothing in > the queue. A followup command a second later showed completely different > items in the queue, leading one to believe that the krt queue was not > stuck. > > Routing table add queue: 0 queued > Interface add/delete/change queue: 0 queued > Indirect next hop add/change: 0 queued > MPLS add queue: 0 queued > Indirect next hop delete: 2 queued > DELETE index 1048789 > DELETE index 1048790 > High-priority deletion queue: 0 queued > High-priority change queue: 0 queued > High-priority add queue: 0 queued > Normal-priority indirect next hop queue: 0 queued > Normal-priority deletion queue: 0 queued > Normal-priority composite next hop deletion queue: 0 queued > Normal-priority change queue: 0 queued > Normal-priority add queue: 7 queued >ADD gf 1 inst id 0 173.164.0.0/19 type 3 > (20) >ADD gf 1 inst id 0 173.162.16.0/20 type 3 > (20) >ADD gf 1 inst id 0 173.160.64.0/19 type 3 > (20) >ADD gf 1 inst id 0 217.168.224.0/20 type 3 > (20) >ADD gf 1 inst id 0 209.211.136.0/24 nexthop > x.x.x.x, xe-7/1/0.0 > (19) >ADD gf 1 inst id 0 208.45.191.0/24 nexthop > x.x.x.x, xe-7/1/0.0 > (19) >ADD gf 1 inst id 0 208.45.190.0/24 nexthop > x.x.x.x, xe-7/1/0.0 > (19) > Routing table delete queue: 0 queued > > Here is an example of a route which has been stuck trying to install for > over 8 minutes (first entry in a show route, the rest all look roughly > the same though): > > 2.0.0.0/16 +[BGP/170] 00:08:40, MED 0, localpref 200, from > xx.xx.xxx.xxx > AS path: 5413 12654 I >> to xx.xx.xxx.xx via xe-3/2/0.0, label-switched-path > X > to xx.xx.xxx.xx via xe-3/2/0.0, label-switched-path > X > to xx.xx.xxx.xx via xe-3/2/0.0, label-switched-path > X > to xx.xx.xxx.xx via xe-3/2/0.0, label-switched-path > X > to xx.xx.xxx.xx via ae0.50, label-switched-path > Bypass->xx.xx.xxx.xx->xx.xx.xxx.xx > to xx.xx.xxx.xx via ae0.50, label-switched-path > Bypass->xx.xx.xxx.xx->xx.xx.xxx.xx > to xx.xx.xxx.xx via ae0.50, label-switched-path > Bypass->xx.xx.xxx.xx->xx.xx.xxx.xx > to xx.xx.xxx.xx via ae0.50, label-switched-path > Bypass->xx.xx.xxx.xx->xx.xx.xxx.xx > > The above is pretty representative of the issue, which has been going on > in one form or another since around the mid 7.x's (confirmed by dozens > of people I've talked to who saw the same behavior beginning at around > the same time). >
[j-nsp] Load Balancing in BGP...
Hi All, I have a question in BGP case study.. for JNCIP topology when we use multipath options in most case studies.. It does show two next-hops.. But I believe we still need load balance on the forwarding option so as to load balance traffic.. But most of the case studies do not include them as a part of the solutions. Is this overdoing the requirement, or am I missing something.. Any ideas would be great.. -Hoogen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ASR1002 Comparitive
I would assume so...SRX240.. is not an equivalent to ASR1002.. On Wed, Nov 18, 2009 at 9:55 AM, Derick Winkworth wrote: > Wouldn't an SRX-650 be a better choice if your comparing to an ASR1002? > > > > > From: Kris Amy > To: "mti...@globaltransit.net" ; " > juniper-nsp@puck.nether.net" > Sent: Wed, November 18, 2009 4:48:17 AM > Subject: Re: [j-nsp] ASR1002 Comparitive > > The plot thickens, > > With sampling set to 1/100. The box is nominally at 50%. > > However whenever we commit a config the box jumps to 100% cpu for approx 10 > minutes. We started seeing this when I brought up 1 full bgp peer. My > Partner has an open case with JTAC for this and will let you know the > results when they come to hand. > > Regards, > Kris > > > On 18/11/09 6:01 PM, "Mark Tinka" wrote: > > > On Wednesday 18 November 2009 11:58:53 am Bill Blackford > > wrote: > > > >> I believe the M7i is the closest one 2 one comparison. > >> The performance numbers are almost exact and depending on > >> your supplier should be competitively priced with an > >> ASR1002. > > > > This is where/when I think Juniper need to re-invent the > > M7i/M10i. Even with the new Enhanced CFEB, the ASR1000's > > offer way more value, e.g., they can talk 10Gbps Ethernet or > > STM-64/OC-192, they can talk STM-16/OC-48, now support a > > 20Gbps centralized forwarding plane, support a wide range of > > line rate Gig-E line cards, e.t.c. > > > > We've seen a number of cases where the ASR1004/6 beats an > > M10i any day, especially when used as a small core or > > medium-sized edge router. The M7i is in even worse trouble > > since the ASR1002 comes with 4x on-board Gig-E ports - > > lovely. > > > > The M7i's/M10i's are finding it very hard to play in this > > space, anymore. This needs to be rectified. > > > > 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 > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Script to check connectivity to all subnets
Thanks for you reply Stefan. Appreciate it.. -Hoogen On Sun, Nov 8, 2009 at 3:52 PM, Stefan Fouant wrote: > Hoogen, > > I honestly wouldn't waste too much time with TCL scripts, etc. Most of > that > stuff is locked out during the exam... You could script something using a > JUNOS Op script, but the problem is the version of JUNOS in the labs is pre > Op-Scripts. > > Your best bet is to use a few intelligent pings, i.e. specify the source > interface as being something that the remote end will need to learn via > some > routing protocol - this way you can kill two birds with one stone. > > Stefan Fouant > GPG Key ID: 0xB5E3803D > > > -Original Message- > > From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- > > boun...@puck.nether.net] On Behalf Of Hoogen > > Sent: Sunday, November 08, 2009 4:59 PM > > To: juniper-nsp@puck.nether.net; Juniper certification > > Subject: [j-nsp] Script to check connectivity to all subnets > > > > Hi, > > > > I was hoping to see if someone has written a script which can be > > quickly > > compiled during the lab exam and executed to make sure of the > > reachability > > to every subnet. Benefit would be if the script can be written quickly > > and > > execution is easy during the lab to confirm the results. > > > > Something in lines of the tcl scripts which can be written in Cisco, > > which a > > lot of people used to test connectivity in the CCIE lab exam. > > > > Thanks, > > Hoogen > > ___ > > 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] Script to check connectivity to all subnets
Hi, I was hoping to see if someone has written a script which can be quickly compiled during the lab exam and executed to make sure of the reachability to every subnet. Benefit would be if the script can be written quickly and execution is easy during the lab to confirm the results. Something in lines of the tcl scripts which can be written in Cisco, which a lot of people used to test connectivity in the CCIE lab exam. Thanks, Hoogen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ISIS-OSPF Redistribution Questions
It's late night here... excuse my typos and all the gibberish.. But yeah
Static routes maybe the only solution..
-Hoogen
On Sun, Nov 8, 2009 at 2:29 AM, Hoogen wrote:
> What is your topology?.. Is your topology is similar to the book?? The
> questions do seem a bit awkward... Well yeah NSSA def route is like an
> external route so changing the value affects everything... and for ISIS
> level 1 preference can be set specifically and def route generated by ISIS
> (Book Case Study) is level 1.
>
> Thinking about it... The only way you can do things is using preference
> values.. since OSPF nor ISIS can have an import policy. So in this scenario
> of yours you might not have optimal routing.. It is a loop..if you do have
> to put that level 1 external preference as 149...
>
> Another way to just solve your problem would be to have static routes... to
> the ABR's.
>
> -Hoogen
>
>
> On Sun, Nov 8, 2009 at 12:38 AM, Walaa Abdel razzak wrote:
>
>> Hi
>>
>> If I did this, then R6 or R7 will prefer datacenter routes through R5 bcoz
>> they r coming with lower preference than ISIS routes which make sub-optimal
>> routing.
>>
>>
>> Best Regards,
>> Walaa Abdel Razzak
>>
>>
>> -Original Message-
>> From: Hoogen [mailto:hooge...@gmail.com ]
>> Sent: Sat 07/11/2009 22:38
>> To: Walaa Abdel razzak
>> Cc: juniper-nsp@puck.nether.net
>> Subject: Re: [j-nsp] ISIS-OSPF Redistribution Questions
>>
>> Hi,
>>
>> Your scenario looks like a complete opposite of what we have in the case
>> study, from what you have mentioned here.. The solution would be that on
>> R6
>> and R7 you set the ospf external-preference to be lower than 149.. This
>> would make the def route from OSPF more preferred.
>>
>> set protocols ospf external-preference 148 <-- Make the nssa def route
>> preference on R6 and R7 to be lower than that received from the ISIS DC
>> router.
>>
>> -Hoogen
>>
>> 2009/11/7 Walaa Abdel razzak
>>
>> > Hi Experts
>> >
>> >
>> >
>> > If you have area 2 nssa receiving default route from the ABR with metric
>> > 150, two routers R6, R7 are sending this default route to ISIS level 1
>> > router in the DC. The L1 external preference are modified on R6, R7 to
>> be
>> > 149. This is to prefer routes coming from ISIS than OSPF. The problem is
>> > that DC router resend the default route from R6 to R7. R7 see it with
>> > preference of 149 and the default route is coming from OSPF is 150 so it
>> > prefers the ISIS which cause non-optimal routing. Any ideas to solve
>> this
>> > issue without making modification on the DC router?
>> >
>> >
>> >
>> > Sample config:
>> >
>> >
>> >
>> > R6 or R7 config.:
>> >
>> >
>> >
>> > isis {
>> >
>> >export senddefault; à send default to the ISIS
>> router
>> >
>> >level 2 disable;
>> >
>> >level 1 external-preference 149;
>> >
>> >interface fe-1/3/1.23;
>> >
>> >interface lo0.6;
>> >
>> > }
>> >
>> > ospf {
>> >
>> >export fromisis; à redistribute routes from
>> ISIS
>> >
>> >area 0.0.0.2 {
>> >
>> >nssa;
>> >
>> >interface lo0.6;
>> >
>> >interface fe-1/3/0.20;
>> >
>> >interface fe-1/3/1.16;
>> >
>> >interface fe-1/3/1.23 {
>> >
>> >passive;
>> >
>> >}
>> >
>> >}
>> >
>> > }
>> >
>> >
>> >
>> > DC:
>> >
>> > -
>> >
>> > isis {
>> >
>> >export static-isis;
>> >
>> >level 2 disable;
>> >
>> >interface fe-1/3/0.23;
>> >
>> >interface fe-1/3/0.24;
>> >
>> > }
>> >
>> >
>> >
>> > BR,
>> >
>> > Walaa Abdel Razzak
>> >
>> > ___
>> > 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] ISIS-OSPF Redistribution Questions
What is your topology?.. Is your topology is similar to the book?? The
questions do seem a bit awkward... Well yeah NSSA def route is like an
external route so changing the value affects everything... and for ISIS
level 1 preference can be set specifically and def route generated by ISIS
(Book Case Study) is level 1.
Thinking about it... The only way you can do things is using preference
values.. since OSPF nor ISIS can have an import policy. So in this scenario
of yours you might not have optimal routing.. It is a loop..if you do have
to put that level 1 external preference as 149...
Another way to just solve your problem would be to have static routes... to
the ABR's.
-Hoogen
On Sun, Nov 8, 2009 at 12:38 AM, Walaa Abdel razzak wrote:
> Hi
>
> If I did this, then R6 or R7 will prefer datacenter routes through R5 bcoz
> they r coming with lower preference than ISIS routes which make sub-optimal
> routing.
>
>
> Best Regards,
> Walaa Abdel Razzak
>
>
> -Original Message-
> From: Hoogen [mailto:hooge...@gmail.com ]
> Sent: Sat 07/11/2009 22:38
> To: Walaa Abdel razzak
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] ISIS-OSPF Redistribution Questions
>
> Hi,
>
> Your scenario looks like a complete opposite of what we have in the case
> study, from what you have mentioned here.. The solution would be that on R6
> and R7 you set the ospf external-preference to be lower than 149.. This
> would make the def route from OSPF more preferred.
>
> set protocols ospf external-preference 148 <-- Make the nssa def route
> preference on R6 and R7 to be lower than that received from the ISIS DC
> router.
>
> -Hoogen
>
> 2009/11/7 Walaa Abdel razzak
>
> > Hi Experts
> >
> >
> >
> > If you have area 2 nssa receiving default route from the ABR with metric
> > 150, two routers R6, R7 are sending this default route to ISIS level 1
> > router in the DC. The L1 external preference are modified on R6, R7 to be
> > 149. This is to prefer routes coming from ISIS than OSPF. The problem is
> > that DC router resend the default route from R6 to R7. R7 see it with
> > preference of 149 and the default route is coming from OSPF is 150 so it
> > prefers the ISIS which cause non-optimal routing. Any ideas to solve this
> > issue without making modification on the DC router?
> >
> >
> >
> > Sample config:
> >
> >
> >
> > R6 or R7 config.:
> >
> >
> >
> > isis {
> >
> >export senddefault; à send default to the ISIS
> router
> >
> >level 2 disable;
> >
> >level 1 external-preference 149;
> >
> >interface fe-1/3/1.23;
> >
> >interface lo0.6;
> >
> > }
> >
> > ospf {
> >
> >export fromisis; à redistribute routes from
> ISIS
> >
> >area 0.0.0.2 {
> >
> >nssa;
> >
> >interface lo0.6;
> >
> >interface fe-1/3/0.20;
> >
> >interface fe-1/3/1.16;
> >
> >interface fe-1/3/1.23 {
> >
> >passive;
> >
> >}
> >
> >}
> >
> > }
> >
> >
> >
> > DC:
> >
> > -
> >
> > isis {
> >
> >export static-isis;
> >
> >level 2 disable;
> >
> >interface fe-1/3/0.23;
> >
> >interface fe-1/3/0.24;
> >
> > }
> >
> >
> >
> > BR,
> >
> > Walaa Abdel Razzak
> >
> > ___
> > 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] ISIS-OSPF Redistribution Questions
Hi,
Your scenario looks like a complete opposite of what we have in the case
study, from what you have mentioned here.. The solution would be that on R6
and R7 you set the ospf external-preference to be lower than 149.. This
would make the def route from OSPF more preferred.
set protocols ospf external-preference 148 <-- Make the nssa def route
preference on R6 and R7 to be lower than that received from the ISIS DC
router.
-Hoogen
2009/11/7 Walaa Abdel razzak
> Hi Experts
>
>
>
> If you have area 2 nssa receiving default route from the ABR with metric
> 150, two routers R6, R7 are sending this default route to ISIS level 1
> router in the DC. The L1 external preference are modified on R6, R7 to be
> 149. This is to prefer routes coming from ISIS than OSPF. The problem is
> that DC router resend the default route from R6 to R7. R7 see it with
> preference of 149 and the default route is coming from OSPF is 150 so it
> prefers the ISIS which cause non-optimal routing. Any ideas to solve this
> issue without making modification on the DC router?
>
>
>
> Sample config:
>
>
>
> R6 or R7 config.:
>
>
>
> isis {
>
>export senddefault; à send default to the ISIS router
>
>level 2 disable;
>
>level 1 external-preference 149;
>
>interface fe-1/3/1.23;
>
>interface lo0.6;
>
> }
>
> ospf {
>
>export fromisis; à redistribute routes from ISIS
>
>area 0.0.0.2 {
>
>nssa;
>
>interface lo0.6;
>
>interface fe-1/3/0.20;
>
>interface fe-1/3/1.16;
>
>interface fe-1/3/1.23 {
>
>passive;
>
>}
>
>}
>
> }
>
>
>
> DC:
>
> -
>
> isis {
>
>export static-isis;
>
>level 2 disable;
>
>interface fe-1/3/0.23;
>
>interface fe-1/3/0.24;
>
> }
>
>
>
> BR,
>
> Walaa Abdel Razzak
>
> ___
> 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] urgent
#show interfaces fe-0/0/0
fastether-options {
802.3ad ae0;
}
r3# show interfaces ae0
vlan-tagging;
aggregated-ether-options {
minimum-links 2;
}
#show chassis aggregated-devices
ethernet {
device-count 1;
}
set protocols ospf area interface ae0.(unit number)
And you are all set...
show interfaces ae0 <-- Should give you some detail.. use the detail switch
for more information
-Hoogen
On Sun, Nov 1, 2009 at 1:08 AM, chandrasekaran iyer wrote:
> Hi all,
>
> I would like to run ospf over aggregated interface (say ae2) and
> check neighborship comes up, also ping to other end.
> I need sample configs, show commands to check aggregated bundle and
> ospf over aggregated bundle.
>
> --
> Thanks with regards
>
> Shekar.B
> --
> ___
> 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] JNCIP EBGP Case Study...
My Bad typo error...
Thanks to all...
On Fri, Oct 30, 2009 at 12:57 AM, Sean Clarke wrote:
> Yes that's a solution, or workaround - but why do you want to prepend to
> your internal peers ? Surely it only makes sense to prepend out of your
> network, and use local preference to your internal peers ?
>
> cheers
> Sean
>
>
> On 10/29/09 11:29 PM, Hoogen wrote:
>
> I guess for the solution to work we need to have
>
> autonomous-system 65001 loops 3;
>
> This would make sure we get those routes.
>
> -Hoogen
>
> On Thu, Oct 29, 2009 at 2:56 PM, Hoogen wrote:
>
>> Okay.. Earlier task required while accepting routes from peer to tag them
>> with a community and prepend them with as number 65412 twice... I notice
>> that when I deactivate that.. It works.. So obviously R3 is considering the
>> routes received from R1 with prepend of 65412 for all P1 routes to be some
>> sort of as loop... So I guess there is something wrong about it..
>>
>> Page 568 of the JNCIP books...
>>
>> -Hoogen
>>
>>
>> On Thu, Oct 29, 2009 at 2:05 PM, Hoogen wrote:
>>
>>> R1
>>>
>>> l...@r1> show configuration routing-options
>>> static {
>>> route 10.0.200.0/24 {
>>> next-hop 10.0.1.102;
>>> no-readvertise;
>>> }
>>> route 192.168.10.0/24 reject;
>>> route 192.168.100.0/24 reject;
>>> route 10.0.0.0/8 {
>>> next-hop 10.0.4.13;
>>> qualified-next-hop 10.0.4.6 {
>>> preference 10;
>>> }
>>> }
>>> }
>>> martians {
>>> 192.0.2.0/24 orlonger;
>>> }
>>> autonomous-system 65000;
>>> confederation 65412 members [ 65000 65001 65002 ];
>>>
>>> l...@r1>
>>>
>>> l...@r1> show configuration protocols bgp
>>> group 65000 {
>>> type internal;
>>> local-address 10.0.6.1;
>>> export ibgp;
>>> neighbor 10.0.3.3;
>>> }
>>> group p1 {
>>> type external;
>>> import peer-filter-in;
>>> export p1-export;
>>> neighbor 10.0.5.254 {
>>> peer-as 1492;
>>> }
>>> }
>>>
>>> l...@r1>
>>>
>>> l...@r1> show configuration policy-options policy-statement ibgp
>>> term 1 {
>>> from {
>>> protocol static;
>>> route-filter 192.168.10.0/24 exact;
>>> }
>>> then accept;
>>> }
>>> term 2 {
>>> from {
>>> protocol static;
>>> route-filter 192.168.100.0/24 exact;
>>> }
>>> then {
>>> metric 101;
>>> local-preference 101;
>>> community add no-export;
>>> accept;
>>> }
>>> }
>>>
>>> l...@r1>
>>>
>>> R3 Configuration
>>>
>>> l...@r3> show configuration routing-options
>>> static {
>>> route 10.0.200.0/24 {
>>> next-hop 10.0.1.102;
>>> no-readvertise;
>>> }
>>> route 192.168.30.0/24 reject;
>>> }
>>> martians {
>>> 192.0.2.0/24 orlonger;
>>> }
>>> aggregate {
>>> route 10.0.4.0/22;
>>> }
>>> autonomous-system 65000;
>>> confederation 65412 members [ 65000 65001 65002 ];
>>>
>>> l...@r3>
>>>
>>> l...@r3> show configuration protocols bgp
>>> advertise-inactive;
>>> group 65000 {
>>> type internal;
>>> local-address 10.0.3.3;
>>> export ibgp;
>>> neighbor 10.0.6.1;
>>> }
>>> group c-bgp {
>>> type external;
>>> multihop;
>>> local-address 10.0.3.3;
>>> export ibgp;
>>> neighbor 10.0.3.4 {
>>> hold-time 180;
>>> peer-as 65001;
>>> }
>>> neighbor 10.0.3.5 {
>>> peer-as 65002;
>>> }
>>> }
>>> group t1-t2 {
>>> type external;
>>> damping;
>>> import [ damp trans-filter-in ];
>>> export [ no-192-24s prepend ];
>>> remove-private;
>>> multipath;
>>> neighbor 172.16.0.14 {
>>> peer-as 65222;
>>> }
>>> neighbor 172.16.0.18 {
>>> peer-as 65222;
>>> }
>>>
Re: [j-nsp] JNCIP EBGP Case Study...
I guess for the solution to work we need to have
autonomous-system 65001 loops 3;
This would make sure we get those routes.
-Hoogen
On Thu, Oct 29, 2009 at 2:56 PM, Hoogen wrote:
> Okay.. Earlier task required while accepting routes from peer to tag them
> with a community and prepend them with as number 65412 twice... I notice
> that when I deactivate that.. It works.. So obviously R3 is considering the
> routes received from R1 with prepend of 65412 for all P1 routes to be some
> sort of as loop... So I guess there is something wrong about it..
>
> Page 568 of the JNCIP books...
>
> -Hoogen
>
>
> On Thu, Oct 29, 2009 at 2:05 PM, Hoogen wrote:
>
>> R1
>>
>> l...@r1> show configuration routing-options
>> static {
>> route 10.0.200.0/24 {
>> next-hop 10.0.1.102;
>> no-readvertise;
>> }
>> route 192.168.10.0/24 reject;
>> route 192.168.100.0/24 reject;
>> route 10.0.0.0/8 {
>> next-hop 10.0.4.13;
>> qualified-next-hop 10.0.4.6 {
>> preference 10;
>> }
>> }
>> }
>> martians {
>> 192.0.2.0/24 orlonger;
>> }
>> autonomous-system 65000;
>> confederation 65412 members [ 65000 65001 65002 ];
>>
>> l...@r1>
>>
>> l...@r1> show configuration protocols bgp
>> group 65000 {
>> type internal;
>> local-address 10.0.6.1;
>> export ibgp;
>> neighbor 10.0.3.3;
>> }
>> group p1 {
>> type external;
>> import peer-filter-in;
>> export p1-export;
>> neighbor 10.0.5.254 {
>> peer-as 1492;
>> }
>> }
>>
>> l...@r1>
>>
>> l...@r1> show configuration policy-options policy-statement ibgp
>> term 1 {
>> from {
>> protocol static;
>> route-filter 192.168.10.0/24 exact;
>> }
>> then accept;
>> }
>> term 2 {
>> from {
>> protocol static;
>> route-filter 192.168.100.0/24 exact;
>> }
>> then {
>> metric 101;
>> local-preference 101;
>> community add no-export;
>> accept;
>> }
>> }
>>
>> l...@r1>
>>
>> R3 Configuration
>>
>> l...@r3> show configuration routing-options
>> static {
>> route 10.0.200.0/24 {
>> next-hop 10.0.1.102;
>> no-readvertise;
>> }
>> route 192.168.30.0/24 reject;
>> }
>> martians {
>> 192.0.2.0/24 orlonger;
>> }
>> aggregate {
>> route 10.0.4.0/22;
>> }
>> autonomous-system 65000;
>> confederation 65412 members [ 65000 65001 65002 ];
>>
>> l...@r3>
>>
>> l...@r3> show configuration protocols bgp
>> advertise-inactive;
>> group 65000 {
>> type internal;
>> local-address 10.0.3.3;
>> export ibgp;
>> neighbor 10.0.6.1;
>> }
>> group c-bgp {
>> type external;
>> multihop;
>> local-address 10.0.3.3;
>> export ibgp;
>> neighbor 10.0.3.4 {
>> hold-time 180;
>> peer-as 65001;
>> }
>> neighbor 10.0.3.5 {
>> peer-as 65002;
>> }
>> }
>> group t1-t2 {
>> type external;
>> damping;
>> import [ damp trans-filter-in ];
>> export [ no-192-24s prepend ];
>> remove-private;
>> multipath;
>> neighbor 172.16.0.14 {
>> peer-as 65222;
>> }
>> neighbor 172.16.0.18 {
>> peer-as 65222;
>> }
>> }
>>
>> l...@r3>
>>
>>
>> l...@r3> show configuration policy-options policy-statement ibgp
>> term 1 {
>> from {
>> protocol static;
>> route-filter 192.168.30.0/24 exact;
>> }
>> then accept;
>> }
>> term 2 {
>> from community trans-1-2;
>> then {
>> next-hop self;
>> }
>> }
>>
>> l...@r3>
>>
>> Thanks for your help guys..
>>
>> -Hoogen
>>
>> On Thu, Oct 29, 2009 at 3:36 AM, Sean Clarke wrote:
>>
>>>
>>> What is in your ibgp export policy from R1 to R3 ? Are you putting
>>> something in there to cause an issue ?
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 10/29/09 10:43 AM, Hoogen wrote:
>>>
>>> Hi Felix,
>>>
>>> Thank you for the reply..
>>>
>
Re: [j-nsp] JNCIP EBGP Case Study...
Okay.. Earlier task required while accepting routes from peer to tag them
with a community and prepend them with as number 65412 twice... I notice
that when I deactivate that.. It works.. So obviously R3 is considering the
routes received from R1 with prepend of 65412 for all P1 routes to be some
sort of as loop... So I guess there is something wrong about it..
Page 568 of the JNCIP books...
-Hoogen
On Thu, Oct 29, 2009 at 2:05 PM, Hoogen wrote:
> R1
>
> l...@r1> show configuration routing-options
> static {
> route 10.0.200.0/24 {
> next-hop 10.0.1.102;
> no-readvertise;
> }
> route 192.168.10.0/24 reject;
> route 192.168.100.0/24 reject;
> route 10.0.0.0/8 {
> next-hop 10.0.4.13;
> qualified-next-hop 10.0.4.6 {
> preference 10;
> }
> }
> }
> martians {
> 192.0.2.0/24 orlonger;
> }
> autonomous-system 65000;
> confederation 65412 members [ 65000 65001 65002 ];
>
> l...@r1>
>
> l...@r1> show configuration protocols bgp
> group 65000 {
> type internal;
> local-address 10.0.6.1;
> export ibgp;
> neighbor 10.0.3.3;
> }
> group p1 {
> type external;
> import peer-filter-in;
> export p1-export;
> neighbor 10.0.5.254 {
> peer-as 1492;
> }
> }
>
> l...@r1>
>
> l...@r1> show configuration policy-options policy-statement ibgp
> term 1 {
> from {
> protocol static;
> route-filter 192.168.10.0/24 exact;
> }
> then accept;
> }
> term 2 {
> from {
> protocol static;
> route-filter 192.168.100.0/24 exact;
> }
> then {
> metric 101;
> local-preference 101;
> community add no-export;
> accept;
> }
> }
>
> l...@r1>
>
> R3 Configuration
>
> l...@r3> show configuration routing-options
> static {
> route 10.0.200.0/24 {
> next-hop 10.0.1.102;
> no-readvertise;
> }
> route 192.168.30.0/24 reject;
> }
> martians {
> 192.0.2.0/24 orlonger;
> }
> aggregate {
> route 10.0.4.0/22;
> }
> autonomous-system 65000;
> confederation 65412 members [ 65000 65001 65002 ];
>
> l...@r3>
>
> l...@r3> show configuration protocols bgp
> advertise-inactive;
> group 65000 {
> type internal;
> local-address 10.0.3.3;
> export ibgp;
> neighbor 10.0.6.1;
> }
> group c-bgp {
> type external;
> multihop;
> local-address 10.0.3.3;
> export ibgp;
> neighbor 10.0.3.4 {
> hold-time 180;
> peer-as 65001;
> }
> neighbor 10.0.3.5 {
> peer-as 65002;
> }
> }
> group t1-t2 {
> type external;
> damping;
> import [ damp trans-filter-in ];
> export [ no-192-24s prepend ];
> remove-private;
> multipath;
> neighbor 172.16.0.14 {
> peer-as 65222;
> }
> neighbor 172.16.0.18 {
> peer-as 65222;
> }
> }
>
> l...@r3>
>
>
> l...@r3> show configuration policy-options policy-statement ibgp
> term 1 {
> from {
> protocol static;
> route-filter 192.168.30.0/24 exact;
> }
> then accept;
> }
> term 2 {
> from community trans-1-2;
> then {
> next-hop self;
> }
> }
>
> l...@r3>
>
> Thanks for your help guys..
>
> -Hoogen
>
> On Thu, Oct 29, 2009 at 3:36 AM, Sean Clarke wrote:
>
>>
>> What is in your ibgp export policy from R1 to R3 ? Are you putting
>> something in there to cause an issue ?
>>
>>
>>
>>
>>
>>
>> On 10/29/09 10:43 AM, Hoogen wrote:
>>
>> Hi Felix,
>>
>> Thank you for the reply..
>>
>> I am not sure how that 17 hidden routes came into play... But its not
>> there now.. I still see the issue..
>>
>> I had already checked the hidden routes..and those are not the ones
>> which are hiding
>>
>> l...@r3# run show route receive-protocol bgp 10.0.6.1 hidden extensive
>>
>> inet.0: 66 destinations, 85 routes (63 active, 0 holddown, 3 hidden)
>>
>> __juniper_private1__.inet.0: 2 destinations, 2 routes (2 active, 0
>> holddown, 0 hidden)
>>
>> iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
>>
>> [edit]
>> l...@r3#
>>
>> l...@r3# run show route receive-protocol bgp 10.0.6.1
>>
>>
>> inet.0: 66 destinations, 85 routes (63 active, 0 holddown, 3 hidden)
>> Prefix Nexthop MED Lclpref
Re: [j-nsp] JNCIP EBGP Case Study...
R1
l...@r1> show configuration routing-options
static {
route 10.0.200.0/24 {
next-hop 10.0.1.102;
no-readvertise;
}
route 192.168.10.0/24 reject;
route 192.168.100.0/24 reject;
route 10.0.0.0/8 {
next-hop 10.0.4.13;
qualified-next-hop 10.0.4.6 {
preference 10;
}
}
}
martians {
192.0.2.0/24 orlonger;
}
autonomous-system 65000;
confederation 65412 members [ 65000 65001 65002 ];
l...@r1>
l...@r1> show configuration protocols bgp
group 65000 {
type internal;
local-address 10.0.6.1;
export ibgp;
neighbor 10.0.3.3;
}
group p1 {
type external;
import peer-filter-in;
export p1-export;
neighbor 10.0.5.254 {
peer-as 1492;
}
}
l...@r1>
l...@r1> show configuration policy-options policy-statement ibgp
term 1 {
from {
protocol static;
route-filter 192.168.10.0/24 exact;
}
then accept;
}
term 2 {
from {
protocol static;
route-filter 192.168.100.0/24 exact;
}
then {
metric 101;
local-preference 101;
community add no-export;
accept;
}
}
l...@r1>
R3 Configuration
l...@r3> show configuration routing-options
static {
route 10.0.200.0/24 {
next-hop 10.0.1.102;
no-readvertise;
}
route 192.168.30.0/24 reject;
}
martians {
192.0.2.0/24 orlonger;
}
aggregate {
route 10.0.4.0/22;
}
autonomous-system 65000;
confederation 65412 members [ 65000 65001 65002 ];
l...@r3>
l...@r3> show configuration protocols bgp
advertise-inactive;
group 65000 {
type internal;
local-address 10.0.3.3;
export ibgp;
neighbor 10.0.6.1;
}
group c-bgp {
type external;
multihop;
local-address 10.0.3.3;
export ibgp;
neighbor 10.0.3.4 {
hold-time 180;
peer-as 65001;
}
neighbor 10.0.3.5 {
peer-as 65002;
}
}
group t1-t2 {
type external;
damping;
import [ damp trans-filter-in ];
export [ no-192-24s prepend ];
remove-private;
multipath;
neighbor 172.16.0.14 {
peer-as 65222;
}
neighbor 172.16.0.18 {
peer-as 65222;
}
}
l...@r3>
l...@r3> show configuration policy-options policy-statement ibgp
term 1 {
from {
protocol static;
route-filter 192.168.30.0/24 exact;
}
then accept;
}
term 2 {
from community trans-1-2;
then {
next-hop self;
}
}
l...@r3>
Thanks for your help guys..
-Hoogen
On Thu, Oct 29, 2009 at 3:36 AM, Sean Clarke wrote:
>
> What is in your ibgp export policy from R1 to R3 ? Are you putting
> something in there to cause an issue ?
>
>
>
>
>
>
> On 10/29/09 10:43 AM, Hoogen wrote:
>
> Hi Felix,
>
> Thank you for the reply..
>
> I am not sure how that 17 hidden routes came into play... But its not
> there now.. I still see the issue..
>
> I had already checked the hidden routes..and those are not the ones which
> are hiding
>
> l...@r3# run show route receive-protocol bgp 10.0.6.1 hidden extensive
>
> inet.0: 66 destinations, 85 routes (63 active, 0 holddown, 3 hidden)
>
> __juniper_private1__.inet.0: 2 destinations, 2 routes (2 active, 0
> holddown, 0 hidden)
>
> iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
>
> [edit]
> l...@r3#
>
> l...@r3# run show route receive-protocol bgp 10.0.6.1
>
> inet.0: 66 destinations, 85 routes (63 active, 0 holddown, 3 hidden)
> Prefix Nexthop MED LclprefAS path
> * 192.168.10.0/24 10.0.6.1 100I
> * 192.168.100.0/2410.0.6.1 101 101I
>
> __juniper_private1__.inet.0: 2 destinations, 2 routes (2 active, 0
> holddown, 0 hidden)
>
> iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
>
> [edit]
> l...@r3#
>
> l...@r3# run show route protocol bgp hidden extensive
>
> inet.0: 66 destinations, 85 routes (63 active, 0 holddown, 3 hidden)
> 172.17.0.0/16 (1 entry, 0 announced)
> BGP /-101
> Next-hop reference count: 2
> Source: 172.16.0.14
> Next hop: 172.16.0.14 via ge-0/0/0.0, selected
> State:
> Local AS: 65000 Peer AS: 65222
> Age: 1:27:54
> Task: BGP_65222.172.16.0.14+3227
> AS path: 65222 I
> Localpref: 100
> Router ID: 130.130.0.1
>
> 192.0.2.0/24 (1 entry, 0 announced)
> BGP /-101
> Next-hop reference count: 5
> Source: 172.16.0.18
> Next hop: 172.16.0.18 via ge-0/0/3.0, selected
> State:
> Local AS: 65
Re: [j-nsp] JNCIP EBGP Case Study...
Hi Felix,
Thank you for the reply..
I am not sure how that 17 hidden routes came into play... But its not there
now.. I still see the issue..
I had already checked the hidden routes..and those are not the ones which
are hiding
l...@r3# run show route receive-protocol bgp 10.0.6.1 hidden extensive
inet.0: 66 destinations, 85 routes (63 active, 0 holddown, 3 hidden)
__juniper_private1__.inet.0: 2 destinations, 2 routes (2 active, 0 holddown,
0 hidden)
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
[edit]
l...@r3#
l...@r3# run show route receive-protocol bgp 10.0.6.1
inet.0: 66 destinations, 85 routes (63 active, 0 holddown, 3 hidden)
Prefix Nexthop MED LclprefAS path
* 192.168.10.0/24 10.0.6.1 100I
* 192.168.100.0/2410.0.6.1 101 101I
__juniper_private1__.inet.0: 2 destinations, 2 routes (2 active, 0 holddown,
0 hidden)
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
[edit]
l...@r3#
l...@r3# run show route protocol bgp hidden extensive
inet.0: 66 destinations, 85 routes (63 active, 0 holddown, 3 hidden)
172.17.0.0/16 (1 entry, 0 announced)
BGP /-101
Next-hop reference count: 2
Source: 172.16.0.14
Next hop: 172.16.0.14 via ge-0/0/0.0, selected
State:
Local AS: 65000 Peer AS: 65222
Age: 1:27:54
Task: BGP_65222.172.16.0.14+3227
AS path: 65222 I
Localpref: 100
Router ID: 130.130.0.1
192.0.2.0/24 (1 entry, 0 announced)
BGP /-101
Next-hop reference count: 5
Source: 172.16.0.18
Next hop: 172.16.0.18 via ge-0/0/3.0, selected
State:
Local AS: 65000 Peer AS: 65222
Age: 1:28:19
Task: BGP_65222.172.16.0.18+179
AS path: 65222 I
Communities: 65412:102
Localpref: 100
Router ID: 130.130.0.2
220.0.0.0/28 (1 entry, 0 announced)
BGP /-101
Next-hop reference count: 5
Source: 172.16.0.18
Next hop: 172.16.0.18 via ge-0/0/3.0, selected
State:
Local AS: 65000 Peer AS: 65222
Age: 1:28:19
Task: BGP_65222.172.16.0.18+179
AS path: 65222 I
Localpref: 100
Router ID: 130.130.0.2
__juniper_private1__.inet.0: 2 destinations, 2 routes (2 active, 0 holddown,
0 hidden)
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
[edit]
l...@r3#
The one I am concerned is with group 65000 and I don't have any import
policy to deny anything there..
[edit]
l...@r3# show protocols bgp
advertise-inactive;
group 65000 {
type internal;
local-address 10.0.3.3;
export ibgp;
neighbor 10.0.6.1;
}
group c-bgp {
type external;
multihop;
local-address 10.0.3.3;
export ibgp;
neighbor 10.0.3.4 {
hold-time 180;
peer-as 65001;
}
neighbor 10.0.3.5 {
peer-as 65002;
}
}
group t1-t2 {
type external;
damping;
import [ damp trans-filter-in ];
export [ no-192-24s prepend ];
remove-private;
multipath;
neighbor 172.16.0.14 {
peer-as 65222;
}
neighbor 172.16.0.18 {
peer-as 65222;
}
}
[edit]
l...@r3#
This is really strange.. I compared the solutions, and there seems nothing
wrong..
-Hoogen
On Thu, Oct 29, 2009 at 1:59 AM, Felix Schueren <
felix.schue...@hosteurope.de> wrote:
> Hoogen,
>
> Hoogen wrote:
> >>> Now R3 only receives
> >>>
> >>> l...@r3# run show route receive-protocol bgp 10.0.6.1
> >>>
> >>> inet.0: 66 destinations, 106 routes (63 active, 0 holddown, 17 hidden)
> >>> Prefix Nexthop MED LclprefAS
> path
> >>> * 192.168.10.0/24 10.0.6.1 100I
> >>> * 192.168.100.0/2410.0.6.1 101 101I
> >>>
> please do
> show route receive-protocol bgp 10.0.6.1 hidden extensive
>
> also paste
> show configuration protocols bgp
>
> both from R3
>
> Kind regards,
>
> Felix
>
> --
> Felix Schüren
> Head of Network
>
> ---
> Host Europe GmbH - http://www.hosteurope.de
> Welserstraße 14 - 51149 Köln - Germany
> Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*)
> HRB 28495 Amtsgericht Köln - USt-IdNr.: DE187370678
> Geschäftsführer:
> Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulvermüller
>
> (*) 0,14 EUR/Min. aus dem dt. Festnetz, Mobilfunkpreise ggf. abweichend
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JNCIP EBGP Case Study...
Hi Sean, Thank you for the reply... l...@r3# run show route 10.0.5.254 inet.0: 66 destinations, 85 routes (63 active, 0 holddown, 3 hidden) + = Active Route, - = Last Active, * = Both 10.0.5.0/24*[IS-IS/15] 00:23:12, metric 106 > to 10.0.4.14 via ge-0/0/1.200 to 10.0.4.2 via ge-0/0/2.0 [edit] l...@r3# The Link between P1-R1 is being advertised by the IGP.. So next-hop self isn't required for this peer. I would assume if the nex-hop is a problem.. the route would be hidden and set to Unusuable.. But this is not the case... I just don't seem to receive the route. -Hoogen On Thu, Oct 29, 2009 at 1:43 AM, Sean Clarke wrote: > > Are you doing "Next hop self" on R1 to advertise to R3, or are you trying > to send the routes without R3 knowing anything about the eBGP next-hop > 10.0.5.254 ? If the latter, advertise the link between R1 and P1 passively > towards R3 > > > > On 10/29/09 9:27 AM, Hoogen wrote: > >> Well I am working with my J-Series routers to do most topologies.. This >> problem has somehow baffled me alot. Any help is greatly appreciated... >> >> A part of topology.. I think the problem lies somewhere in this... >> >> P1---R1---R3 (Both R1 and R3 are in 65000... and R1 is peering with P1 >> which >> is AS 1492) >> >> R1 receives >> >> l...@r1# run show route receive-protocol bgp 10.0.5.254 >> >> inet.0: 65 destinations, 69 routes (63 active, 0 holddown, 4 hidden) >> Prefix Nexthop MED LclprefAS path >> * 3.4.0.0/20 10.0.5.254 1492 I >> * 6.0.0.0/7 10.0.5.254 1492 I >> * 120.120.0.0/24 10.0.5.254 1492 I >> * 120.120.1.0/24 10.0.5.254 1492 I >> * 120.120.2.0/24 10.0.5.254 1492 I >> * 120.120.3.0/24 10.0.5.254 1492 I >> * 120.120.4.0/24 10.0.5.254 1492 I >> * 120.120.5.0/24 10.0.5.254 1492 I >> * 120.120.6.0/24 10.0.5.254 1492 I >> * 120.120.7.0/24 10.0.5.254 1492 I >> * 120.120.69.128/25 10.0.5.254 1492 I >> >> __juniper_private1__.inet.0: 2 destinations, 2 routes (2 active, 0 >> holddown, >> 0 hidden) >> >> iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) >> >> [edit] >> l...@r1# >> >> And then R1 sends this to R3 >> >> l...@r1# run show route advertising-protocol bgp 10.0.3.3 >> >> inet.0: 65 destinations, 69 routes (63 active, 0 holddown, 4 hidden) >> Prefix Nexthop MED LclprefAS path >> * 3.4.0.0/20 10.0.5.254 10065412 >> 65412 1492 I >> * 6.0.0.0/7 10.0.5.254 10065412 >> 65412 1492 I >> * 120.120.0.0/24 10.0.5.254 10065412 >> 65412 1492 I >> * 120.120.1.0/24 10.0.5.254 10065412 >> 65412 1492 I >> * 120.120.2.0/24 10.0.5.254 10065412 >> 65412 1492 I >> * 120.120.3.0/24 10.0.5.254 10065412 >> 65412 1492 I >> * 120.120.4.0/24 10.0.5.254 10065412 >> 65412 1492 I >> * 120.120.5.0/24 10.0.5.254 10065412 >> 65412 1492 I >> * 120.120.6.0/24 10.0.5.254 10065412 >> 65412 1492 I >> * 120.120.7.0/24 10.0.5.254 10065412 >> 65412 1492 I >> * 120.120.69.128/25 10.0.5.254 10065412 >> 65412 1492 I >> * 192.168.10.0/24 Self 100I >> * 192.168.100.0/24Self 101 101I >> >> [edit] >> l...@r1# >> >> So far so good... >> >> Now R3 only receives >> >> l...@r3# run show route receive-protocol bgp 10.0.6.1 >> >> inet.0: 66 destinations, 106 routes (63 active, 0 holddown, 17 hidden) >> Prefix Nexthop MED LclprefAS path >> * 192.168.10.0/24 10.0.6.1 100I >> * 192.168.100.0/2410.0.6.1 101 101I >> >> __juniper_private1__.inet.0: 2 destinations,
[j-nsp] JNCIP EBGP Case Study...
Well I am working with my J-Series routers to do most topologies.. This
problem has somehow baffled me alot. Any help is greatly appreciated...
A part of topology.. I think the problem lies somewhere in this...
P1---R1---R3 (Both R1 and R3 are in 65000... and R1 is peering with P1 which
is AS 1492)
R1 receives
l...@r1# run show route receive-protocol bgp 10.0.5.254
inet.0: 65 destinations, 69 routes (63 active, 0 holddown, 4 hidden)
Prefix Nexthop MED LclprefAS path
* 3.4.0.0/20 10.0.5.254 1492 I
* 6.0.0.0/7 10.0.5.254 1492 I
* 120.120.0.0/24 10.0.5.254 1492 I
* 120.120.1.0/24 10.0.5.254 1492 I
* 120.120.2.0/24 10.0.5.254 1492 I
* 120.120.3.0/24 10.0.5.254 1492 I
* 120.120.4.0/24 10.0.5.254 1492 I
* 120.120.5.0/24 10.0.5.254 1492 I
* 120.120.6.0/24 10.0.5.254 1492 I
* 120.120.7.0/24 10.0.5.254 1492 I
* 120.120.69.128/25 10.0.5.254 1492 I
__juniper_private1__.inet.0: 2 destinations, 2 routes (2 active, 0 holddown,
0 hidden)
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
[edit]
l...@r1#
And then R1 sends this to R3
l...@r1# run show route advertising-protocol bgp 10.0.3.3
inet.0: 65 destinations, 69 routes (63 active, 0 holddown, 4 hidden)
Prefix Nexthop MED LclprefAS path
* 3.4.0.0/20 10.0.5.254 10065412
65412 1492 I
* 6.0.0.0/7 10.0.5.254 10065412
65412 1492 I
* 120.120.0.0/24 10.0.5.254 10065412
65412 1492 I
* 120.120.1.0/24 10.0.5.254 10065412
65412 1492 I
* 120.120.2.0/24 10.0.5.254 10065412
65412 1492 I
* 120.120.3.0/24 10.0.5.254 10065412
65412 1492 I
* 120.120.4.0/24 10.0.5.254 10065412
65412 1492 I
* 120.120.5.0/24 10.0.5.254 10065412
65412 1492 I
* 120.120.6.0/24 10.0.5.254 10065412
65412 1492 I
* 120.120.7.0/24 10.0.5.254 10065412
65412 1492 I
* 120.120.69.128/25 10.0.5.254 10065412
65412 1492 I
* 192.168.10.0/24 Self 100I
* 192.168.100.0/24Self 101 101I
[edit]
l...@r1#
So far so good...
Now R3 only receives
l...@r3# run show route receive-protocol bgp 10.0.6.1
inet.0: 66 destinations, 106 routes (63 active, 0 holddown, 17 hidden)
Prefix Nexthop MED LclprefAS path
* 192.168.10.0/24 10.0.6.1 100I
* 192.168.100.0/2410.0.6.1 101 101I
__juniper_private1__.inet.0: 2 destinations, 2 routes (2 active, 0 holddown,
0 hidden)
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
[edit]
l...@r3#
I check to see if I have an import policy but it's not present... I am not
sure why I am not receiving any routes from R1 except for those internal
routes...
group 65000 {
type internal;
local-address 10.0.3.3;
export ibgp;
neighbor 10.0.6.1;
}
As you notice there is no policy to deny any routes.. Can someone help me
out here..
-Hoogen
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OSPF Configuration Changes
OSPF works the same in Juniper or Cisco world. But considering 8 routers it wouldn't affect a lot. But do make a topology diagram to just check the links and the cost that might be associated after the change. That would actually be type 10. There would be a small flood of these LSA to even those routers that do not understand this. But is should be okay. -Hoogen On Mon, Sep 28, 2009 at 9:13 AM, Matthew Walster wrote: > Hey there, > > I'm currently using the default reference-bandwidth for OSPF (presumably > 100M) and would like to change this to 10G to reflect link-capacities more > accurately. > > I have a mix of M7i, MX240 and J6350 at the moment - most of which are > running 9.5, though I believe the J-series routers might be running 8.5. > There are 8 routers in total. > > Is this change "safe" to make on a live system, i.e., will it reset the > OSPF > link-state database, or will it just re-broadcast an LSA as it does in the > Cisco world? > > Additionally, if I was to add OSPF traffic-engineering type 7 LSAs in > preparation for adding MPLS to the network, is that "safe" to change on a > live network? Would it be advisable to change everything at once (with > commit confirmed, of course), or to stagger it over a number of iterations? > > Input 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] ISIS Case Study in JNCIP..Summarization into Backbone
Thank you Daniel and Farooq.
-Hooge
On Fri, Sep 18, 2009 at 2:55 AM, Daniel Verlouw wrote:
> On Fri, 2009-09-18 at 01:16 -0700, Hoogen wrote:
> > Now from my understanding of the question I need to deny the longer more
> > specific routes... on R5 filter saying 172.16.40/29 longer the reject...
>
> yes it is quite common to suppress the more specifics. A more scalable
> approach would be to use the 'aggregate-contributor' match condition to
> suppress the more specifics, e.g.:
>
> term accept-aggregates {
> from {
>protocol aggregate;
> }
> to level 2;
> then accept;
> }
> term reject-more-specifics {
> from {
>aggregate-contributor;
> }
> to level 2;
> then reject;
> }
>
>
> --Daniel.
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] ISIS Case Study in JNCIP..Summarization into Backbone
Hi,
My question is when we redistribute 172.16.40.0/30 and 172.16.40.4/30 subnet
on R6 and R7...it reaches R5... and we see the output as
l...@r5# run show route 172.16.40.0/29
inet.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.40.0/30 *[IS-IS/15] 00:17:21, metric 6
> to 10.0.8.5 via ge-0/0/0.0
172.16.40.4/30 *[IS-IS/15] 00:16:53, metric 6
> to 10.0.8.10 via ge-0/0/1.0
[edit]
l...@r5#
Now we need to summarize this before sending it into Backbone..
On R5 though we see the policy-option to be
term 3 {
from {
protocol aggregate;
route-filter 172.16.40.0/29 exact;
}
to level 2;
then accept;
}
}
In this we have it accepting aggregate route 172.16.40/29
Now in the whole policy on R5 we do not discard the more specific routes
from entering the Backbone area
And on R3 we see those three routes along with the aggregate route...
l...@r3# run show route 172.16.40.0/29
inet.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.40.0/29 *[IS-IS/165] 00:04:07, metric 13
> to 10.0.2.1 via t1-2/0/0.35
172.16.40.0/30 *[IS-IS/18] 00:12:15, metric 9
> to 10.0.2.1 via t1-2/0/0.35
172.16.40.4/30 *[IS-IS/18] 00:11:47, metric 9
> to 10.0.2.1 via t1-2/0/0.35
[edit]
l...@r3#
Now from my understanding of the question I need to deny the longer more
specific routes... on R5 filter saying 172.16.40/29 longer the reject...
So that on R3 and R4 I only see
l...@r3# run show route 172.16.40.0/29
inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.40.0/29 *[IS-IS/165] 00:04:29, metric 13
> to 10.0.2.1 via t1-2/0/0.35
[edit]
l...@r3#
Is my understanding right.. or is this step not required ...I do not see
this extra solution in the book..
-Hoogen
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OSPF case study... nbma between R3-R4..causing adjacency issues
Got that...From an old post... I wanted to do a multi point since I knew it
would work.. But seems like Harry did confirm that..
I would try adding the multipoint keyword under the interface unit, and also
add mapping for each remote dlci. The latter is needed due to lack of inarp
response (if that is still the case).
unit 0 { wrote:
> Hi All,
>
>
> For a good measure I checked the link ip address between 10.0.2.5 and
> 10.0.2.6 there is no netmask issues This is a requirement as stated in
> OSPF case study in JNCIP book. To make the link between R3-R4 to have a DR
> election... So i made it an nbma interface... which is now causing the
> adjacency to break.
>
> I verified the hello packets by the interface detail command... it does
> show up as 30 and 120 (h/D)... so no issues there...
>
> Any help is greatly appreciated...
>
>
> Interface configuration
>
> R3
> t1-1/0/0 {
> hold-time up 30 down 30;
> encapsulation frame-relay;
> lmi {
> n392dte 2;
> n393dte 3;
> t391dte 15;
> lmi-type itu;
> }
> unit 100 {
> bandwidth 155m;
> dlci 100;
> family inet {
> address 10.0.2.5/30;
> }
> }
> }
> ###
> area 0.0.0.0 {
> interface t1-1/0/0.100 {
> interface-type nbma;
> neighbor 10.0.2.6 eligible;
> }
>
>
> R4
>
> t1-1/0/0 {
> dce;
> hold-time up 30 down 30;
> encapsulation frame-relay;
> lmi {
> n392dce 2;
> n393dce 3;
> t392dce 25;
> lmi-type itu;
> }
> unit 100 {
> bandwidth 155m;
> dlci 100;
> family inet {
> address 10.0.2.6/30;
> }
> }
> }
>
>
>
> area 0.0.0.0 {
> interface t1-1/0/0.100 {
> interface-type nbma;
> neighbor 10.0.2.5 eligible;
> }
>
> Sep 9 17:07:54.604230 OSPF rcvd Hello 10.0.2.5 -> 10.0.2.6 (t1-1/0/0.100,
> IFL 0x44)
> Sep 9 17:07:54.604237 Version 2, length 44, ID 10.0.3.3, area 0.0.0.0
> Sep 9 17:07:54.604242 checksum 0x0, authtype 0
> Sep 9 17:07:54.604248 mask 255.255.255.252, hello_ivl 30, opts 0x2, prio
> 128
> Sep 9 17:07:54.604253 dead_ivl 120, DR 0.0.0.0, BDR 0.0.0.0
> *Sep 9 17:07:54.604259 OSPF packet ignored: netmask 255.255.255.252
> mismatch from 10.0.2.5*
>
> Did google... but nothing on what I might be doing wrong
> l...@r3#
> *** ospf ***
> Sep 9 17:29:42.537312 OSPF sent Hello -> 10.0.2.6 (t1-1/0/0.100, IFL 0x47)
> Sep 9 17:29:42.538006 OSPF sent Hello 10.0.2.5 -> 10.0.2.6 (t1-1/0/0.100,
> IFL 0x47)
> Sep 9 17:29:45.656935 OSPF rcvd Hello 10.0.2.6 -> 10.0.2.5 (t1-1/0/0.100,
> IFL 0x47)
> *Sep 9 17:29:45.657005 OSPF packet ignored: netmask 255.255.255.252
> mismatch from 10.0.2.6*
> Sep 9 17:29:46.556973 OSPF rcvd Hello 10.0.2.6 -> 10.0.2.5 (t1-1/0/0.100,
> IFL 0x47)
> Sep 9 17:29:46.557059 OSPF packet ignored: netmask 255.255.255.252 mismatch
> from 10.0.2.6
> Sep 9 17:29:49.336728 OSPF 10.0.2.6 DBD cleanup complete
> Sep 9 17:29:49.336765 OSPF sent Hello -> 10.0.2.6 (t1-1/0/0.100, IFL 0x47)
> run monitor stop
>
> [edit]
> l...@r3#
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] OSPF case study... nbma between R3-R4..causing adjacency issues
Hi All,
For a good measure I checked the link ip address between 10.0.2.5 and
10.0.2.6 there is no netmask issues This is a requirement as stated in
OSPF case study in JNCIP book. To make the link between R3-R4 to have a DR
election... So i made it an nbma interface... which is now causing the
adjacency to break.
I verified the hello packets by the interface detail command... it does show
up as 30 and 120 (h/D)... so no issues there...
Any help is greatly appreciated...
Interface configuration
R3
t1-1/0/0 {
hold-time up 30 down 30;
encapsulation frame-relay;
lmi {
n392dte 2;
n393dte 3;
t391dte 15;
lmi-type itu;
}
unit 100 {
bandwidth 155m;
dlci 100;
family inet {
address 10.0.2.5/30;
}
}
}
###
area 0.0.0.0 {
interface t1-1/0/0.100 {
interface-type nbma;
neighbor 10.0.2.6 eligible;
}
R4
t1-1/0/0 {
dce;
hold-time up 30 down 30;
encapsulation frame-relay;
lmi {
n392dce 2;
n393dce 3;
t392dce 25;
lmi-type itu;
}
unit 100 {
bandwidth 155m;
dlci 100;
family inet {
address 10.0.2.6/30;
}
}
}
area 0.0.0.0 {
interface t1-1/0/0.100 {
interface-type nbma;
neighbor 10.0.2.5 eligible;
}
Sep 9 17:07:54.604230 OSPF rcvd Hello 10.0.2.5 -> 10.0.2.6 (t1-1/0/0.100,
IFL 0x44)
Sep 9 17:07:54.604237 Version 2, length 44, ID 10.0.3.3, area 0.0.0.0
Sep 9 17:07:54.604242 checksum 0x0, authtype 0
Sep 9 17:07:54.604248 mask 255.255.255.252, hello_ivl 30, opts 0x2, prio
128
Sep 9 17:07:54.604253 dead_ivl 120, DR 0.0.0.0, BDR 0.0.0.0
*Sep 9 17:07:54.604259 OSPF packet ignored: netmask 255.255.255.252
mismatch from 10.0.2.5*
Did google... but nothing on what I might be doing wrong
l...@r3#
*** ospf ***
Sep 9 17:29:42.537312 OSPF sent Hello -> 10.0.2.6 (t1-1/0/0.100, IFL 0x47)
Sep 9 17:29:42.538006 OSPF sent Hello 10.0.2.5 -> 10.0.2.6 (t1-1/0/0.100,
IFL 0x47)
Sep 9 17:29:45.656935 OSPF rcvd Hello 10.0.2.6 -> 10.0.2.5 (t1-1/0/0.100,
IFL 0x47)
*Sep 9 17:29:45.657005 OSPF packet ignored: netmask 255.255.255.252 mismatch
from 10.0.2.6*
Sep 9 17:29:46.556973 OSPF rcvd Hello 10.0.2.6 -> 10.0.2.5 (t1-1/0/0.100,
IFL 0x47)
Sep 9 17:29:46.557059 OSPF packet ignored: netmask 255.255.255.252 mismatch
from 10.0.2.6
Sep 9 17:29:49.336728 OSPF 10.0.2.6 DBD cleanup complete
Sep 9 17:29:49.336765 OSPF sent Hello -> 10.0.2.6 (t1-1/0/0.100, IFL 0x47)
run monitor stop
[edit]
l...@r3#
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JNCIP Case Study - 1 Pg 42 - archive size and files
But since this was in the M-Series... and I would assume when they mentioned
"permit four archived copies that will be no larger than 128K"
The solution should have been "archive size 128k files 4" and not just left
as default. Maybe there was some error in printing. Is there any loss of
points in overdoing anything... In this case I believe I am just setting the
values without caring for the defaults.
-Hoogen
On Mon, Sep 7, 2009 at 10:06 AM, Nalkhande Tarique Abbas <
ntari...@juniper.net> wrote:
>
> The default maximum file size depends on the platform type:
>
> * 128 kilobytes (KB) for J-series Routers
> * 1 (MB) for M-series, MX-series, and T-series routing platforms
> * 10 MB for TX Matrix platforms
>
> So based on the setup/platform this value should be defined or probably
> left to default.
>
>
> Thanks & Regards,
> Tarique A. Nalkhande
>
>
> Original Message-
> From: juniper-nsp-boun...@puck.nether.net
> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Hoogen
> Sent: Monday, September 07, 2009 10:23 PM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] JNCIP Case Study - 1 Pg 42 - archive size and files
>
> Modify the syslog parameters to log all interactive CLI commands to a
> file
> called rn-cli, where n is equal to the router number. Configure the CLI
> log
> to permit four archived copies that will be no larger than 128K, and
> ensure
> that CLI-related logging is also sent to 10.0.200.2, which is providing
> a
> remote syslog service. All other syslog parameters should be left at
> their
> default setting.
>
> Book Solution
>
> syslog {
> user * {
> any emergency;
> }
> host 10.0.200.2 {
> interactive-commands any;
> }
> file messages {
> any notice;
> authorization info;
> }
> file r2-cli {
> interactive-commands any;
> archive files 4;
> }
> }
>
> My concern is the file r2-cli.. wherein archive files 4 is given.. but
> the
> question says "permit four archived copies that will be no larger than
> 128K"
>
> My Solution was
>
> syslog {
> user * {
> any emergency;
> }
> host 10.0.200.2 {
> interactive-commands any;
> }
> file messages {
> any notice;
> authorization info;
> }
> file r1-cli {
> interactive-commands any;
> archive size 128k files 4;
> }
>
> Any insight into this... Am I missing something..
> ___
> 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] JNCIP Case Study - 1 Pg 42 - archive size and files
Modify the syslog parameters to log all interactive CLI commands to a file
called rn-cli, where n is equal to the router number. Configure the CLI log
to permit four archived copies that will be no larger than 128K, and ensure
that CLI-related logging is also sent to 10.0.200.2, which is providing a
remote syslog service. All other syslog parameters should be left at their
default setting.
Book Solution
syslog {
user * {
any emergency;
}
host 10.0.200.2 {
interactive-commands any;
}
file messages {
any notice;
authorization info;
}
file r2-cli {
interactive-commands any;
archive files 4;
}
}
My concern is the file r2-cli.. wherein archive files 4 is given.. but the
question says "permit four archived copies that will be no larger than 128K"
My Solution was
syslog {
user * {
any emergency;
}
host 10.0.200.2 {
interactive-commands any;
}
file messages {
any notice;
authorization info;
}
file r1-cli {
interactive-commands any;
archive size 128k files 4;
}
Any insight into this... Am I missing something..
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Why a transit area cannot be a stub area?
Hi All, I have been trying to look around but any more information would be great... The only thing I understand it can't be done is because RFC says so.. and because just in case the disconnected area has ASBR type 5 external lsa's cannot pass through. Anyone has any more information other than this? -Hoogen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Frame-relay Switching on J-Series
Hi Guys, I have a lab that I am trying to setup, some basics here. I would like to setup a J-Series to act like a Frame-relay switch. Could anyone direct me to some configurations? I am using T1 ports here and would like to get some p2p and p2m configurations. So some configurations would definitely help. Thanks, Hoogen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Load Balancing..
Hi All,
Kind of silly but I am not able to figure this out.. So any help
Appreciated..
I am trying to ping 172.16.1.254.. which works if I remove the load balance
policy but doesn't if I apply it..
-Hoogen
regr...@shiraz> show configuration interfaces
ge-0/0/1 {
vlan-tagging;
unit 40 {
vlan-id 22;
family inet {
address 10.30.40.40/24;
}
}
unit 41 {
vlan-id 23;
family inet {
address 10.30.41.41/24;
}
}
}
regr...@shiraz>
regr...@shiraz> show configuration routing-options
static {
route 172.16.1.0/24 next-hop [ 10.30.40.30 10.30.41.31 ];
route 10.10.20.0/24 next-hop [ 10.30.40.30 10.30.41.31 ];
route 10.20.30.0/24 next-hop [ 10.30.40.30 10.30.41.31 ];
}
forwarding-table {
export PerPkt_loadB;
}
regr...@shiraz>
regr...@shiraz>
regr...@shiraz> show configuration policy-options
policy-statement PerPkt_loadB {
then {
load-balance per-packet;
}
}
regr...@shiraz>
regr...@shiraz> show route detail 172.16.1.0
inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
172.16.1.0/24 (1 entry, 1 announced)
*Static Preference: 5
Next hop type: Router, Next hop index: 262143
Next-hop reference count: 6
Next hop: 10.30.40.30 via ge-0/0/1.40
Next hop: 10.30.41.31 via ge-0/0/1.41, selected
State:
Age: 25:21
Task: RT
Announcement bits (1): 0-KRT
AS path: I
regr...@shiraz>
regr...@shiraz> show route forwarding-table destination 172.16.1.0
Routing table: inet
Internet:
DestinationType RtRef Next hop Type Index NhRef Netif
172.16.1.0/24 user 0ulst 262143 4
10.30.40.30ucst 402 3
ge-0/0/1.40
10.30.41.31ucst 403 3
ge-0/0/1.41
Routing table: __juniper_private1__.inet
Internet:
DestinationType RtRef Next hop Type Index NhRef Netif
defaultperm 0rjct61 1
Routing table: __juniper_private2__.inet
Internet:
DestinationType RtRef Next hop Type Index NhRef Netif
defaultperm 0rjct 101 1
regr...@shiraz>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
