Re: [j-nsp] BGP and OSPF ECMP
Hmm. Normally for LB we expect to see a ulst next hop, which in turn contains
two or more ucst NHs. The FT display indicates that a single NH is installed
for that prefix.
Can you describe the nature of the test traffic? If its all one flow I'd expect
all to take the same NH even when LB is in effect. AFAIK, MX behavior is no
different here.
Regards
> -Original Message-
> From: Marlon Duksa [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 17, 2008 1:57 PM
> To: Harry Reynolds; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] BGP and OSPF ECMP
>
> I tried this on MX960 and it seams that load balancing is on
> by default. How do I turn load balancing off?
> In the RT I can see both next hops:
> 2.2.2.2/32 *[OSPF/10] 02:21:29, metric 1
> to 10.0.2.2 via ge-8/0/5.0
> > to 10.0.3.2 via ge-5/1/0.0
>
>
> In the FT I can see only one path:
> 2.2.2.2/32 user 1 10.0.3.2 ucst 572
> 5 ge-5/1/0.0
>
> But when I actually send traffic and run 'monitor interface
> traffic', I see that traffic is going out over both links.
> This 2.2.2.2 next hop is actually a PE router in VPN.
>
> Is load balancing on by default on MX? I didn't configure
> anything special to turn it on.
>
>
> On Tue, Jul 15, 2008 at 6:43 AM, Boyd, Benjamin R
> <[EMAIL PROTECTED]> wrote:
>
>
> You can further control the flow with:
>
> [edit forwarding-options hash-key]
>
> family inet {
> layer-3;
> layer-4;
> }
> family mpls {
> label-1;
> label-2;
> }
>
> If you're load balancing over a decent amount of hops I
> wouldn't hash
> both layer-3/layer-4 and label-1/label-2 on every
> router because then
> your per-flow becomes quite segregated and you might
> find issues where
> your load balancing on many routers will break the
> seemingly load
> balancing of another router since the hashing algorithm
> will produce the
> same result on each router.
>
> -Ben
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
>
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Harry Reynolds
> Sent: Monday, July 14, 2008 6:18 PM
> To: Marlon Duksa; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] BGP and OSPF ECMP
>
> Do you have a per-packet (really per flow) LB policy
> applied to the
> forwarding table?
>
> This is needed to install two or more forwarding paths
> in the pfe. BGP
> multipath is a control plane tie breaker, but by
> default only one of the
> winners is installed as active in the FT.
>
> HTHs
>
>
> [edit]
> [EMAIL PROTECTED] show policy-options
> policy-statement lb {
> then {
> load-balance per-packet;
> }
> }
>
> [edit]
> [EMAIL PROTECTED] show routing-options forwarding-table
> traceoptions {
> file forwarding_table;
> flag route detail;
> }
> export lb;
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On
> Behalf Of Marlon Duksa
> > Sent: Monday, July 14, 2008 3:22 PM
> > To: juniper-nsp@puck.nether.net
> > Subject: [j-nsp] BGP and OSPF ECMP
> >
> > Does anyone know how to enable ecmp in Junos (I'm on M320
> > with Junos 9.0)?
> >
> > I have a vrf with BGP configured for multipath. In the
> > forwarding table I see only one path installed even though I
> > have two equal cost physical links to the NH.
> > My IGP is OSPF and in the routing table OSPF is showing two
> > paths (only one active >) and in the fwd table only one path
> > is selected. How do I force Junos to select both links.
> >
> > Similar with LDP which is used for the transport (tunnel) in
> > this VPN environment.
> >
> > So it looks to me that multipath in BGP is not taking effect
> > because underlying protocols (OSPF and LDP) is not utilizing
> > both links??
> > Thanks,
> > Marlon
> > ___
> > 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
>
>
>
>
>
> **
> *
>
> The information contained in this message, including
> attachments, may contain
> privileged or confidential information that is intended
> to be delivered only to the
> person ide
Re: [j-nsp] NSRP through 802.1Q trunks
I tried to hard code the peer MAC for probes and it hasnt taken exec nsrp probe interface [ mac_addr ] I still see the default NSRP MAC for the destination On Thu, Jul 17, 2008 at 9:01 AM, Ivan c <[EMAIL PROTECTED]> wrote: > Doesn't seem to be the case though, even though logic would dictate > that the switch should just pass the frames > > I am starting to suspect that the Nortel do not recognise the frames > and thus are dropping it, as the HA interface MAC only appears on the > access port and not on the trunk port. > > HA1 dot1q trunk > HA1 > NS5400<--->5520<-->5520<--->NS5400 > > It would be helpfull if Juniper provided at least minimual detail on > the protocol. > > Any Nortel ninja's out there? > > cheers > Ivan > > On Thu, Jul 17, 2008 at 12:03 AM, Stefan Fouant <[EMAIL PROTECTED]> wrote: >> You'll be fine as long as you are not expecting the Netscreen to tag >> the frames. Otherwise, the HA interfaces (or pseudo-HA interfaces >> that you've designated as such) look like regular Ethernet interfaces, >> so as long as you've got a normal Ethernet handoff with end-to-end L2 >> connectivity between both pair of devices it should work. Heck, I >> suppose you could even run NSRP over an L2VPN if you wanted, not sure >> why one would want to do so, but it's possible... >> >> HTHs. >> >> On Tue, Jul 15, 2008 at 8:54 PM, Ivan c <[EMAIL PROTECTED]> wrote: >>> Hey, anyone have any experience with running active/passive NSRP >>> betwen datacentres via 802.1Q trunks? specially through Nortel 5520 >>> switches? >>> >>> I can't find any specific info on NSRP protocol requirements, only >>> from the screenos cookbook, which states "The only requirement is that >>> the Layer 2 frames arrive at the remote peer as sent." >>> >>> I have verfied the trunking works by plugging in laptops on each end >>> with an IP on the same vlan, and connectivity is fine. >>> The get nrsp ha says state:disconnected and I have the NSRP HA probes >>> running. >>> >>> Any special requirements or info on trunking NSRP? >>> >>> thanks >>> Ivan >>> ___ >>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>> >> >> >> >> -- >> Stefan Fouant >> Principal Network Engineer >> NeuStar, Inc. - http://www.neustar.biz >> GPG Key ID: 0xB5E3803D >> > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP and OSPF ECMP
I tried this on MX960 and it seams that load balancing is on by default. How
do I turn load balancing off?
In the RT I can see both next hops:
2.2.2.2/32 *[OSPF/10] 02:21:29, metric 1
to 10.0.2.2 via ge-8/0/5.0
> to 10.0.3.2 via ge-5/1/0.0
In the FT I can see only one path:
2.2.2.2/32 user 1 10.0.3.2 ucst 572 5 ge-5/1/0.0
But when I actually send traffic and run 'monitor interface traffic', I see
that traffic is going out over both links.
This 2.2.2.2 next hop is actually a PE router in VPN.
Is load balancing on by default on MX? I didn't configure anything special
to turn it on.
On Tue, Jul 15, 2008 at 6:43 AM, Boyd, Benjamin R <
[EMAIL PROTECTED]> wrote:
> You can further control the flow with:
>
> [edit forwarding-options hash-key]
>
> family inet {
>layer-3;
>layer-4;
> }
> family mpls {
>label-1;
>label-2;
> }
>
> If you're load balancing over a decent amount of hops I wouldn't hash
> both layer-3/layer-4 and label-1/label-2 on every router because then
> your per-flow becomes quite segregated and you might find issues where
> your load balancing on many routers will break the seemingly load
> balancing of another router since the hashing algorithm will produce the
> same result on each router.
>
> -Ben
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Harry Reynolds
> Sent: Monday, July 14, 2008 6:18 PM
> To: Marlon Duksa; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] BGP and OSPF ECMP
>
> Do you have a per-packet (really per flow) LB policy applied to the
> forwarding table?
>
> This is needed to install two or more forwarding paths in the pfe. BGP
> multipath is a control plane tie breaker, but by default only one of the
> winners is installed as active in the FT.
>
> HTHs
>
>
> [edit]
> [EMAIL PROTECTED] show policy-options
> policy-statement lb {
>then {
>load-balance per-packet;
>}
> }
>
> [edit]
> [EMAIL PROTECTED] show routing-options forwarding-table traceoptions {
>file forwarding_table;
>flag route detail;
> }
> export lb;
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Marlon Duksa
> > Sent: Monday, July 14, 2008 3:22 PM
> > To: juniper-nsp@puck.nether.net
> > Subject: [j-nsp] BGP and OSPF ECMP
> >
> > Does anyone know how to enable ecmp in Junos (I'm on M320
> > with Junos 9.0)?
> >
> > I have a vrf with BGP configured for multipath. In the
> > forwarding table I see only one path installed even though I
> > have two equal cost physical links to the NH.
> > My IGP is OSPF and in the routing table OSPF is showing two
> > paths (only one active >) and in the fwd table only one path
> > is selected. How do I force Junos to select both links.
> >
> > Similar with LDP which is used for the transport (tunnel) in
> > this VPN environment.
> >
> > So it looks to me that multipath in BGP is not taking effect
> > because underlying protocols (OSPF and LDP) is not utilizing
> > both links??
> > Thanks,
> > Marlon
> > ___
> > 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
>
>
>
>
> ***
>
> The information contained in this message, including attachments, may
> contain
> privileged or confidential information that is intended to be delivered
> only to the
> person identified above. If you are not the intended recipient, or the
> person
> responsible for delivering this message to the intended recipient,
> Windstream requests
> that you immediately notify the sender and asks that you do not read the
> message or its
> attachments, and that you delete them without copying or sending them to
> anyone else.
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IPSEC into VRF
I know you only asked about the J and MX series. The ERX platform will terminate a tunnel in the VRF. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benny Amorsen Sent: Monday, July 14, 2008 4:08 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] IPSEC into VRF Which Juniper routers can terminate an IPSEC tunnel in a virtual router? M-series and T-series routers with the ES PIC can do it according to this: http://www.juniper.net/products/modules/100089.pdf What about the J-series and the MX-series? /Benny ___ 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] JUNOScript API error
My experience is that JUNOScript would try to initiate the connection to a weird port - I cannot remember which port that it, but you can find out easily by doing a tcpdump. Basically what I did was locating that port number in the source code and changing it to 22. Hope this helps. -Simon On Thu, Jul 17, 2008 at 12:04 PM, Boyd, Benjamin R <[EMAIL PROTECTED]> wrote: > All, > > I'm playing with JUNOScript and after installation I get the following > error: > > [get_chassis_inventory]# perl get_chassis_inventory.pl x.x.x.x -m ssh > login: * > password: > ERROR[1]: recv failed: EOF > ERROR[2]: initial handshake with JUNOScript server failed > > Has anyone seen this or know the fix/cause? > > > -Ben > > *** > > The information contained in this message, including attachments, may contain > privileged or confidential information that is intended to be delivered only > to the > person identified above. If you are not the intended recipient, or the person > responsible for delivering this message to the intended recipient, Windstream > requests > that you immediately notify the sender and asks that you do not read the > message or its > attachments, and that you delete them without copying or sending them to > anyone else. > > ___ > 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] test please ignoring
ignore . ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] JUNOScript API error
All, I'm playing with JUNOScript and after installation I get the following error: [get_chassis_inventory]# perl get_chassis_inventory.pl x.x.x.x -m ssh login: * password: ERROR[1]: recv failed: EOF ERROR[2]: initial handshake with JUNOScript server failed Has anyone seen this or know the fix/cause? -Ben *** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] PtP link over FR
Fair enough. I simply read the scenario involving two routers sharing a frame-relay p2p link. :) Scott -Original Message- From: Jesper Skriver [mailto:[EMAIL PROTECTED] Sent: Thursday, July 17, 2008 9:27 AM To: Scott Morris Cc: 'Farhan Jaffer'; 'Juniper Puck'; [EMAIL PROTECTED] Subject: Re: [j-nsp] PtP link over FR On Thu, Jul 17, 2008 at 07:49:09AM -0400, Scott Morris wrote: > There is no ARP in frame-relay. More specifically, on a P2P > subinterface, there's no mapping either. I think you're mis understanding my suggestion, I was suggesting that router A could only reach router B because the router in the middle did proxy ARP for B's address, so A could reach it. It has nothing to do with ARP over FR. > The assumption is that if it's not MY address it must be yours. So as > long as you believe the other side is within the defined subnet, then > you're good. > > If you have 10.1.1.1/24 on one side, and 10.1.1.2/27 on the other, > they will still talk to each other just fine. At least until you try > to run ospf or something that cares about the netmask! Yes - unless you have 10.1.1.1/24 configured on A towards 'Juniper' and 10.1.1.2/27 configured on B towards 'Juniper' /Jesper > > Scott > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jesper > Skriver > Sent: Thursday, July 17, 2008 7:24 AM > To: Farhan Jaffer > Cc: Juniper Puck; [EMAIL PROTECTED] > Subject: Re: [j-nsp] PtP link over FR > > Let me guess, on Cisco Router A you got an ARP entry for Cisco Router > B's address when you put a Cisco router in the middle, as the Cisco > router has proxy-arp enabled by default. > > Or to put it more clearly the IP addresses used FR p2p pvc is a subset > of the IP addresses used on the link between Cisco Router A and Juniper Router. > > Or on Cisco router A you have a static route without a next-hop > address to the IP subnet used on the FR link > > In either case it's a mis configuration, that gets 'saved'/'hidden' by > the fact proxy-arp is enabled by default on the Cisco router. > > /Jesper > > On Thu, Jul 17, 2008 at 04:06:31PM +0500, Farhan Jaffer wrote: > > Hi, > > > > There is an interesting situation, let me discuss the scenario > > first, > > > > Cisco Router A (same n/w) Juniper Router -(FR > > point-to-point pvc) --- Cisco Router B. > > > > PVC is Active & point to point connectivity is OK. But the ping > > response from cisco router A to B via FR is unreachable & vice versa. > > > > however if i replace Juniper router with Cisco Router, it works fine. > > > > Is there any IP forwarding like thing? or any other problem. > > > > Thanks very much in advance. > > > > -FJ > > ___ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > /Jesper > > -- > Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 > > One Unix to rule them all, One Resolver to find them, One IP to bring > them all and in the zone to bind them. > ___ > 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 /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] PtP link over FR
On Thu, Jul 17, 2008 at 07:49:09AM -0400, Scott Morris wrote: > There is no ARP in frame-relay. More specifically, on a P2P subinterface, > there's no mapping either. I think you're mis understanding my suggestion, I was suggesting that router A could only reach router B because the router in the middle did proxy ARP for B's address, so A could reach it. It has nothing to do with ARP over FR. > The assumption is that if it's not MY address it > must be yours. So as long as you believe the other side is within the > defined subnet, then you're good. > > If you have 10.1.1.1/24 on one side, and 10.1.1.2/27 on the other, they will > still talk to each other just fine. At least until you try to run ospf or > something that cares about the netmask! Yes - unless you have 10.1.1.1/24 configured on A towards 'Juniper' and 10.1.1.2/27 configured on B towards 'Juniper' /Jesper > > Scott > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jesper Skriver > Sent: Thursday, July 17, 2008 7:24 AM > To: Farhan Jaffer > Cc: Juniper Puck; [EMAIL PROTECTED] > Subject: Re: [j-nsp] PtP link over FR > > Let me guess, on Cisco Router A you got an ARP entry for Cisco Router B's > address when you put a Cisco router in the middle, as the Cisco router has > proxy-arp enabled by default. > > Or to put it more clearly the IP addresses used FR p2p pvc is a subset of > the IP addresses used on the link between Cisco Router A and Juniper Router. > > Or on Cisco router A you have a static route without a next-hop address to > the IP subnet used on the FR link > > In either case it's a mis configuration, that gets 'saved'/'hidden' by the > fact proxy-arp is enabled by default on the Cisco router. > > /Jesper > > On Thu, Jul 17, 2008 at 04:06:31PM +0500, Farhan Jaffer wrote: > > Hi, > > > > There is an interesting situation, let me discuss the scenario first, > > > > Cisco Router A (same n/w) Juniper Router -(FR > > point-to-point pvc) --- Cisco Router B. > > > > PVC is Active & point to point connectivity is OK. But the ping > > response from cisco router A to B via FR is unreachable & vice versa. > > > > however if i replace Juniper router with Cisco Router, it works fine. > > > > Is there any IP forwarding like thing? or any other problem. > > > > Thanks very much in advance. > > > > -FJ > > ___ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > /Jesper > > -- > Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 > > One Unix to rule them all, One Resolver to find them, One IP to bring them > all and in the zone to bind them. > ___ > 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 /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Tunnel Services
On Wed, Jul 16, 2008 at 11:59:44AM +0200, [EMAIL PROTECTED] wrote: > - *May* use an explicit tunnel PIC in one of the 4 PIC slots (but since > there is always a built-in tunnel PIC, why would you want to?). If I remember correctly, the onboard "Tunnel PIC" gives you only ~150mbps throughput. I may be wrong as I wasn't able to find any evidence for that anymore in the tech docs on www.juniper.net Best regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] PtP link over FR
Thanks for all. It was one mistake from my side. I used management interface ip address for routes on Juniper :) It's working fine now. Thanks again. -FJ On Thu, Jul 17, 2008 at 4:06 PM, Farhan Jaffer <[EMAIL PROTECTED]> wrote: > Hi, > > There is an interesting situation, let me discuss the scenario first, > > Cisco Router A (same n/w) Juniper Router -(FR > point-to-point pvc) --- Cisco Router B. > > PVC is Active & point to point connectivity is OK. But the ping > response from cisco router A to B via FR is unreachable & vice versa. > > however if i replace Juniper router with Cisco Router, it works fine. > > Is there any IP forwarding like thing? or any other problem. > > Thanks very much in advance. > > -FJ > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] PtP link over FR
There is no ARP in frame-relay. More specifically, on a P2P subinterface, there's no mapping either. The assumption is that if it's not MY address it must be yours. So as long as you believe the other side is within the defined subnet, then you're good. If you have 10.1.1.1/24 on one side, and 10.1.1.2/27 on the other, they will still talk to each other just fine. At least until you try to run ospf or something that cares about the netmask! Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jesper Skriver Sent: Thursday, July 17, 2008 7:24 AM To: Farhan Jaffer Cc: Juniper Puck; [EMAIL PROTECTED] Subject: Re: [j-nsp] PtP link over FR Let me guess, on Cisco Router A you got an ARP entry for Cisco Router B's address when you put a Cisco router in the middle, as the Cisco router has proxy-arp enabled by default. Or to put it more clearly the IP addresses used FR p2p pvc is a subset of the IP addresses used on the link between Cisco Router A and Juniper Router. Or on Cisco router A you have a static route without a next-hop address to the IP subnet used on the FR link In either case it's a mis configuration, that gets 'saved'/'hidden' by the fact proxy-arp is enabled by default on the Cisco router. /Jesper On Thu, Jul 17, 2008 at 04:06:31PM +0500, Farhan Jaffer wrote: > Hi, > > There is an interesting situation, let me discuss the scenario first, > > Cisco Router A (same n/w) Juniper Router -(FR > point-to-point pvc) --- Cisco Router B. > > PVC is Active & point to point connectivity is OK. But the ping > response from cisco router A to B via FR is unreachable & vice versa. > > however if i replace Juniper router with Cisco Router, it works fine. > > Is there any IP forwarding like thing? or any other problem. > > Thanks very much in advance. > > -FJ > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. ___ 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] PtP link over FR
The PVC being "up" is a signaling of LMI telling you that it's in an ACTIVE state. It's more like you can call me on the telephone. But if you speak japanese and I do not, we really can't have much of a conversation yet the "link" is still up! HTH, Scott -Original Message- From: Mark Tinka [mailto:[EMAIL PROTECTED] Sent: Thursday, July 17, 2008 7:25 AM To: juniper-nsp@puck.nether.net; [EMAIL PROTECTED] Cc: 'Farhan Jaffer'; [EMAIL PROTECTED] Subject: Re: [j-nsp] PtP link over FR On Thursday 17 July 2008 19:13:50 Scott Morris wrote: > Juniper routers (like most other vendors) does not do CISCO frame > encapsulation, so if you change to IETF on the Cisco side you should > be fine. That's what I thought of at first, but then realized the op said the PVC was up and there was point-to-point connectivity between the Cisco and Juniper over the FR link. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Load balancing: hash algorithm
The specific algorithm differs on different chipsets, and is generally considered to be a "trade secret" of Juniper. This decision was made several years ago when I suggested filing a patent application for one of the chipset's algorithm. Paul Goyette Juniper Networks Customer Service JTAC Senior Escalation Engineer Juniper Security Incident Response Team PGP Key ID 0x53BA7731 Fingerprint: FA29 0E3B 35AF E8AE 6651 0786 F758 55DE 53BA 7731 > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Thursday, July 17, 2008 1:59 AM > To: [EMAIL PROTECTED]; juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] Load balancing: hash algorithm > Importance: High > > > > The hash algorithm uses the source IP address, the > destination IP address, the Protocol field and the Incoming > Interface Index in order to generate a key. > > Thanks David. How is chosen the next-hop with this generate > key? I am looking for this algorithm. > > Regards, > Samuel > > > > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 17 juillet 2008 10:55 > À : Gay,S,Samuel,JPECS R; juniper-nsp@puck.nether.net > Objet : RE: [j-nsp] Load balancing: hash algorithm > > > Hi, > > The hash algorithm uses the source IP address, the > destination IP address, the Protocol field and the Incoming > Interface Index in order to generate a key. > > Regards > David > > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de > [EMAIL PROTECTED] Envoyé : jeudi 17 juillet 2008 10:46 À : > juniper-nsp@puck.nether.net Objet : [j-nsp] Load balancing: > hash algorithm > > Hi Group, > > Do you know how work hash algorithm used in load balancing > (only layer-3)? Is there some documentation about it? > > Thanks, > Samuel > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > > * > This message and any attachments (the "message") are > confidential and intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if > altered, changed or falsified. > If you are not the intended addressee of this message, please > cancel it immediately and inform the sender. > > ___ > 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] PtP link over FR
Let me guess, on Cisco Router A you got an ARP entry for Cisco Router B's address when you put a Cisco router in the middle, as the Cisco router has proxy-arp enabled by default. Or to put it more clearly the IP addresses used FR p2p pvc is a subset of the IP addresses used on the link between Cisco Router A and Juniper Router. Or on Cisco router A you have a static route without a next-hop address to the IP subnet used on the FR link In either case it's a mis configuration, that gets 'saved'/'hidden' by the fact proxy-arp is enabled by default on the Cisco router. /Jesper On Thu, Jul 17, 2008 at 04:06:31PM +0500, Farhan Jaffer wrote: > Hi, > > There is an interesting situation, let me discuss the scenario first, > > Cisco Router A (same n/w) Juniper Router -(FR > point-to-point pvc) --- Cisco Router B. > > PVC is Active & point to point connectivity is OK. But the ping > response from cisco router A to B via FR is unreachable & vice versa. > > however if i replace Juniper router with Cisco Router, it works fine. > > Is there any IP forwarding like thing? or any other problem. > > Thanks very much in advance. > > -FJ > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] PtP link over FR
On your Cisco router, when you look at "show frame map" what do you see as the encapsulation? Is it CISCO or IETF? Juniper routers (like most other vendors) does not do CISCO frame encapsulation, so if you change to IETF on the Cisco side you should be fine. Note, this is different than Cisco LMI, which Juniper does support. HTH, Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Farhan Jaffer Sent: Thursday, July 17, 2008 7:07 AM To: Juniper Puck; [EMAIL PROTECTED] Subject: [j-nsp] PtP link over FR Hi, There is an interesting situation, let me discuss the scenario first, Cisco Router A (same n/w) Juniper Router -(FR point-to-point pvc) --- Cisco Router B. PVC is Active & point to point connectivity is OK. But the ping response from cisco router A to B via FR is unreachable & vice versa. however if i replace Juniper router with Cisco Router, it works fine. Is there any IP forwarding like thing? or any other problem. Thanks very much in advance. -FJ ___ 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] PtP link over FR
Hi, There is an interesting situation, let me discuss the scenario first, Cisco Router A (same n/w) Juniper Router -(FR point-to-point pvc) --- Cisco Router B. PVC is Active & point to point connectivity is OK. But the ping response from cisco router A to B via FR is unreachable & vice versa. however if i replace Juniper router with Cisco Router, it works fine. Is there any IP forwarding like thing? or any other problem. Thanks very much in advance. -FJ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Vpn with rsa
I don't understand how to assign remote settings shrewsoft only has xauth not auth as an option.i have tried it from trust to untrust with authentication applied on the policy for a specific user And when he requested internet service he got a prompt to enter username and password I entered the username I have configured in the RSA server and the token code as password and worked. The problem is on the vpn authentication that Im confused on the way the authentication occurs.(Do I have to configure a locally user? If I don't how will he receive ip address?) I even put it in the policy of the vpn "Untrust to Trust" "authentication" the rsa server and got nothing. I would really appreciated if you help me out here. -Original Message- From: Stefan Fouant [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 16, 2008 5:38 PM To: sunnyday Cc: Juniper-Nsp; [EMAIL PROTECTED] Subject: Re: [j-nsp] Vpn with rsa Whoops, sorry I forgot to mention that you can use an IKE/XAuth account as well. Yep, if you've got it already set up, you should just be able to forward the authentication requests toward the RSA server as opposed to the local database and you should be good to go. As I mentioned before however, the SecurID cannot assign remote settings to an L2TP or an XAuth user, so if you intend on assigning any remote settings, you are probably better off using an Auth user for this purpose. Good luck! On Wed, Jul 16, 2008 at 10:21 AM, sunnyday <[EMAIL PROTECTED]> wrote: > I have an working ipsec vpn with xauth.i use the shrew soft vpn client. can > I just forward the requests to the RSA authentication manager instead of the > local database? > I tried it but with luck. > > > -Original Message- > From: Stefan Fouant [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 16, 2008 5:17 PM > To: sunnyday > Cc: Juniper-Nsp; [EMAIL PROTECTED] > Subject: Re: [j-nsp] Vpn with rsa > > For dial-up VPN applications, you can configure an Auth or L2TP user > and authenticate them against the SecurID database. I would recommend > configuring an Auth user as the SecurID cannot assign remote settings > to an L2TP user. Once you've configured your Auth user account and > set up authentication against the SecurID server, it's really just a > simple matter of specifying the Auth user in the IKE Phase 1 profile. > > For more information, you are really going to need to dig into the > manuals. The "ScreenOS Concepts and Examples Guide Volume 9: User > Authentiation" should provide you an ample starting point. > > HTHs. > > On Wed, Jul 16, 2008 at 3:52 AM, sunnyday <[EMAIL PROTECTED]> wrote: >> I need to configure (if possible ) a vpn with rsa authentication.i have > some >> tokens which generate the tokens codes and have setup the securID server. >> >> I already have a IPSEC vpn. I need to know what steps to take to use rsa >> tokens to authenticate when requesting access to the vpn. >> >> Any help appreciated. >> >> Thank you >> >> ___ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > > > > -- > Stefan Fouant > Principal Network Engineer > NeuStar, Inc. - http://www.neustar.biz > GPG Key ID: 0xB5E3803D > > -- Stefan Fouant Principal Network Engineer NeuStar, Inc. - http://www.neustar.biz GPG Key ID: 0xB5E3803D ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Load balancing: hash algorithm
In the Juniper documentation I can read: "By default, or if you specify only the layer-3 statement, the router uses the incoming interface index as well as the following Layer 3 information in the packet header to load balance traffic: - Source IP address - Destination IP address - Protocol" And: "On routing platforms with the Internet Processor II ASIC, when per-packet load balancing is configured, traffic between routers with multiple paths is divided into individual traffic flows (up to a maximum of 16 equal-cost load-balanced paths). Packets for each individual flow are kept on a single interface." With this information I have two question: - Is the key (generate with hash algorithm) always the same if the incoming interface, source IP address, destination IP address and protocol are the same? If yes is it possible to predict the next-hop? - Is there a way to know the next-hop used for an individual flow (if I have an Internet Processor II ASIC)? Samuel -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Envoyé : jeudi 17 juillet 2008 10:55 À : Gay,S,Samuel,JPECS R; juniper-nsp@puck.nether.net Objet : RE: [j-nsp] Load balancing: hash algorithm Hi, The hash algorithm uses the source IP address, the destination IP address, the Protocol field and the Incoming Interface Index in order to generate a key. Regards David -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de [EMAIL PROTECTED] Envoyé : jeudi 17 juillet 2008 10:46 À : juniper-nsp@puck.nether.net Objet : [j-nsp] Load balancing: hash algorithm Hi Group, Do you know how work hash algorithm used in load balancing (only layer-3)? Is there some documentation about it? Thanks, Samuel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp * This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Load balancing: hash algorithm
> The hash algorithm uses the source IP address, the destination IP address, > the Protocol field and the Incoming Interface Index in order to generate a > key. Thanks David. How is chosen the next-hop with this generate key? I am looking for this algorithm. Regards, Samuel -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Envoyé : jeudi 17 juillet 2008 10:55 À : Gay,S,Samuel,JPECS R; juniper-nsp@puck.nether.net Objet : RE: [j-nsp] Load balancing: hash algorithm Hi, The hash algorithm uses the source IP address, the destination IP address, the Protocol field and the Incoming Interface Index in order to generate a key. Regards David -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de [EMAIL PROTECTED] Envoyé : jeudi 17 juillet 2008 10:46 À : juniper-nsp@puck.nether.net Objet : [j-nsp] Load balancing: hash algorithm Hi Group, Do you know how work hash algorithm used in load balancing (only layer-3)? Is there some documentation about it? Thanks, Samuel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp * This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Load balancing: hash algorithm
Hi, The hash algorithm uses the source IP address, the destination IP address, the Protocol field and the Incoming Interface Index in order to generate a key. Regards David -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de [EMAIL PROTECTED] Envoyé : jeudi 17 juillet 2008 10:46 À : juniper-nsp@puck.nether.net Objet : [j-nsp] Load balancing: hash algorithm Hi Group, Do you know how work hash algorithm used in load balancing (only layer-3)? Is there some documentation about it? Thanks, Samuel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp * This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Load balancing: hash algorithm
Hi Group, Do you know how work hash algorithm used in load balancing (only layer-3)? Is there some documentation about it? Thanks, Samuel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
