Re: [mpls-linux-general] MPLS and virtual interfaces

[James R. L. <jl...@mi...>]

Please send the output of 'dmesg', 'ip addr show', 'ip route show',
and 'ip link show' from LER1 after trying to create the NHLFE.

On Wed, Jan 04, 2006 at 01:41:31PM +0100, Alessandro De Rosa wrote:
> James, thanks for your reply. This is the simple scenario I am trying to=
=20
> simulate with NCTUns:
>=20
>=20
> Host1 -----------------LER1 ------------------- LER2 ---------------- Hos=
t2
>   1.0.1.1          1.0.1.2     1.0.3.1        1.0.3.2    1.0.2.2      =20
> 1.0.2.1
>=20
>=20
> Where LER1 should create the MPLS stack and LER2 should remove it. Host1=
=20
> and Host2 respectively send and receive ipv4 packets.  I am trying to=20
> configure LER1 (from its rlogin shell) entering the following instruction=
s:
>=20
> mpls nhlfe add key 0
> ---> key:  0x00000002
> mpls nhlfe change key 0x2 instructions push gen 1000 nexthop eth2 ipv4=20
> 1.0.3.2
> ---> mpls nhlfe change key 0x2 instructions push gen 1000 nexthop tun4 ip=
v4=20
> 1.0.3.2
> ---> RTNETLINK answers: Operation not permitted
>=20
> Eth2 is the outgoing interface of LER1 (ip address 1.0.3.1) which=20
> corresponds to the virtual interface tun4. Exchanging eth2 with tun4 does=
=20
> not eliminate the RTNETLINK error.
> The strange fact is that if I enter any other address which doesn't belon=
g=20
> to my simulated network (i mean an invented address) I do not get the=20
> error. For example:
>=20
> mpls nhlfe change key 0x2 instructions push gen 1000 nexthop eth2 ipv4=20
> 153.153.153.153 (this network doesn't exist)
> ---> mpls nhlfe change key 0x2 instructions push gen 1000 nexthop tun4 ip=
v4=20
> 153.153153.153
> mpls nhlfe show
> ---> NHLFE entry key 0x00000002 mtu 1496 propagate_ttl
> --->                     push gen 1000 set tun4 ipv4 153.153.153.153 (0=
=20
> bytes, 0 pkts, 0 dropped)
>=20
> But obviously MPLS forwarding is then not enabled, since the network=20
> configuration is wrong.
>=20
> The only thing I can think about is the way this simulator addresses=20
> packets: probably the point is not this, but every ip address in NCTUns i=
s=20
> 1.0.x.x and when a sending node 1.0.A.B has to send packets to a=20
> destination node 1.0.C.D, it uses A.B.C.D as destination address. And=20
> although this mechanism should be hidden to the user i can still see=20
> strange A.B.C.D addresses in my routing tables.
> I don't know if these informations can be useful to you, but I am still n=
ot=20
> able to forward any MPLS packet in my simulated network. Can you help me =
in=20
> any way?
> Alessandro De Rosa
>=20

--=20
James R. Leu
jl...@mi...