Re: : L3 VPN Problems

David Carver wrote:

> 
> 
> Having problems create a L3 VPN.
> 
> CE -----fe-------- Juniper PE ----------fe-------------Cisco PE 
> -------fe-------CE
> 
> All the routes seem to be correct in the correcti routing table 
> instance, but I try the following on Juniper and it fails:
> 
> 
> ping vpn-interface fe-0/1/0 10.162.16.12
> PING 10.162.16.12 (10.162.16.12): 56 data bytes
> 
> 
> Turned on debug on the Cisco PE and saw the ping reach it.  But, it is 
> obviously not going back.
> 
> Any suggestions?

may be because you don't specify source ip of your ping and the cisco 
don't have the route of juniper loobpback?

> 
> Thanks,
> David
> 
> _________________________________________________________________

: draft-vasseur-ccamp-te-router-info-00.txt clarification needed.

Hi,
 We have some confusion in understanding the Data
Plane Capability Flags (B-bit & E-bit) from
draft-vasseur-ccamp-te-router-info-00.txt

(a) Does E-bit ON implies B-bit ON always ? (assuming
ON = set and OFF = unset).
(b) E-bit = ON & B-bit = OFF, is it a valid
combination.
(c) Please tell us the E-bit and B-bit status for a
node which is a destination node but does not have
branch capability.

We are also curious to know
(1)The idea behind combing two things (egress status &
transit status) in a single E-bit. rather than making
use of B-bit(branch) and having E-bit just for egress
status.
(2) Why the TE Node Capability Descriptor TLV should
have E-bit & how it should be used in CSPF path
computation.

Thanks
Satya 

: OSPF Retransmission

: vendor mtu differences

: Multiple VRF's

draft-vasseur-ccamp-te-router-info-00.txt clarification needed.

Hi,
 We have some confusion in understanding the Data
Plane Capability Flags (B-bit & E-bit) from
draft-vasseur-ccamp-te-router-info-00.txt

(a) Does E-bit ON implies B-bit ON always ? (assuming
ON = set and OFF = unset).
(b) E-bit = ON & B-bit = OFF, is it a valid
combination.
(c) Please tell us the E-bit and B-bit status for a
node which is a destination node but does not have
branch capability.

We are also curious to know
(1)The idea behind combing two things (egress status &
transit status) in a single E-bit. rather than making
use of B-bit(branch) and having E-bit just for egress
status.
(2) Why the TE Node Capability Descriptor TLV should
have E-bit & how it should be used in CSPF path
computation.

Thanks
Satya 

		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

: CE-CE MTU Problem ...

Hi,

after getting just about all the problems worked out (both MPLS 
connection related and not) and our customer up an running, a new 
problem came up ... while all "regular" connection going through the DSL 
dial up router work fine, the MPLS VPN connection of the customer has 
problems with the MTU (I suspect) - while normal telnet/terminal 
sessions work fine inside their MPLS VPN, ftp transfers don't ... 
problem is I can't get a tcpdump from the FTP site (AS400?), so I can't 
really pinpoint what is happening at the moment ... basic config is: all 
Cisco routers, MTU 1456 on the DSL link (changed down from 1480 
originally used), MTU 1500 on the ethernet on either side of the CE 
routers, minimum MTU 1500 on the backbone w/ an mpls mtu of 1520 w/ ip 
tcp adjust-mss 1416 (which is messed up to 1432 by MPLS)

Any ideas?

Tnx, -gg

RE: : CE-CE MTU Problem ...

Hi,

Try changing the MTU to 1526 on all L2 devices within the network and 

Change the MTU (tag-switching mtu 1526) on all routers.

Regards,

MK

-----Original Message-----
From: Garry Glendown [mailto:garry <at> regio.net] 
Sent: 7/Oct/2004 12:00 AM
To: mpls-ops <at> mplsrc.com
Subject: [MPLS-OPS]: CE-CE MTU Problem ...

Hi,

after getting just about all the problems worked out (both MPLS 
connection related and not) and our customer up an running, a new 
problem came up ... while all "regular" connection going through the DSL 
dial up router work fine, the MPLS VPN connection of the customer has 
problems with the MTU (I suspect) - while normal telnet/terminal 
sessions work fine inside their MPLS VPN, ftp transfers don't ... 
problem is I can't get a tcpdump from the FTP site (AS400?), so I can't 
really pinpoint what is happening at the moment ... basic config is: all 
Cisco routers, MTU 1456 on the DSL link (changed down from 1480 
originally used), MTU 1500 on the ethernet on either side of the CE 
routers, minimum MTU 1500 on the backbone w/ an mpls mtu of 1520 w/ ip 
tcp adjust-mss 1416 (which is messed up to 1432 by MPLS)

Any ideas?

Tnx, -gg

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

Re: : CE-CE MTU Problem ...

Mansoor Khan wrote:
> 
> 
> 
> Hi,
> 
> Try changing the MTU to 1526 on all L2 devices within the network and 

Can`t do, the ethernet ports on my Ciscos don`t allow anything larger 
than 1500 ... (been there before) ...

-gg

Re: : CE-CE MTU Problem ...

Addendum: I put ip tcp adjust-mss 1300 on the customer router - the 
destination CE router shows incoming packets of size 1340 (which is 
correct) - therefore I think I shoudl be able to rule out an actual MTU 
problem ...

The FTP transfer now looks like this - I get the connection, the 
transfer starts with a couple dozen of packets being transfered, then I 
get nothing for a minute or so, upon which the transfer continues for 
another batch of packets, then freezes, etc ... I've known this behavior 
from MTU problems before, but with a packet size of 1340 this shouldn't 
be the cause ...

Could there be another problem involved? Behind the CE router, our 
customer has a Checkpoint FW (IIRC), could it be a reassemble problem?

Any ideas?

Tnx, -garry