Re: [c-nsp] Unicast flooding?
While the event is occurring I have verified the ARP and CAM entry. The CAM entry is associated with one of the first two Ethernet interfaces, not the third. I can clear the ARP and CAM entry from the CLI and they are re-learned with the same information, yet the traffic continues to egress the wrong Ethernet port. Ugh. I've set the ARP timeout to 4 minutes so that it's less than the CAM table's default configuration of 5 minutes, but there was no improvement. One more observation -- the errant port is the root of the bridge. Any ideas why the 7609 would be sending traffic out an Ethernet port to a device that the CAM table says is on a different Ethernet port? What module is the traffic coming in via? Which of the modules have DFCs? Have you looked at: http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00807347ab.shtml#dfc ...specifically the 1st item Loss of Dynamic MAC Addresses with Distributed Switching which could possibly be related, though that is a wild guess. How long has this been happening for? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] DS3 over STM1
Hi, On Tue, Jan 12, 2010 at 11:15:10PM +0800, Ian Henderson wrote: The new carrier has provisioned a 45Mbit clear channel service with a DS3 at the remote site, and a channelised STM1 at the head office. I can't seem to find a combination of router/card/mux to make this work. I'd ask the carrier to deliver clear channel DS3 on both ends. After all, that's what you ordered (give us a DS3!), no? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpA4unMe11TN.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] PVLAN and trunks (for redundancy and more bandwidth), any idea?
Hello Sven, If I understood you correctly you can get around these limitations by using the PVLAN feature on the end-user ports only and not on the internal switch-to-switch links. On those links you can use normal trunk ports and spread the PVLAN to your 6509 and terminate it on L3 VLAN int. Access layer example for end-user port somewhere in the deeps of the switched fabric: interface FastEthernet0/1 switchport mode private-vlan host switchport private-vlan host-association 10 100 Access layer trunk port: interface GigabitEthernet0/1 switchport mode trunk On your distribution (6509) you configure: interface Vlan10 ip sticky-arp ignore --- this is important as PVLAN VLAN interface gets sticky arp by default (for some unknown reason) no ip proxy-arp private-vlan mapping 100 and normal trunk port towards the switch fabric: interface GigabitEthernet6/1 switchport mode trunk Yes this is probably suboptimal to what you would like to accoplish however the end effect is that the end-user ports cannot communicate with each other - which is probably what you want. Another alternative is the private-vlan trunk feature which is described over here http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sga/configuration/guide/pvlans.html#wp1166138 - the trouble is that AFAIK currently it works only on C4500. -pavel skovajsa On Wed, Jan 13, 2010 at 7:03 AM, Sven 'Darkman' Michels s...@darkman.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, i'd like to use the pvlan feature from Cisco for two networks. I already read a lot of documentation on the pvlan feature on ciscos page and mayn other blog posts etc. and already know, that it seems not to be possible to use the pvlan feature with etherchannel/port groups on any device. A part from no information *why* this is not possible, i have no idea, how to complete the following setup: I'd like to have my PVLAN connected to my core network in a kind of redundancy and more bandwidth. The PVLAN has GBIT enabled devices, the uplink to the core should be more than one GBIT (to ensure that no single device is able to fill the uplink, but also able to use max of avaiable bandwidth). Sadly, a TGigE Uplink is not yet possble. As switches we have 3560G and the core is currently a 6509. At least the redundancy is important, so i could try it with backup-interface on the 6509, but this would limit the pvlan to 1GigE, which is not exactly what i want. Another problem is, that i currently plan to deploy two isolated pvlans on the 3560 switches, which should be no problem if i use two different primary vlans (a primary may only carry one isolated pvlan at a time), but it seems to be not possible to use one uplink/trunk port for two different isolated pvlan setups? If thats true, i would need at least four ports (two for each isolated pvlan) just to get the redundancy and would not have any uplink 1GigE... Did i miss anything? is there a way to get the redundancy and the bandwidth? may i use two isolated pvlans on the same uplink? Is there some way to use something like etherchannel with pvlans? Or is there a way to change the setup in a way i would get pvlan + more bandwidth + redundancy without all of these problems or limitations? ;) Thanks and regards, Sven -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktNYjQACgkQQoCguWUBzByRRgCgqzWhNR6O/GNSjQZUhjAMw/+z rrAAoK4X2X5ti4MibH7r1dUUCDpf/S05 =3btI -END PGP SIGNATURE- ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Unicast flooding?
Hello Frank, Does not sound really healthy - if you have gathered good evidence this is a good candidate for TAC. Anyway - you should probably upgrade to something other then SRB4 as TAC will tell you probably the same thing -pavel skovajsa On Wed, Jan 13, 2010 at 7:02 AM, Frank Bulk frnk...@iname.com wrote: We've been seeing some strange behavior on our 7609-S running 12.2(33r)SRB4. We have a VLAN (with four /24s) configured on three ports across two 10/100/1000 blades facing some FTTH transport equipment. Customers hanging off the FTTH equipment on the third port are complaining that several times per day they lose internet access. We've been able to correlate their complaints with failed ping attempts from our workstations and the 7609-S to their public IPs. What's interesting is that it's not all the traffic, and of the 4 IPs we are tracking, two of which are on separate /24s, the outages happen within the same /24. At the same time, while using Wireshark, I can see one of the Cisco interfaces sending out 1 to 2 Mbps of traffic that should be going to one of the other two Ethernet interfaces. This is happening about a dozen times per day for 4 to 6 minutes at a time. While the event is occurring I have verified the ARP and CAM entry. The CAM entry is associated with one of the first two Ethernet interfaces, not the third. I can clear the ARP and CAM entry from the CLI and they are re-learned with the same information, yet the traffic continues to egress the wrong Ethernet port. I've set the ARP timeout to 4 minutes so that it's less than the CAM table's default configuration of 5 minutes, but there was no improvement. One more observation -- the errant port is the root of the bridge. Any ideas why the 7609 would be sending traffic out an Ethernet port to a device that the CAM table says is on a different Ethernet port? Frank interface Vlan10 description FTTH network ip dhcp relay information trusted ip dhcp relay information option-insert none ip dhcp relay information policy-action keep ip address 67.22.a.1 255.255.255.0 secondary ip address 67.22.b.1 255.255.255.0 secondary ip address 67.22.c.1 255.255.255.0 secondary ip address 67.22.d.1 255.255.255.0 ip helper-address e.f.g.h no ip redirects arp timeout 300 end interface GigabitEthernet1/29 (and 3/39 and 3/45) switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 10 switchport mode trunk switchport nonegotiate load-interval 30 spanning-tree portfast trunk end ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Cisco ASA and Update Cisco VPN Client
Hi anyone know if it's possible : When a user connect to my Cisco ASA in VPN IPSec, the ASA see the version of the IPSec Client Software, i thinks. If this software are too old, the asa can sent a update automatiquely ? Thanks Jerome ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco ASA and Update Cisco VPN Client
I just see in my ASA 8.2 under Configuration Remote Access VPN Network (Client) Access IPsec Connection Profiles (Advancede IPSec) an option Client Software Update. I remember see this in older versions too. I never used it, but I think this is you are looking for. On Wed, Jan 13, 2010 at 9:14 AM, Phibee Network Operation Center n...@phibee.net wrote: Hi anyone know if it's possible : When a user connect to my Cisco ASA in VPN IPSec, the ASA see the version of the IPSec Client Software, i thinks. If this software are too old, the asa can sent a update automatiquely ? Thanks Jerome ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASA ipv6 + icmp types
On Tue, 12 Jan 2010, Dale W. Carder wrote: On Jan 11, 2010, at 1:41 PM, Brandon Applegate wrote: So I'm playing around with ipv6 on the ASA. I'm running the latest code (8.2(1)). And in trying to get traceroutes and pings 'through' the ASA, I've found that icmp-types are translated to 'english' but using the ipv4 codes. I.e. code 3 for ipv6 is time-exceeded but shows up in config as unreachable (because unreachable == 3 in ipv4). I'm guessing I should open a TAC case and complain ? You could call it a cosmetic issue, but I see myself making mistakes because the burden is on me to translate the icmp types as I enter config :( I would certainly open a tac case and insist on getting a bug id. Yeah I asked Brandon unicast to open a new case and get me the #. However: The issue comes from the icmp-type object group being a separate entity from an ACL, that is not context-aware (www is always 80), and it can not really be fixed: if you were to use the same icmp-type OG in the IPv4 and IPv6 ACL- what should the type 3 correspond to in the running config within that object group ? There's not always 1:1 mapping between ICMPv4 and ICMPv6. So it is not as black and white as printing IPv4 instead of IPv6, unfortunately... Looks like the only approach might be creating a new object-group kind icmp6-type - and make the CLI not accept the icmp-type object group for the IPv6 ACLs. cheers, andrew ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] IPv6 ns-interval 12.2(33)SRE ASA 8.2(2)
Hi Guys, I'm hoping there is someone out there who knows a bit more about IPv6 that I do :) Enabled ipv6 between the Cisco 7600 running 12.2(33)SRE and a pair of Cisco ASA firewalls running 8.2(2) (in HA). I get the following from the 7600 %IPV6-3-CONFLICT: Router FE80::21A:E2FF:FE68:50AA on Vlan2008 has conflicting ND settings show ipv6 routers show the only real difference is the retransmit time. On the 7600, it is 0ms (which I understand to be unspecified rather than 0) and on the ASA the default is 1000. cr1-sdf2.uk#show ipv6 routers vlan2008 Router FE80::21A:E2FF:FE68:50AA on Vlan2008, last update 0 min, CONFLICT Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500 HomeAgentFlag=0, Preference=Medium Reachable time 0 msec, Retransmit time 1000 msec Prefix 2A02:298:0:4::/112 onlink autoconfig Valid lifetime 2592000, preferred lifetime 604800 colofw1/act# show ipv6 routers Router fe80::21b:dff:fee5:ae00 on outside, last update 0 min Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500 Reachable time 0 msec, Retransmit time 0 msec Prefix 2a02:298:0:4::/112 onlink autoconfig Valid lifetime 2592000, preferred lifetime 604800 Adding the following configuration to the 7600 corrects the issue: ipv6 nd ns-interval 1000 cr1-sdf2.uk(config-if)#do show ipv6 routers vlan2008 Router FE80::21A:E2FF:FE68:50AA on Vlan2008, last update 0 min Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500 HomeAgentFlag=0, Preference=Medium Reachable time 0 msec, Retransmit time 1000 msec Prefix 2A02:298:0:4::/112 onlink autoconfig Valid lifetime 2592000, preferred lifetime 604800 Both ends are now the same and no conflict occurs. Any ideas why it's complaining? I thought that the unspecified nature of ns-interval means that it would accept the 1000 milliseconds from the other end? Thanks Tim Timothy Arnold Senior Engineer, Operations (Network, Security Facilities Group), UKSolutions Telephone: 0845 004 1333, option 2 Email: timothy.arn...@uksolutions.co.uk Web: www.uksolutions.co.ukhttp://www.uksolutions.co.uk/ UKS Ltd, Birmingham Road, Studley, Warwickshire, B80 7BG Registered in England Number 3036806 This email must be read in conjunction with the legal service notices on http://www.uksolutions.co.uk/disclaimer.html ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IPv6 ns-interval 12.2(33)SRE ASA 8.2(2)
Tim, I got the following of from Cisco pertaining to your error message; ExplanationAnother router on the link has sent router advertisements with parameters that conflict with this router. Recommended ActionVerify that all IPv6 routers on the link have the same parameters in the router advertisement for hop-limit, managed-config-flag, other-config-flag, reachable-time and ns-interval. Also verify that preferred and valid lifetimes for the same prefix advertised by several routers are the same. Enter the *show ipv6 interface* command to list the parameters per interface. mike On Wed, Jan 13, 2010 at 7:31 AM, Timothy Arnold timothy.arn...@uksolutions.co.uk wrote: Hi Guys, I'm hoping there is someone out there who knows a bit more about IPv6 that I do :) Enabled ipv6 between the Cisco 7600 running 12.2(33)SRE and a pair of Cisco ASA firewalls running 8.2(2) (in HA). I get the following from the 7600 %IPV6-3-CONFLICT: Router FE80::21A:E2FF:FE68:50AA on Vlan2008 has conflicting ND settings show ipv6 routers show the only real difference is the retransmit time. On the 7600, it is 0ms (which I understand to be unspecified rather than 0) and on the ASA the default is 1000. cr1-sdf2.uk#show http://cr1-sdf2.uk/#show ipv6 routers vlan2008 Router FE80::21A:E2FF:FE68:50AA on Vlan2008, last update 0 min, CONFLICT Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500 HomeAgentFlag=0, Preference=Medium Reachable time 0 msec, Retransmit time 1000 msec Prefix 2A02:298:0:4::/112 onlink autoconfig Valid lifetime 2592000, preferred lifetime 604800 colofw1/act# show ipv6 routers Router fe80::21b:dff:fee5:ae00 on outside, last update 0 min Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500 Reachable time 0 msec, Retransmit time 0 msec Prefix 2a02:298:0:4::/112 onlink autoconfig Valid lifetime 2592000, preferred lifetime 604800 Adding the following configuration to the 7600 corrects the issue: ipv6 nd ns-interval 1000 cr1-sdf2.uk(config-if)#do show ipv6 routers vlan2008 Router FE80::21A:E2FF:FE68:50AA on Vlan2008, last update 0 min Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1500 HomeAgentFlag=0, Preference=Medium Reachable time 0 msec, Retransmit time 1000 msec Prefix 2A02:298:0:4::/112 onlink autoconfig Valid lifetime 2592000, preferred lifetime 604800 Both ends are now the same and no conflict occurs. Any ideas why it's complaining? I thought that the unspecified nature of ns-interval means that it would accept the 1000 milliseconds from the other end? Thanks Tim Timothy Arnold Senior Engineer, Operations (Network, Security Facilities Group), UKSolutions Telephone: 0845 004 1333, option 2 Email: timothy.arn...@uksolutions.co.uk Web: www.uksolutions.co.ukhttp://www.uksolutions.co.uk/ UKS Ltd, Birmingham Road, Studley, Warwickshire, B80 7BG Registered in England Number 3036806 This email must be read in conjunction with the legal service notices on http://www.uksolutions.co.uk/disclaimer.html ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Unicast flooding?
I agree, I have some good evidence. I'm not against upgrading if that will resolve the issue. Frank -Original Message- From: Pavel Skovajsa [mailto:pavel.skova...@gmail.com] Sent: Wednesday, January 13, 2010 3:43 AM To: frnk...@iname.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Unicast flooding? Hello Frank, Does not sound really healthy - if you have gathered good evidence this is a good candidate for TAC. Anyway - you should probably upgrade to something other then SRB4 as TAC will tell you probably the same thing -pavel skovajsa On Wed, Jan 13, 2010 at 7:02 AM, Frank Bulk frnk...@iname.com wrote: We've been seeing some strange behavior on our 7609-S running 12.2(33r)SRB4. We have a VLAN (with four /24s) configured on three ports across two 10/100/1000 blades facing some FTTH transport equipment. Customers hanging off the FTTH equipment on the third port are complaining that several times per day they lose internet access. We've been able to correlate their complaints with failed ping attempts from our workstations and the 7609-S to their public IPs. What's interesting is that it's not all the traffic, and of the 4 IPs we are tracking, two of which are on separate /24s, the outages happen within the same /24. At the same time, while using Wireshark, I can see one of the Cisco interfaces sending out 1 to 2 Mbps of traffic that should be going to one of the other two Ethernet interfaces. This is happening about a dozen times per day for 4 to 6 minutes at a time. While the event is occurring I have verified the ARP and CAM entry. The CAM entry is associated with one of the first two Ethernet interfaces, not the third. I can clear the ARP and CAM entry from the CLI and they are re-learned with the same information, yet the traffic continues to egress the wrong Ethernet port. I've set the ARP timeout to 4 minutes so that it's less than the CAM table's default configuration of 5 minutes, but there was no improvement. One more observation -- the errant port is the root of the bridge. Any ideas why the 7609 would be sending traffic out an Ethernet port to a device that the CAM table says is on a different Ethernet port? Frank interface Vlan10 description FTTH network ip dhcp relay information trusted ip dhcp relay information option-insert none ip dhcp relay information policy-action keep ip address 67.22.a.1 255.255.255.0 secondary ip address 67.22.b.1 255.255.255.0 secondary ip address 67.22.c.1 255.255.255.0 secondary ip address 67.22.d.1 255.255.255.0 ip helper-address e.f.g.h no ip redirects arp timeout 300 end interface GigabitEthernet1/29 (and 3/39 and 3/45) switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 10 switchport mode trunk switchport nonegotiate load-interval 30 spanning-tree portfast trunk end ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Unicast flooding?
Hi Frank, It sounds like you have already done a bit of research. I thought I might pass on this link as future reference, or for anyone else that is interested. http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801d0808.shtml p.s. I know you are not on a 6000, but most of it should apply. Frank Bulk wrote: We've been seeing some strange behavior on our 7609-S running 12.2(33r)SRB4. We have a VLAN (with four /24s) configured on three ports across two 10/100/1000 blades facing some FTTH transport equipment. Customers hanging off the FTTH equipment on the third port are complaining that several times per day they lose internet access. We've been able to correlate their complaints with failed ping attempts from our workstations and the 7609-S to their public IPs. What's interesting is that it's not all the traffic, and of the 4 IPs we are tracking, two of which are on separate /24s, the outages happen within the same /24. At the same time, while using Wireshark, I can see one of the Cisco interfaces sending out 1 to 2 Mbps of traffic that should be going to one of the other two Ethernet interfaces. This is happening about a dozen times per day for 4 to 6 minutes at a time. While the event is occurring I have verified the ARP and CAM entry. The CAM entry is associated with one of the first two Ethernet interfaces, not the third. I can clear the ARP and CAM entry from the CLI and they are re-learned with the same information, yet the traffic continues to egress the wrong Ethernet port. I've set the ARP timeout to 4 minutes so that it's less than the CAM table's default configuration of 5 minutes, but there was no improvement. One more observation -- the errant port is the root of the bridge. Any ideas why the 7609 would be sending traffic out an Ethernet port to a device that the CAM table says is on a different Ethernet port? Frank interface Vlan10 description FTTH network ip dhcp relay information trusted ip dhcp relay information option-insert none ip dhcp relay information policy-action keep ip address 67.22.a.1 255.255.255.0 secondary ip address 67.22.b.1 255.255.255.0 secondary ip address 67.22.c.1 255.255.255.0 secondary ip address 67.22.d.1 255.255.255.0 ip helper-address e.f.g.h no ip redirects arp timeout 300 end interface GigabitEthernet1/29 (and 3/39 and 3/45) switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 10 switchport mode trunk switchport nonegotiate load-interval 30 spanning-tree portfast trunk end ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Unicast flooding?
-Original Message- From: Phil Mayers [mailto:p.may...@imperial.ac.uk] Sent: Wednesday, January 13, 2010 3:18 AM To: frnk...@iname.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Unicast flooding? While the event is occurring I have verified the ARP and CAM entry. The CAM entry is associated with one of the first two Ethernet interfaces, not the third. I can clear the ARP and CAM entry from the CLI and they are re-learned with the same information, yet the traffic continues to egress the wrong Ethernet port. Ugh. Agreed. I've set the ARP timeout to 4 minutes so that it's less than the CAM table's default configuration of 5 minutes, but there was no improvement. One more observation -- the errant port is the root of the bridge. Any ideas why the 7609 would be sending traffic out an Ethernet port to a device that the CAM table says is on a different Ethernet port? What module is the traffic coming in via? Which of the modules have DFCs? Have you looked at: http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_not e09186a00807347ab.shtml#dfc ...specifically the 1st item Loss of Dynamic MAC Addresses with Distributed Switching which could possibly be related, though that is a wild guess. Thanks for reminding me about this article. When I do a sh mac-address-table, am I looking at what's on the Supervisor or line card's DFC? When I turn it on, I get this message: Mutual_7609(config)#mac-address-table synchronize % Current activity time is [160] seconds % Recommended aging time for all vlans is at least three times the activity interval The aging time of the CAM? By default it's 300 seconds, so working backwards, I would want a Current activity time of 100 seconds, but that doesn't appear to be an option. So I've now increased the mac address-table aging time for that VLAN to 480 seconds (3 x 160) and the arp timeout also to 480 seconds. How long has this been happening for? We've had the first two interfaces in production for several months. We just turned up this third interface two or three weeks, and started moving customers on there and they started complaining last week, so extrapolating from that I'm pretty confident it's been doing this the whole time. Frank ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Ethernet Network
hi all thanks all for ur response i checked where i can deploy MTU on my network on the Cisco ME-C3750-24TE with IOS c3750me-i5-mz.122-35.SE5.bin it has 4 G interfaces , 2 of them are MPLS enabled there is no command under the interface mode mtu but there is on the FE port switch(config-if)#mpls mtu ? 64-1500 MTU (bytes) override Override mpls mtu maximum of interface mtu on the GE port ar6.HS-AMM-017(config-if)#mpls mtu ? 64-1512 MTU (bytes) override Override mpls mtu maximum of interface mtu on the global mode: switch(config)#system mtu ? 1500-1998 MTU size in bytes jumboSet Jumbo MTU value for GigabitEthernet or TenGigabitEthernet interfaces routing Set the Routing MTU for the system on the cisco ME-C6524GT-8S switch(config)#system jumbomtu ? 1500-9216 Jumbo mtu size in Bytes, default is 9216 From: i...@ioshints.info To: td_mi...@yahoo.com; cisco-nsp@puck.nether.net; dlas...@newedgenetworks.com Date: Wed, 13 Jan 2010 08:36:33 +0100 Subject: Re: [c-nsp] Ethernet Network The MTU on PA-FE (probably) does not include MAC header and definitely does not include CRC trailer. Otherwise the minimum value of 1500 wouldn't make sense. -Original Message- From: Tony [mailto:td_mi...@yahoo.com] Sent: Wednesday, January 13, 2010 8:10 AM To: cisco-nsp@puck.nether.net; DonnLasher Subject: Re: [c-nsp] Ethernet Network --- On Wed, 13/1/10, Lasher, Donn dlas...@newedgenetworks.com wrote: SNIP 1500 bytes max data + 22 max header + 4 CRC trailer + 4 byte 802.1q tag +16 up to 4 labels = 1546? Why not just enable jumbos and set it as high as possible? 1546 = largest MTU the 355x/356x switches, PA-FE, etc, will support, as I recall. PA-FE are limited to 1530. You're correct about 1546 for the switches though. 7204(config)#int fa4/0 7204(config-if)#mtu ? 1500-1530 MTU size in bytes __ See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _ Windows Live: Keep your friends up to date with what you do online. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Unicast flooding?
Frank Bulk - iName.com wrote: Have you looked at: http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_not e09186a00807347ab.shtml#dfc ...specifically the 1st item Loss of Dynamic MAC Addresses with Distributed Switching which could possibly be related, though that is a wild guess. Thanks for reminding me about this article. When I do a sh mac-address-table, am I looking at what's on the Supervisor or line card's DFC? Well, on a 6500 under SXI, it shows me things like: Module 1: * 1740 .0c07.ac00 dynamic Yes160 Po1 * 1740 001e.2a6f.5c37 dynamic Yes220 Po1 * 1740 0015.c706.8c00 dynamic Yes170 Po1 Module 2[FE 1]: * 1740 .0c07.ac00 dynamic Yes 0 Po1 * 1740 0015.c706.8c00 dynamic Yes170 Po1 Module 2[FE 2]: * 1740 0015.c706.8c00 dynamic Yes170 Po1 ...leading me to believe it's querying all the forwarding engines on all the modules but NOT the PFC on the sup (module 5 in our case) - possibly because we've got DFCs in all slots? As the example shows, the module and even FE tables within a module can differ. You can get the raw module local tables (and the PFC one) using: remote command module N sh mac-address-table [dynamic] [vlan N] If the active sup is in slot 5, these are equivalent: remote command module 5 remote command switch ...and on the sup I see, using the above example: Displaying entries from SP: RM PI_E RMA Vlan Destination Address Address Type XTag LTL Index ---++---+--+-+-++- No Yes No 1740 ..0016static 0 0x802 No Yes No 1740 ..0001static 0 0x802 No Yes No 1740 ..000dstatic 0 0x7FF8 No No No 1740 .0c07.ac00dynamic 0 0x340 No Yes No 1740 0015.c70b.9000static 1 0x380 No No No 1740 001e.2a6f.5c37dynamic 0 0x340 No No No 1740 0015.c706.8c00dynamic 0 0x340 ...which looks like an amalgam of the module MAC tables. We're not running mac sync or anything odd. You can remote command [switch|module N] (or attach N) and run sh mac-address-table detail ...but based on the deafening silence in response to a query the other week, no-one knows what those flags mean - maybe you can see a pattern in your problematic entries though (yay I just love reverse engineering the 6500 forwarding architecture - thanks cisco!) When I turn it on, I get this message: Mutual_7609(config)#mac-address-table synchronize % Current activity time is [160] seconds % Recommended aging time for all vlans is at least three times the activity interval The aging time of the CAM? By default it's 300 seconds, so working backwards, I would want a Current activity time of 100 seconds, but that doesn't appear to be an option. So I've now increased the mac address-table aging time for that VLAN to 480 seconds (3 x 160) and the arp timeout also to 480 seconds. Interestingly, at some point when I was testing either SXH or SXI, I recall this very time (480 seconds) magically popped into the nvgen without any input from me. I can't remember when, and it seems to not be there now. I've seen hints that VSS systems use the mac sync / move notify stuff behind the scenes to sync up MAC tables across chassis - of course since you're on a 7600 that should not be relevant. sh mac- sync stat ...might be illuminating now that you've got it running, but I'm afraid the output baffles me... ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] IOS, IOS-XR and RANCID
Hello all, We have a network composed by Cisco equipment running IOS and IOS-XR. We run RANCID to manage/backup our configurations. Is anybody has experience on this software with both versions (IOS and IOS-XR)? We have difficulties to integrate both versions simultaneously in the same RANCID process (problem of user and admin mode execution) Thanks, Simon ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Unicast flooding?
Good news is that with the mac-address-table synchronize command things have been stable for 2 hours, a new record. More below. Frank -Original Message- From: Phil Mayers [mailto:p.may...@imperial.ac.uk] Sent: Wednesday, January 13, 2010 10:19 AM To: frnk...@iname.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Unicast flooding? Frank Bulk - iName.com wrote: Have you looked at: http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_not e09186a00807347ab.shtml#dfc ...specifically the 1st item Loss of Dynamic MAC Addresses with Distributed Switching which could possibly be related, though that is a wild guess. Thanks for reminding me about this article. When I do a sh mac-address-table, am I looking at what's on the Supervisor or line card's DFC? Well, on a 6500 under SXI, it shows me things like: Module 1: * 1740 .0c07.ac00 dynamic Yes160 Po1 * 1740 001e.2a6f.5c37 dynamic Yes220 Po1 * 1740 0015.c706.8c00 dynamic Yes170 Po1 Module 2[FE 1]: * 1740 .0c07.ac00 dynamic Yes 0 Po1 * 1740 0015.c706.8c00 dynamic Yes170 Po1 Module 2[FE 2]: * 1740 0015.c706.8c00 dynamic Yes170 Po1 The output under SRB is a bit different: Mutual_7609#sh mac-address-table Legend: * - primary entry age - seconds since last seen n/a - not available vlan mac address typelearn age ports --+++-+--+-- 280 0007.e96b.06fb dynamic Yes295 Gi1/32 150 0030.d700.1afe dynamic Yes295 Gi3/35 293 001e.e573.ee2e dynamic Yes 5 Gi1/39 293 0023.69c4.d0a7 dynamic Yes295 Gi1/39 572 0021.29d9.2dbb dynamic Yes295 Gi3/47 280 001e.e573.edda dynamic Yes295 Gi1/32 ...leading me to believe it's querying all the forwarding engines on all the modules but NOT the PFC on the sup (module 5 in our case) - possibly because we've got DFCs in all slots? Perhaps. As the example shows, the module and even FE tables within a module can differ. There's times where I've seen nothing for sh mac-address-table, but when I specify a port, I do see it listed (notice that it mentions Line card 3): Mutual_7609#sh mac-address-table int gi3/45 Displaying entries from Line card 3: Legend: * - primary entry age - seconds since last seen n/a - not available vlan mac address typelearn age ports --+++-+--+ * 10 0023.69c4.d0da dynamic Yes 5 Gi3/45 Etc. You can get the raw module local tables (and the PFC one) using: remote command module N sh mac-address-table [dynamic] [vlan N] If the active sup is in slot 5, these are equivalent: remote command module 5 remote command switch ...and on the sup I see, using the above example: Displaying entries from SP: RM PI_E RMA Vlan Destination Address Address Type XTag LTL Index ---++---+--+-+-++-- --- No Yes No 1740 ..0016static 0 0x802 No Yes No 1740 ..0001static 0 0x802 No Yes No 1740 ..000dstatic 0 0x7FF8 No No No 1740 .0c07.ac00dynamic 0 0x340 No Yes No 1740 0015.c70b.9000static 1 0x380 No No No 1740 001e.2a6f.5c37dynamic 0 0x340 No No No 1740 0015.c706.8c00dynamic 0 0x340 ...which looks like an amalgam of the module MAC tables. We're not running mac sync or anything odd. You can remote command [switch|module N] (or attach N) and run sh mac-address-table detail ...but based on the deafening silence in response to a query the other week, no-one knows what those flags mean - maybe you can see a pattern in your problematic entries though (yay I just love reverse engineering the 6500 forwarding architecture - thanks cisco!) Those remote commands work for me here, but as you said, who knows what those flags mean. When I turn it on, I get this message: Mutual_7609(config)#mac-address-table synchronize % Current activity time is [160] seconds % Recommended aging time for all vlans is at least three times the activity interval The aging time of the CAM? By default it's 300 seconds, so working backwards, I would want a Current activity time of 100 seconds, but that doesn't appear to be an option. So I've now increased the mac address-table aging time for that VLAN to 480 seconds (3 x 160) and the arp timeout also to 480 seconds. Interestingly, at some point when I was testing either SXH or SXI, I recall this very time (480 seconds) magically popped into the nvgen without any input
Re: [c-nsp] MPLS TE and PIM
ask yourself this way - 1. are TE tunnels bi-directional? answer is no 2. can a TE tunnel receive traffic? again the answer is no. A TE tunnel is for sending traffic, not for receiving. PIM neighborship hence is established on physical interface, not on the TE interface coz you need bidirectional flow between the neighbors. RPF failures may happen when you receive multicast traffic via physical interface while the routing table has a route via TE interface. Either mpls traffic-eng multicast-intact or static mroutes can be used to solve these RPF issues. Forwarding adj doesnt work with multicast-intact feature. HTH Swap #19804 On Tue, Jan 12, 2010 at 11:38 PM, Ibrahim Abo Zaid ibrahim.aboz...@gmail.com wrote: Hi I have a question about PIM , is PIM messages can flow across MPLS TE Tunnel ? why PIM neighborship can't be established over the tunnel ? thanks --Ibrahim ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] BGP to OSPF redistribution
I'm having a problem trying to figure out a way to get eBGP learned routes (from a layer-3 VPN MPLS WAN provider) into our internal OSPF, so that the routes learned via the provider are preffered over the internally learned OSPF routes. No matter where the BGP--OSPF redistribution point is, if it's the PE or CE, the routes will still show up (by default) as OSPF external, and will never be prefferred. The provider who's path we prefer will only run BGP. We would like to use OSPF everywhere if possible, for several reasons. WAN provider A is a layer-3 VPN MPLS network, and is the prefferred path. WAN provider B is a layer-2 VPN MPLS network over which we run OSPF. Provider B's network is inferior at times and we use it as a backup. The equipment where the eBGP peering relationsips exist is a mix of 7600, 3800, 2800, 1800, 6500, 3750, 3550. We considered GRE over the providers network however we then wind up with 25+ tunnels at each location, and that just grows as each new site is added, not to mention some potential issues regarding throughput with a GRE tunnel in the path. Is there a way to redistribute BGP into OSPF so that the routes can be anything but OSPF external? I have not found a way to do this yet, and was wondering if it's even possible, or if I'm missing something obvious. Any suggestions appreciated. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP to OSPF redistribution
On Jan 13, 2010, at 12:19 PM, null zeroroute wrote: I'm having a problem trying to figure out a way to get eBGP learned routes (from a layer-3 VPN MPLS WAN provider) into our internal OSPF, so that the routes learned via the provider are preffered over the internally learned OSPF routes. Is there a way to redistribute BGP into OSPF so that the routes can be anything but OSPF external? I think you are looking for redistribution. Make sure you have plenty of filters in the way of this, but that's what you are looking for. router ospf xxx redistribute bgp route-map blah ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP to OSPF redistribution
If I understand your question properly, why not just change the administrative distance of the eBGP routes to something less than 110. __ Saxon Jones Email: saxon.jo...@gmail.com 2010/1/13 null zeroroute nullzero.ro...@gmail.com I'm having a problem trying to figure out a way to get eBGP learned routes (from a layer-3 VPN MPLS WAN provider) into our internal OSPF, so that the routes learned via the provider are preffered over the internally learned OSPF routes. No matter where the BGP--OSPF redistribution point is, if it's the PE or CE, the routes will still show up (by default) as OSPF external, and will never be prefferred. The provider who's path we prefer will only run BGP. We would like to use OSPF everywhere if possible, for several reasons. WAN provider A is a layer-3 VPN MPLS network, and is the prefferred path. WAN provider B is a layer-2 VPN MPLS network over which we run OSPF. Provider B's network is inferior at times and we use it as a backup. The equipment where the eBGP peering relationsips exist is a mix of 7600, 3800, 2800, 1800, 6500, 3750, 3550. We considered GRE over the providers network however we then wind up with 25+ tunnels at each location, and that just grows as each new site is added, not to mention some potential issues regarding throughput with a GRE tunnel in the path. Is there a way to redistribute BGP into OSPF so that the routes can be anything but OSPF external? I have not found a way to do this yet, and was wondering if it's even possible, or if I'm missing something obvious. Any suggestions appreciated. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IP/VC 3526 serial port is not showing anything
Yes, as well, different connectors. We were able to enter over IP but we didn't see any configuration related with the serial port console :-P El mar, 12-01-2010 a las 13:11 -0600, Jason Shearer escribió: Have you tried different baud rates? I have found some 35xx MCUs come from the factory set at 115200. Jason -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of luismi Sent: Tuesday, January 12, 2010 10:21 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] IP/VC 3526 serial port is not showing anything Hi all, We take a Cisco IP/VC 3526 from one of our racks. We tried to access to it over the serial port with 9600 8N1 -as the documentation says- and it didn't work. We also have an alarm in the from but we were not able to find the relation with it in the documentation. As far as we read the product is EoL/EoS but it will have support until 2011 or 2012, so what is the natural alternative to replace it? Any comment is welcome, not neccesary should be Cisco. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ *** NOTICE--The attached communication contains privileged and confidential information. If you are not the intended recipient, DO NOT read, copy, or disseminate this communication. Non-intended recipients are hereby placed on notice that any unauthorized disclosure, duplication, distribution, or taking of any action in reliance on the contents of these materials is expressly prohibited. If you have received this communication in error, please delete this information in its entirety and contact the Amedisys Privacy Hotline at 1-866-518-6684. Also, please immediately notify the sender via e-mail that you have received this communication in error. *** ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP to OSPF redistribution
That's what we currently do, however the problem is that we have other routers and firewalls in our network which are only running OSPF, and they need to know about the routes which pass through the eBGP network, Since those routes would become OSPF external, they would only be used if the internal routes went away. On Wed, Jan 13, 2010 at 3:34 PM, Saxon Jones saxon.jo...@gmail.com wrote: If I understand your question properly, why not just change the administrative distance of the eBGP routes to something less than 110. __ Saxon Jones Email: saxon.jo...@gmail.com 2010/1/13 null zeroroute nullzero.ro...@gmail.com I'm having a problem trying to figure out a way to get eBGP learned routes (from a layer-3 VPN MPLS WAN provider) into our internal OSPF, so that the routes learned via the provider are preffered over the internally learned OSPF routes. No matter where the BGP--OSPF redistribution point is, if it's the PE or CE, the routes will still show up (by default) as OSPF external, and will never be prefferred. The provider who's path we prefer will only run BGP. We would like to use OSPF everywhere if possible, for several reasons. WAN provider A is a layer-3 VPN MPLS network, and is the prefferred path. WAN provider B is a layer-2 VPN MPLS network over which we run OSPF. Provider B's network is inferior at times and we use it as a backup. The equipment where the eBGP peering relationsips exist is a mix of 7600, 3800, 2800, 1800, 6500, 3750, 3550. We considered GRE over the providers network however we then wind up with 25+ tunnels at each location, and that just grows as each new site is added, not to mention some potential issues regarding throughput with a GRE tunnel in the path. Is there a way to redistribute BGP into OSPF so that the routes can be anything but OSPF external? I have not found a way to do this yet, and was wondering if it's even possible, or if I'm missing something obvious. Any suggestions appreciated. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP to OSPF redistribution
Actually I re-read your problem. Sham links may be a solution to look at, if you control the right pieces of equipment. You can also mess with the AD of OSPF external routes versus OSPF internal routes but this is probably a Bad Idea(TM) (and my testing of this a few years ago showed it didn't have the desired result). __ Saxon Jones Email: saxon.jo...@gmail.com Telephone: (780) 669-0899 Toll-free: (866) 701-8022 United Kingdom: 0(1315)168664 2010/1/13 Saxon Jones saxon.jo...@gmail.com If I understand your question properly, why not just change the administrative distance of the eBGP routes to something less than 110. __ Saxon Jones Email: saxon.jo...@gmail.com 2010/1/13 null zeroroute nullzero.ro...@gmail.com I'm having a problem trying to figure out a way to get eBGP learned routes (from a layer-3 VPN MPLS WAN provider) into our internal OSPF, so that the routes learned via the provider are preffered over the internally learned OSPF routes. No matter where the BGP--OSPF redistribution point is, if it's the PE or CE, the routes will still show up (by default) as OSPF external, and will never be prefferred. The provider who's path we prefer will only run BGP. We would like to use OSPF everywhere if possible, for several reasons. WAN provider A is a layer-3 VPN MPLS network, and is the prefferred path. WAN provider B is a layer-2 VPN MPLS network over which we run OSPF. Provider B's network is inferior at times and we use it as a backup. The equipment where the eBGP peering relationsips exist is a mix of 7600, 3800, 2800, 1800, 6500, 3750, 3550. We considered GRE over the providers network however we then wind up with 25+ tunnels at each location, and that just grows as each new site is added, not to mention some potential issues regarding throughput with a GRE tunnel in the path. Is there a way to redistribute BGP into OSPF so that the routes can be anything but OSPF external? I have not found a way to do this yet, and was wondering if it's even possible, or if I'm missing something obvious. Any suggestions appreciated. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP to OSPF redistribution
On Wed, 13 Jan 2010, null zeroroute wrote: Is there a way to redistribute BGP into OSPF so that the routes can be anything but OSPF external? Change in what order routing protocols are selected (administrative distance): http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094195.shtml -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP to OSPF redistribution
We only manage the CE devices, not the PE's. I just reviewed the sham-link documentation, and my understanding is that the provider needs to configure sham links between each PE over their backbone. I don't think they'll support this. I'm rather certain that they will only support BGP or standard redistribution. On Wed, Jan 13, 2010 at 3:39 PM, Saxon Jones saxon.jo...@gmail.com wrote: Actually I re-read your problem. Sham links may be a solution to look at, if you control the right pieces of equipment. You can also mess with the AD of OSPF external routes versus OSPF internal routes but this is probably a Bad Idea(TM) (and my testing of this a few years ago showed it didn't have the desired result). __ Saxon Jones Email: saxon.jo...@gmail.com Telephone: (780) 669-0899 Toll-free: (866) 701-8022 United Kingdom: 0(1315)168664 2010/1/13 Saxon Jones saxon.jo...@gmail.com If I understand your question properly, why not just change the administrative distance of the eBGP routes to something less than 110. __ Saxon Jones Email: saxon.jo...@gmail.com 2010/1/13 null zeroroute nullzero.ro...@gmail.com I'm having a problem trying to figure out a way to get eBGP learned routes (from a layer-3 VPN MPLS WAN provider) into our internal OSPF, so that the routes learned via the provider are preffered over the internally learned OSPF routes. No matter where the BGP--OSPF redistribution point is, if it's the PE or CE, the routes will still show up (by default) as OSPF external, and will never be prefferred. The provider who's path we prefer will only run BGP. We would like to use OSPF everywhere if possible, for several reasons. WAN provider A is a layer-3 VPN MPLS network, and is the prefferred path. WAN provider B is a layer-2 VPN MPLS network over which we run OSPF. Provider B's network is inferior at times and we use it as a backup. The equipment where the eBGP peering relationsips exist is a mix of 7600, 3800, 2800, 1800, 6500, 3750, 3550. We considered GRE over the providers network however we then wind up with 25+ tunnels at each location, and that just grows as each new site is added, not to mention some potential issues regarding throughput with a GRE tunnel in the path. Is there a way to redistribute BGP into OSPF so that the routes can be anything but OSPF external? I have not found a way to do this yet, and was wondering if it's even possible, or if I'm missing something obvious. Any suggestions appreciated. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP to OSPF redistribution
you need to use OSPF Sham links. Tht'll make the other-CE's routes route as internal on your local-CE crossing MP-BGP backbone. Swap #19804 On Thu, Jan 14, 2010 at 2:06 AM, null zeroroute nullzero.ro...@gmail.comwrote: I understand redistribution. The problem is that when routes pass through a BGP AS and then get redistributed into OSPF, they show up as OSPF external. I'm looking for a way to make those internal, or prefferred, over the OSPF routes learned via the rest of the network. On Wed, Jan 13, 2010 at 3:31 PM, Cord MacLeod cordmacl...@gmail.com wrote: On Jan 13, 2010, at 12:19 PM, null zeroroute wrote: I'm having a problem trying to figure out a way to get eBGP learned routes (from a layer-3 VPN MPLS WAN provider) into our internal OSPF, so that the routes learned via the provider are preffered over the internally learned OSPF routes. Is there a way to redistribute BGP into OSPF so that the routes can be anything but OSPF external? I think you are looking for redistribution. Make sure you have plenty of filters in the way of this, but that's what you are looking for. router ospf xxx redistribute bgp route-map blah ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP to OSPF redistribution
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ospfshmk. html Using a Sham-Link to Correct OSPF Backdoor Routing Although OSPF PE-CE connections assume that the only path between two client sites is across the MPLS VPN backbone, backdoor paths between VPN sites (shown in grey in Figure 2) may exist. If these sites belong to the same OSPF area, the path over a backdoor link will always be selected because OSPF prefers intraarea paths to interarea paths. (PE routers advertise OSPF routes learned over the VPN backbone as interarea paths.) For this reason, OSPF backdoor links between VPN sites must be taken into account so that routing is performed based on policy. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of null zeroroute Sent: Wednesday, January 13, 2010 2:20 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] BGP to OSPF redistribution I'm having a problem trying to figure out a way to get eBGP learned routes (from a layer-3 VPN MPLS WAN provider) into our internal OSPF, so that the routes learned via the provider are preffered over the internally learned OSPF routes. No matter where the BGP--OSPF redistribution point is, if it's the PE or CE, the routes will still show up (by default) as OSPF external, and will never be prefferred. The provider who's path we prefer will only run BGP. We would like to use OSPF everywhere if possible, for several reasons. WAN provider A is a layer-3 VPN MPLS network, and is the prefferred path. WAN provider B is a layer-2 VPN MPLS network over which we run OSPF. Provider B's network is inferior at times and we use it as a backup. The equipment where the eBGP peering relationsips exist is a mix of 7600, 3800, 2800, 1800, 6500, 3750, 3550. We considered GRE over the providers network however we then wind up with 25+ tunnels at each location, and that just grows as each new site is added, not to mention some potential issues regarding throughput with a GRE tunnel in the path. Is there a way to redistribute BGP into OSPF so that the routes can be anything but OSPF external? I have not found a way to do this yet, and was wondering if it's even possible, or if I'm missing something obvious. Any suggestions appreciated. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP to OSPF redistribution
Can you stop learning routes from 'provider b' and add it back as a default? Then everything should go to the more specific route and if 'provider a' goes down things will then go through 'provider b'? Luck, Buz -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Saxon Jones Sent: Wednesday, January 13, 2010 3:39 PM To: null zeroroute Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] BGP to OSPF redistribution Actually I re-read your problem. Sham links may be a solution to look at, if you control the right pieces of equipment. You can also mess with the AD of OSPF external routes versus OSPF internal routes but this is probably a Bad Idea(TM) (and my testing of this a few years ago showed it didn't have the desired result). __ Saxon Jones Email: saxon.jo...@gmail.com Telephone: (780) 669-0899 Toll-free: (866) 701-8022 United Kingdom: 0(1315)168664 2010/1/13 Saxon Jones saxon.jo...@gmail.com If I understand your question properly, why not just change the administrative distance of the eBGP routes to something less than 110. __ Saxon Jones Email: saxon.jo...@gmail.com 2010/1/13 null zeroroute nullzero.ro...@gmail.com I'm having a problem trying to figure out a way to get eBGP learned routes (from a layer-3 VPN MPLS WAN provider) into our internal OSPF, so that the routes learned via the provider are preffered over the internally learned OSPF routes. No matter where the BGP--OSPF redistribution point is, if it's the PE or CE, the routes will still show up (by default) as OSPF external, and will never be prefferred. The provider who's path we prefer will only run BGP. We would like to use OSPF everywhere if possible, for several reasons. WAN provider A is a layer-3 VPN MPLS network, and is the prefferred path. WAN provider B is a layer-2 VPN MPLS network over which we run OSPF. Provider B's network is inferior at times and we use it as a backup. The equipment where the eBGP peering relationsips exist is a mix of 7600, 3800, 2800, 1800, 6500, 3750, 3550. We considered GRE over the providers network however we then wind up with 25+ tunnels at each location, and that just grows as each new site is added, not to mention some potential issues regarding throughput with a GRE tunnel in the path. Is there a way to redistribute BGP into OSPF so that the routes can be anything but OSPF external? I have not found a way to do this yet, and was wondering if it's even possible, or if I'm missing something obvious. Any suggestions appreciated. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP to OSPF redistribution
We need provider A to carry the default. Provider B is actually a layer-2 VPN MPLS provider, so the OSPF neighbors are our own routers. On Wed, Jan 13, 2010 at 4:19 PM, Harold 'Buz' Dale buz.d...@usg.edu wrote: Can you stop learning routes from 'provider b' and add it back as a default? Then everything should go to the more specific route and if 'provider a' goes down things will then go through 'provider b'? Luck, Buz -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto: cisco-nsp-boun...@puck.nether.net] On Behalf Of Saxon Jones Sent: Wednesday, January 13, 2010 3:39 PM To: null zeroroute Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] BGP to OSPF redistribution Actually I re-read your problem. Sham links may be a solution to look at, if you control the right pieces of equipment. You can also mess with the AD of OSPF external routes versus OSPF internal routes but this is probably a Bad Idea(TM) (and my testing of this a few years ago showed it didn't have the desired result). __ Saxon Jones Email: saxon.jo...@gmail.com Telephone: (780) 669-0899 Toll-free: (866) 701-8022 United Kingdom: 0(1315)168664 2010/1/13 Saxon Jones saxon.jo...@gmail.com If I understand your question properly, why not just change the administrative distance of the eBGP routes to something less than 110. __ Saxon Jones Email: saxon.jo...@gmail.com 2010/1/13 null zeroroute nullzero.ro...@gmail.com I'm having a problem trying to figure out a way to get eBGP learned routes (from a layer-3 VPN MPLS WAN provider) into our internal OSPF, so that the routes learned via the provider are preffered over the internally learned OSPF routes. No matter where the BGP--OSPF redistribution point is, if it's the PE or CE, the routes will still show up (by default) as OSPF external, and will never be prefferred. The provider who's path we prefer will only run BGP. We would like to use OSPF everywhere if possible, for several reasons. WAN provider A is a layer-3 VPN MPLS network, and is the prefferred path. WAN provider B is a layer-2 VPN MPLS network over which we run OSPF. Provider B's network is inferior at times and we use it as a backup. The equipment where the eBGP peering relationsips exist is a mix of 7600, 3800, 2800, 1800, 6500, 3750, 3550. We considered GRE over the providers network however we then wind up with 25+ tunnels at each location, and that just grows as each new site is added, not to mention some potential issues regarding throughput with a GRE tunnel in the path. Is there a way to redistribute BGP into OSPF so that the routes can be anything but OSPF external? I have not found a way to do this yet, and was wondering if it's even possible, or if I'm missing something obvious. Any suggestions appreciated. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP to OSPF redistribution
Very good suggestion, however the provider is not sending the internet routing table, only our own internal network's routes. Or are you suggesting some providers make mistakes and send full internet tables to a private VRF customer? We already had our layer-2 VPN MPLS provider join our network with someone else's, and we learned the hard way why you should never ever ever connect a layer-2 switch to that provider, especically one that doesn't support turning off VTP on an interface. Oh yeah and using VTP passwords doens't hurt either :) On Wed, Jan 13, 2010 at 4:20 PM, Richard A Steenbergen r...@e-gerbil.netwrote: On Wed, Jan 13, 2010 at 12:31:41PM -0800, Cord MacLeod wrote: I think you are looking for redistribution. Make sure you have plenty of filters in the way of this, but that's what you are looking for. router ospf xxx redistribute bgp route-map blah Don't forget to double check your out of band and remote reboot power strips for the day someone types no redistribute bgp route-map blah thinking it will remote the entire line instead of just the route-map, 'cause that router will be going down in flames. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP to OSPF redistribution
I don't think sham link will work in this case either. You are running ebgp with provider A? You are only concerned that your ibgp routes from other sites, right? change the ibgp administrative distance to be lower than 110 might work for you. Schilling On Wed, Jan 13, 2010 at 4:03 PM, null zeroroute nullzero.ro...@gmail.com wrote: We only manage the CE devices, not the PE's. I just reviewed the sham-link documentation, and my understanding is that the provider needs to configure sham links between each PE over their backbone. I don't think they'll support this. I'm rather certain that they will only support BGP or standard redistribution. On Wed, Jan 13, 2010 at 3:39 PM, Saxon Jones saxon.jo...@gmail.com wrote: Actually I re-read your problem. Sham links may be a solution to look at, if you control the right pieces of equipment. You can also mess with the AD of OSPF external routes versus OSPF internal routes but this is probably a Bad Idea(TM) (and my testing of this a few years ago showed it didn't have the desired result). __ Saxon Jones Email: saxon.jo...@gmail.com Telephone: (780) 669-0899 Toll-free: (866) 701-8022 United Kingdom: 0(1315)168664 2010/1/13 Saxon Jones saxon.jo...@gmail.com If I understand your question properly, why not just change the administrative distance of the eBGP routes to something less than 110. __ Saxon Jones Email: saxon.jo...@gmail.com 2010/1/13 null zeroroute nullzero.ro...@gmail.com I'm having a problem trying to figure out a way to get eBGP learned routes (from a layer-3 VPN MPLS WAN provider) into our internal OSPF, so that the routes learned via the provider are preffered over the internally learned OSPF routes. No matter where the BGP--OSPF redistribution point is, if it's the PE or CE, the routes will still show up (by default) as OSPF external, and will never be prefferred. The provider who's path we prefer will only run BGP. We would like to use OSPF everywhere if possible, for several reasons. WAN provider A is a layer-3 VPN MPLS network, and is the prefferred path. WAN provider B is a layer-2 VPN MPLS network over which we run OSPF. Provider B's network is inferior at times and we use it as a backup. The equipment where the eBGP peering relationsips exist is a mix of 7600, 3800, 2800, 1800, 6500, 3750, 3550. We considered GRE over the providers network however we then wind up with 25+ tunnels at each location, and that just grows as each new site is added, not to mention some potential issues regarding throughput with a GRE tunnel in the path. Is there a way to redistribute BGP into OSPF so that the routes can be anything but OSPF external? I have not found a way to do this yet, and was wondering if it's even possible, or if I'm missing something obvious. Any suggestions appreciated. ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP to OSPF redistribution
On Wed, 2010-01-13 at 21:50 +0100, Mikael Abrahamsson wrote: On Wed, 13 Jan 2010, null zeroroute wrote: Is there a way to redistribute BGP into OSPF so that the routes can be anything but OSPF external? Change in what order routing protocols are selected (administrative distance): http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094195.shtml Have you considered converting your current WAN OSPF links to BGP so you can use standard BGP route preference controls to select the best route? If that is not possible, another approach (albeit painful) is to use route summarization/fragmentation so that the BGP routes are longer prefixes than the remote OSPF routes. Good luck and have fun! -- Vincent C. Jones Networking Unlimited, Inc. Phone: +1 201 568-7810 v.jo...@networkingunlimited.com ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP to OSPF redistribution
Thanks for your suggestion. We want to use OSPF because it will scale more easily in our network. For example, if we ran BGP over the layer-2 providers network, we would need (today) 25 neighbors at every site, every time a new site is added new neighbors need to be created everywhere, etc to keep the one hop away design. Route-reflectors got too complicated. It's also very helpful to have firewalls running OSPF when there are multiple egress points to extranet partner locations or the internet etc. On Wed, Jan 13, 2010 at 4:43 PM, Vincent C Jones v.jo...@networkingunlimited.com wrote: On Wed, 2010-01-13 at 21:50 +0100, Mikael Abrahamsson wrote: On Wed, 13 Jan 2010, null zeroroute wrote: Is there a way to redistribute BGP into OSPF so that the routes can be anything but OSPF external? Change in what order routing protocols are selected (administrative distance): http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094195.shtml Have you considered converting your current WAN OSPF links to BGP so you can use standard BGP route preference controls to select the best route? If that is not possible, another approach (albeit painful) is to use route summarization/fragmentation so that the BGP routes are longer prefixes than the remote OSPF routes. Good luck and have fun! -- Vincent C. Jones Networking Unlimited, Inc. Phone: +1 201 568-7810 v.jo...@networkingunlimited.com ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP to OSPF redistribution
So far I like the idea of modifying the AD for ospf external routes under the ospf config, or under the ospf config modify the AD for routes learned only from the CE BGP-OSPF redistribution point router, with an ACL matching specific (or all) routes. That would probably give us quite a bit of control. I recall having mixed experiences with a similar config related to BGP-EIGRP redistribution though, I'll definitely need to lab it up because it seems the metrics are calculated a bit differently based on what type of OSPF route it becomes. I need to brush up on my OSPF. For example: At the bgp-ospf redist border router... router ospf 1 redistribute bgp provider private ASN blah distance ospf external 19 Or... access-list 100 permit whatever prefixes we want to prefer router ospf 1 redistribute bgp provider private ASN blah distance 19 CE router ip 0.0.0.0 100 Thanks to all for your suggestions! ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP to OSPF redistribution
How about running a separate OSPF AS over the WAN and distributing it and your BGP into a core OSPF AS. You could metric the WAN OSPF AS in with different values/tags. Jason -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of null zeroroute Sent: Wednesday, January 13, 2010 3:21 PM To: Harold 'Buz' Dale Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] BGP to OSPF redistribution We need provider A to carry the default. Provider B is actually a layer-2 VPN MPLS provider, so the OSPF neighbors are our own routers. On Wed, Jan 13, 2010 at 4:19 PM, Harold 'Buz' Dale buz.d...@usg.edu wrote: Can you stop learning routes from 'provider b' and add it back as a default? Then everything should go to the more specific route and if 'provider a' goes down things will then go through 'provider b'? Luck, Buz -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto: cisco-nsp-boun...@puck.nether.net] On Behalf Of Saxon Jones Sent: Wednesday, January 13, 2010 3:39 PM To: null zeroroute Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] BGP to OSPF redistribution Actually I re-read your problem. Sham links may be a solution to look at, if you control the right pieces of equipment. You can also mess with the AD of OSPF external routes versus OSPF internal routes but this is probably a Bad Idea(TM) (and my testing of this a few years ago showed it didn't have the desired result). __ Saxon Jones Email: saxon.jo...@gmail.com Telephone: (780) 669-0899 Toll-free: (866) 701-8022 United Kingdom: 0(1315)168664 2010/1/13 Saxon Jones saxon.jo...@gmail.com If I understand your question properly, why not just change the administrative distance of the eBGP routes to something less than 110. __ Saxon Jones Email: saxon.jo...@gmail.com 2010/1/13 null zeroroute nullzero.ro...@gmail.com I'm having a problem trying to figure out a way to get eBGP learned routes (from a layer-3 VPN MPLS WAN provider) into our internal OSPF, so that the routes learned via the provider are preffered over the internally learned OSPF routes. No matter where the BGP--OSPF redistribution point is, if it's the PE or CE, the routes will still show up (by default) as OSPF external, and will never be prefferred. The provider who's path we prefer will only run BGP. We would like to use OSPF everywhere if possible, for several reasons. WAN provider A is a layer-3 VPN MPLS network, and is the prefferred path. WAN provider B is a layer-2 VPN MPLS network over which we run OSPF. Provider B's network is inferior at times and we use it as a backup. The equipment where the eBGP peering relationsips exist is a mix of 7600, 3800, 2800, 1800, 6500, 3750, 3550. We considered GRE over the providers network however we then wind up with 25+ tunnels at each location, and that just grows as each new site is added, not to mention some potential issues regarding throughput with a GRE tunnel in the path. Is there a way to redistribute BGP into OSPF so that the routes can be anything but OSPF external? I have not found a way to do this yet, and was wondering if it's even possible, or if I'm missing something obvious. Any suggestions appreciated. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ *** NOTICE--The attached communication contains privileged and confidential information. If you are not the intended recipient, DO NOT read, copy, or disseminate this communication. Non-intended recipients are hereby placed on notice that any unauthorized disclosure, duplication, distribution, or taking of any action in reliance on the contents of these materials is expressly prohibited. If you have received this communication in error, please delete this information in its entirety and contact the Amedisys Privacy Hotline at 1-866-518-6684. Also, please immediately notify the sender via e-mail that you have received this communication in error. *** ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP to OSPF redistribution
- Original Message From: null zeroroute nullzero.ro...@gmail.com Very good suggestion, however the provider is not sending the internet routing table, only our own internal network's routes. Or are you suggesting some providers make mistakes and send full internet tables to a private VRF customer? We already had our layer-2 VPN MPLS provider join our network with someone else's, and we learned the hard way why you should never ever ever connect a layer-2 switch to that provider, especically one that doesn't support turning off VTP on an interface. Oh yeah and using VTP passwords doens't hurt either :) Why not just use site-to-site BGP across the VPLS provider instead of OSPF? A simple prepend will make sure that the AS_PATHs work out right, and then all of the ickiness which is redistribution can be avoided. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP to OSPF redistribution
Well on the BGP-side network, the router/switch that connects the OSPF networks, you could create 2 separate OSPF processes. 1 process for the remote network that will neighbor up across the L2VPN, and the other process for the OSPF network that has BGP redistributing into it (the local network from this devices perspective). On this router/switch, then redistribute the OSPF networks between the two processes (as noted earlier, be sure to prevent loops with route-maps). Now all the OSPF routes are seen as External (not necessarily ideal, but it works), and you can then set the OSPF metric (cost) higher on the neighbor adjacency(s) than taking routes learned from the BGP redistro. You could also do some summarization here too, which would prefer the more specific route from BGP (may or may not be possible with your design). -Mark Date: Wed, 13 Jan 2010 16:52:02 -0500 From: null zeroroute nullzero.ro...@gmail.com To: Vincent C Jones v.jo...@networkingunlimited.com Cc: cisco-nsp@puck.nether.net, Mikael Abrahamsson swm...@swm.pp.se Subject: Re: [c-nsp] BGP to OSPF redistribution Message-ID: bd2721bb1001131352w474e7e8ew222e9182e1f8d...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Thanks for your suggestion. We want to use OSPF because it will scale more easily in our network. For example, if we ran BGP over the layer-2 providers network, we would need (today) 25 neighbors at every site, every time a new site is added new neighbors need to be created everywhere, etc to keep the one hop away design. Route-reflectors got too complicated. It's also very helpful to have firewalls running OSPF when there are multiple egress points to extranet partner locations or the internet etc. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] MPLS TE and PIM
sorry if my question wasn't clear enough i tried it with 2 tunnels between two PEs and enabled sparse-mode under tunnels so in this case , should traffic flows over the tunnel ? thanks swap On Wed, Jan 13, 2010 at 7:21 PM, swap m ccie19...@gmail.com wrote: ask yourself this way - 1. are TE tunnels bi-directional? answer is no 2. can a TE tunnel receive traffic? again the answer is no. A TE tunnel is for sending traffic, not for receiving. PIM neighborship hence is established on physical interface, not on the TE interface coz you need bidirectional flow between the neighbors. RPF failures may happen when you receive multicast traffic via physical interface while the routing table has a route via TE interface. Either mpls traffic-eng multicast-intact or static mroutes can be used to solve these RPF issues. Forwarding adj doesnt work with multicast-intact feature. HTH Swap #19804 On Tue, Jan 12, 2010 at 11:38 PM, Ibrahim Abo Zaid ibrahim.aboz...@gmail.com wrote: Hi I have a question about PIM , is PIM messages can flow across MPLS TE Tunnel ? why PIM neighborship can't be established over the tunnel ? thanks --Ibrahim ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP to OSPF redistribution
Is there a way to redistribute BGP into OSPF so that the routes can be anything but OSPF external? I thought (tho it's been a while and I don't have time to research) that you could use a route-map to match external OSPF routes and set them to internal BGP. I think it would look something like this: route-map bgp-to-ospf permit 10 match route-type external type-1 set metric-type internal asr-egv(config-route-map)#match route-type ? external external route (BGP, EIGRP and OSPF type 1/2) internal internal route (including OSPF intra/inter area) level-1IS-IS level-1 route level-2IS-IS level-2 route local locally generated route nssa-external nssa-external route (OSPF type 1/2) asr-egv(config-route-map)#match route-type external ? type-1 OSPF external type 1 route type-2 OSPF external type 2 route cr asr-egv(config-route-map)#set metric-type internal But I've not tested and memory is failing me on this right now but I swear I did this in a lab once upon a time... Kenny ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
