Could NAT be an option?
Jean-Christophe Varaillon ------------ ALTEC Telecoms - NOC 14, Patmou, 151 23 Maroussi, Greece Tel: +30 210 6872932 Fax: +30 210 6872904 E-mail: vajc@altectelecoms.gr ICQ: 264-755-242
-----Original Message----- From: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] On Behalf Of Steven.Glogger@swisscom.com Sent: Thursday, March 22, 2007 12:12 AM To: swinog@swinog.ch Subject: [swinog] MPLS VRF source routing (inter-vrf routing)
hi all
i've got some nice cisco bugs / features / whatever.
some prerequisites:
- 2 VRFs: vrf blue and vrf red - both vrfs have a different default route. - a PPP session / user terminating in vrf blue
a specific route (10.0.1.0/29) is routed over static route (e.g. radius avpair) over the ppp session (vrf blue). this route is imported to vrf red by importing rd values and route-map filtering. so the connectivity from the red vrf to the vrf blue is working (one way).
so, the goal (and this is the problem) is traffic souring that specific route should go back to vrf red.
how i thought would be the simplest way to do it: policy routing.
interface virtual-access123 ip policy route-map set-vrf-red ... !
access-list 110 permit 10.0.1.0 0.0.0.7 any
route-map set-vrf-red permit 10 match ip address 110 set vrf red !
would be the nicest way of doing this.
now the but: if you put the policy on the virtual-template / radius profile the session starts flapping (connect/disconnect/connect/disconnect....). so: not usable.
my other approach was:
interconnect vrf blue with vrf red by a vlan / interface. assume on vrf blue: fastethernet0/0 with 11.0.0.1/30 connnected to vrf red with fastethernet0/1 with 11.0.0.2/30.
modifying the route map to:
route-map set-vrf-red permit 10 match ip address 110 set interface fastethernet0/0 set ip next-hop 11.0.0.2 !
this will stop the flapping (disconnect/connect/disconnect...) of the ppp session and the whole routing works as expected.... BUT: somewhen it stops working because of one thousand possible CEF bugs ;-(
i have to put "no ip route-cache cef" on the interconnection interface, then it works. some hours later (as already said) it stops working. when i do again "no ip route-cache cef" on the interface it works some other hours.
i've tried several IOS for the C7200series and the only half-way working version is the 12.4T (or even 12.3T).
so, now the big question to the community:
1) do you see any other working way doing source-routing from one vrf to another vrf? (there's a vrf source routing command, but i think this will really not scale)
2) do you have encountered the same CEF bugs? (i have seen them on 7206, 1841 and 2851 series routers)
how cisco tells me to do it: http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_ guide09186a0080296409.html
i would be glad to get some input from you guys.
greetings
-steven _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Disclaimer The information in this e-mail and any attachments is confidential. It is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, or person responsible for delivering this information to the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorized to, and must not, read, copy, distribute, use or retain this message or any part of it. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
not really ;-) should be routed not somewhere natted...
in reality the 10.0.1.0/29 is a DMZ range which is public.
-steven
-----Original Message----- From: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] On Behalf Of Varaillon Jean Christophe Sent: Thursday, March 22, 2007 8:31 AM To: swinog@swinog.ch Subject: RE: [swinog] MPLS VRF source routing (inter-vrf routing)
Could NAT be an option?
Jean-Christophe Varaillon ------------ ALTEC Telecoms - NOC 14, Patmou, 151 23 Maroussi, Greece Tel: +30 210 6872932 Fax: +30 210 6872904 E-mail: vajc@altectelecoms.gr ICQ: 264-755-242
-----Original Message----- From: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] On Behalf Of Steven.Glogger@swisscom.com Sent: Thursday, March 22, 2007 12:12 AM To: swinog@swinog.ch Subject: [swinog] MPLS VRF source routing (inter-vrf routing)
hi all
i've got some nice cisco bugs / features / whatever.
some prerequisites:
- 2 VRFs: vrf blue and vrf red - both vrfs have a different default route. - a PPP session / user terminating in vrf blue
a specific route (10.0.1.0/29) is routed over static route (e.g. radius avpair) over the ppp session (vrf blue). this route is imported to vrf red by importing rd values and route-map filtering. so the connectivity from the red vrf to the vrf blue is working (one way).
so, the goal (and this is the problem) is traffic souring that specific route should go back to vrf red.
how i thought would be the simplest way to do it: policy routing.
interface virtual-access123 ip policy route-map set-vrf-red ... !
access-list 110 permit 10.0.1.0 0.0.0.7 any
route-map set-vrf-red permit 10 match ip address 110 set vrf red !
would be the nicest way of doing this.
now the but: if you put the policy on the virtual-template / radius profile the session starts flapping (connect/disconnect/connect/disconnect....). so: not usable.
my other approach was:
interconnect vrf blue with vrf red by a vlan / interface. assume on vrf blue: fastethernet0/0 with 11.0.0.1/30 connnected to vrf red with fastethernet0/1 with 11.0.0.2/30.
modifying the route map to:
route-map set-vrf-red permit 10 match ip address 110 set interface fastethernet0/0 set ip next-hop 11.0.0.2 !
this will stop the flapping (disconnect/connect/disconnect...) of the ppp session and the whole routing works as expected.... BUT: somewhen it stops working because of one thousand possible CEF bugs ;-(
i have to put "no ip route-cache cef" on the interconnection interface, then it works. some hours later (as already said) it stops working. when i do again "no ip route-cache cef" on the interface it works some other hours.
i've tried several IOS for the C7200series and the only half-way working version is the 12.4T (or even 12.3T).
so, now the big question to the community:
1) do you see any other working way doing source-routing from one vrf to another vrf? (there's a vrf source routing command, but i think this will really not scale)
2) do you have encountered the same CEF bugs? (i have seen them on 7206, 1841 and 2851 series routers)
how cisco tells me to do it: http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_ guide09186a0080296409.html
i would be glad to get some input from you guys.
greetings
-steven _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Disclaimer The information in this e-mail and any attachments is confidential. It is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, or person responsible for delivering this information to the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorized to, and must not, read, copy, distribute, use or retain this message or any part of it. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
_______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
hi all
after a long time and a lot of discussions with cisco - some update for the community on this topic: it is not possible (according to cisco engineers).
but there is a small 'but': - probably next year there will be a new IOS for the cisco 7200 enabling this feature - it could be that some images for the cisco 7600 are supporting this inter-vrf feature
greetings ,-)
-steven
-----Original Message----- From: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] On Behalf Of Glogger Steven, FX-IT-SME-SNE Sent: Thursday, March 22, 2007 9:20 AM To: swinog@swinog.ch Subject: RE: [swinog] MPLS VRF source routing (inter-vrf routing)
not really ;-) should be routed not somewhere natted...
in reality the 10.0.1.0/29 is a DMZ range which is public.
-steven
-----Original Message----- From: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] On Behalf Of Varaillon Jean Christophe Sent: Thursday, March 22, 2007 8:31 AM To: swinog@swinog.ch Subject: RE: [swinog] MPLS VRF source routing (inter-vrf routing)
Could NAT be an option?
Jean-Christophe Varaillon ------------ ALTEC Telecoms - NOC 14, Patmou, 151 23 Maroussi, Greece Tel: +30 210 6872932 Fax: +30 210 6872904 E-mail: vajc@altectelecoms.gr ICQ: 264-755-242
-----Original Message----- From: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] On Behalf Of Steven.Glogger@swisscom.com Sent: Thursday, March 22, 2007 12:12 AM To: swinog@swinog.ch Subject: [swinog] MPLS VRF source routing (inter-vrf routing)
hi all
i've got some nice cisco bugs / features / whatever.
some prerequisites:
- 2 VRFs: vrf blue and vrf red - both vrfs have a different default route. - a PPP session / user terminating in vrf blue
a specific route (10.0.1.0/29) is routed over static route (e.g. radius avpair) over the ppp session (vrf blue). this route is imported to vrf red by importing rd values and route-map filtering. so the connectivity from the red vrf to the vrf blue is working (one way).
so, the goal (and this is the problem) is traffic souring that specific route should go back to vrf red.
how i thought would be the simplest way to do it: policy routing.
interface virtual-access123 ip policy route-map set-vrf-red ... !
access-list 110 permit 10.0.1.0 0.0.0.7 any
route-map set-vrf-red permit 10 match ip address 110 set vrf red !
would be the nicest way of doing this.
now the but: if you put the policy on the virtual-template / radius profile the session starts flapping (connect/disconnect/connect/disconnect....). so: not usable.
my other approach was:
interconnect vrf blue with vrf red by a vlan / interface. assume on vrf blue: fastethernet0/0 with 11.0.0.1/30 connnected to vrf red with fastethernet0/1 with 11.0.0.2/30.
modifying the route map to:
route-map set-vrf-red permit 10 match ip address 110 set interface fastethernet0/0 set ip next-hop 11.0.0.2 !
this will stop the flapping (disconnect/connect/disconnect...) of the ppp session and the whole routing works as expected.... BUT: somewhen it stops working because of one thousand possible CEF bugs ;-(
i have to put "no ip route-cache cef" on the interconnection interface, then it works. some hours later (as already said) it stops working. when i do again "no ip route-cache cef" on the interface it works some other hours.
i've tried several IOS for the C7200series and the only half-way working version is the 12.4T (or even 12.3T).
so, now the big question to the community:
1) do you see any other working way doing source-routing from one vrf to another vrf? (there's a vrf source routing command, but i think this will really not scale)
2) do you have encountered the same CEF bugs? (i have seen them on 7206, 1841 and 2851 series routers)
how cisco tells me to do it: http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_ guide09186a0080296409.html
i would be glad to get some input from you guys.
greetings
-steven _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Disclaimer The information in this e-mail and any attachments is confidential. It is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, or person responsible for delivering this information to the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorized to, and must not, read, copy, distribute, use or retain this message or any part of it. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
_______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog