Re: [c-nsp] console port
99% of those USB to Serial adaptors are using the same chipset, called Prolific something, it doesn't matter too much which vendor driver you use, it may work anyway. If you want I can send you a generic driver I've got once that I used on a cable that I've got from the office and didn't have any names on it, I've found it by digging into the digital ID on the unrecognized device. Anyway, here's a couple of links you may find useful: http://www.prolific.com.tw/eng/downloads.asp?ID=31 http://support.gateway.com/support/drivers/ddaStep.asp?Tab=All Hope this helps, Ziv -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Muldoon Sent: Friday, September 12, 2008 5:56 PM To: Tom Storey Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] console port On Sep 12, 2008, at 10:46 AM, Tom Storey wrote: My vote for Keyspan aswell, though I have seen some very strange things happen with them. Personally, mine is working flawless, and it gets a good workout... I use a Mac with Minicom, doesnt matter which USB port I have it plugged into, it always works. Tom Same Here, using a Mac With Minicom.. Drivers default to creating /dev/cu.KeySerial1 for the first on you plug-in. (they used to not, so you always had to use the same USB port, or manual adjust symlink, etc...) I cannot speak to how they work on windows though... -Patrick -- Patrick Muldoon Network/Software Engineer INOC (http://www.inoc.net) PGPKEY (http://www.inoc.net/~doon) Key ID: 0x370D752C NOTICE: alloc: /dev/null: filesystem full ___ 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/ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. ___ 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] NPE-G2 Gigabit Ignored Errors
At 02:43 PM 12-09-08 -0400, Rodney Dunn wrote: Rodney, On a related note, we are seeing input overruns on almost all native GigaE ports on the NPE-G1. Example on 12.4(21): GigabitEthernet0/2 is up, line protocol is up Hardware is BCM1250 Internal MAC, address is 0009.446d.ac1a (bia 0009.446d.ac1a) MTU 1500 bytes, BW 100 Kbit, DLY 10 usec, reliability 255/255, txload 23/255, rxload 13/255 Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, link type is force-up, media type is SX output flow-control is unsupported, input flow-control is XON ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 52874000 bits/sec, 13178 packets/sec 30 second output rate 92696000 bits/sec, 14626 packets/sec 13055246077 packets input, 7473426491146 bytes, 0 no buffer Received 48343 broadcasts, 0 runts, 0 giants, 0 throttles 315 input errors, 0 CRC, 0 frame, 315 overrun, 0 ignored 0 watchdog, 2937496 multicast, 0 pause input 0 input packets with dribble condition detected On 12.4(18): GigabitEthernet0/1 is up, line protocol is up Hardware is BCM1250 Internal MAC, address is 0009.449b.2c1b (bia 0009.449b.2c1b) MTU 9000 bytes, BW 100 Kbit, DLY 10 usec, reliability 255/255, txload 29/255, rxload 41/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is RJ45 output flow-control is XON, input flow-control is XON ARP type: ARPA, ARP Timeout 00:04:00 Last input 00:00:01, output 00:00:00, output hang never Last clearing of show interface counters never Input queue: 0/2048/0/3 (size/max/drops/flushes); Total output drops: 139963 Queueing strategy: fifo Output queue: 0/1024 (size/max) 30 second input rate 163604000 bits/sec, 25284 packets/sec 30 second output rate 113775000 bits/sec, 23142 packets/sec 138829558726 packets input, 110625630435301 bytes, 0 no buffer Received 1170089 broadcasts, 0 runts, 0 giants, 0 throttles 42963 input errors, 0 CRC, 0 frame, 42963 overrun, 0 ignored 0 watchdog, 2939379 multicast, 0 pause input 0 input packets with dribble condition detected On 12.4(9)T2: GigabitEthernet0/2 is up, line protocol is up Hardware is BCM1250 Internal MAC, address is 0009.449b.441a (bia 0009.449b.441a) MTU 1500 bytes, BW 45 Kbit, DLY 10 usec, reliability 255/255, txload 21/255, rxload 60/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is RJ45 output flow-control is XON, input flow-control is XON ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters never Input queue: 0/1024/369/79002147 (size/max/drops/flushes); Total output drops: 82 Queueing strategy: fifo Output queue: 0/1024 (size/max) 30 second input rate 105976000 bits/sec, 13665 packets/sec 30 second output rate 38207000 bits/sec, 11394 packets/sec 2996785111 packets input, 3073612701 bytes, 2279 no buffer Received 500907287 broadcasts, 0 runts, 0 giants, 2483 throttles 8348 input errors, 0 CRC, 0 frame, 8348 overrun, 0 ignored 0 watchdog, 497602409 multicast, 0 pause input 0 input packets with dribble condition detected Any ideas why? -Hank On Fri, Sep 12, 2008 at 02:40:04PM -0400, Clayton Zekelman wrote: No luck... didn't fix it. Is it fixed in a subsequent release? Are there any other parameters I can tune? Not really because you can't tune the rx ring depth. Check 'sh controller'. What does 'sh proc cpu sort | excl 0.00' say? Can you post the configuration..I'm curious what your features look like because the more you have the less pps you get through this box..it's all done in software and can't do all features at line rate during a microburst. sh int stat Rodney GigabitEthernet0/1 is up, line protocol is up Hardware is MV64460 Internal MAC, address is 001a.6d30.091b (bia 001a.6d30.091b) Description: to gig-fastiron Ethernet11 MTU 1500 bytes, BW 100 Kbit, DLY 10 usec, reliability 255/255, txload 23/255, rxload 48/255 Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is RJ45 output flow-control is XON, input flow-control is XON ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters 00:10:09 Input queue: 0/4096/533/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 189692000 bits/sec, 30246 packets/sec 30 second output
Re: [c-nsp] NPE-G2 Gigabit Ignored Errors
At 02:16 PM 12-09-08 -0400, Rodney Dunn wrote: I don't suspect that is going to help because the ignores are not increasing that would point to: CSCse05447 Externally found moderate defect: Resolved (R) 7200 ethernet interfaces should not throttle on input queue full drops Most likely you are seeing micro burst that are coming in faster than the CPU can drain the rx ring. Rodney Can't view it: Information contained within bug ID CSCse05447 is only available to Cisco employees. It is our policy to make all externally-facing bugs available in Bug Toolkit so the system administrators have been automatically alerted to the problem. By choosing to save this bug, you may be notified when the decision to make this bug available to you has been made. Note: Some product enhancement requests and documentation error bugs may not be available in Bug Toolkit. -Hank ___ 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] NPE-G2 Gigabit Ignored Errors
On a related note, we are seeing input overruns on almost all native GigaE ports on the NPE-G1. Example on 12.4(21): On the other side, of those NPE-G1 ports, do you see any flow control from them? I've never seen a G1's counters show pause frame that it sends, but even watching them indirectly, they're always several orders of magnitude less than the number of overruns... ___ 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] separation of transit, peerings and this-AS traffic (long)
Greetings! I am thinking about a scenario, which is maybe quite common, but I do not know how to make that work. Say that an AS1 is receiving full BGP table from multiple upstreams, for example AS100 and AS200. AS1 has a customer, say AS2. There is one Ethernet physical connection between border routers of AS1 and AS2. AS2 is paying to AS1 for upstream and receives full BGP feed. AS1 has another customer AS3, paying for upstream also. Besides that AS1 and AS2 has a peering via some IX. AS2 is stub, so it is announcing only prefixes with as-path ^2$. AS1 is announcing ^1$ and ^1 3$ prefixes to its peers in the IX. AS1 preferres paths via IX by local-preferrence. The point is how to make packets traveling from upstreams of AS1 to AS2 not to take path via IX, but via direct Ethernet connection while traffic originating in AS1 and traffic from AS3 traveling trough AS1 take path via IX? I have two ideas: 1) policy based routing, bind some route-map to AS1's upstream-facing interfaces and set ip next-hop or set interface... But it does not scale well of course. 2) put transit neighbors (upstream and customers also) into vrf, for example: ip vrf transit rd 1:100 export map EXPORT_ALL import map IMPORT_ALL ! router bgp 1 network 1.1.1.0 mask 255.255.255.0 neighbor 2.2.2.1 remote-as 2 neighbor 2.2.2.1 route-map SET_IX_LOCPREF in neighbor 2.2.2.1 filter-list 1 ! address-family ipv4 vrf transit neighbor 1.1.0.1 remote-as 100 neighbor 1.1.0.1 route-map SET_TRANSIT_LOCPREF in neighbor 1.1.0.1 description UPSTREAM1 neighbor 1.1.0.2 remote-as 200 neighbor 1.1.0.2 route-map SET_TRANSIT_LOCPREF in neighbor 1.1.0.2 description UPSTREAM2 neighbor 2.2.2.2 remote-as 2 neighbor 2.2.2.2 route-map SET_TRANSIT_LOCPREF in neighbor 2.2.2.2 description CUSTOMER AS2 neighbor 3.3.3.1 remote-as 3 neighbor 3.3.3.1 route-map SET_TRANSIT_LOCPREF in neighbor 3.3.3.1 description CUSTOMER AS3 ! ! route-map SET_IX_LOCPREF permit 10 set local-preference 200 ! route-map SET_TRANSIT_LOCPREF permit 10 set local-preference 100 ! route-map EXPORT_ALL permit 10 ! route-map IMPORT_ALL permit 10 ! I spent few hours in lab experimenting with this configuration. I am using old Cisco 1600, so there is possibility that issues I had could come from some bug in this EoL platform... For reference, I used IOS (tm) 1600 Software (C1600-SY-M), Version 12.2(37) RELEASE SOFTWARE (fc1) for experiments. Problems: 1) routes in vrf transit are learned to into vrf routing table and are announced in both directions from AS100 to AS2 and AS3 and vice-versa, as expected. But routes from vrf transit are not exported into global routing table nor imported from global into vrf. I tried everything (I put some prefix- or access-list to match ip address clause in IMPORT_ALL and EXPORT_ALL maps,...), but nothing appeared in the global table. It should be some misconfiguration over there but I do not see that. Any help would be appreciated. 2) Let's assume that the import and export works, so I have all transit routes in my global table and route 1.1.1.0/24 inside vrf transit (this is a route originated in AS2). Those routes are therefore in fact duplicated... Is there any mechanism or chance to overcome that? Something like default route in global table pointing into transit VRF and triggering one extra routing decission inside VRF? Or is the duplication somehow optimized and it won't be any problem even for full BGP table? (O course I mean full table on real routers... 7200 or 7600.) Is there any best-practice or common approach to that? Maybe something completly different which I am not aware of? Tomas -- Tomáš Hlaváček [EMAIL PROTECTED] ___ 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] Dreaded FIB Exception on Sup2
It's minimal, but RSP720-3CXL is going to require a 7600, though if you are willing to trade the MSFC4 for VSS, you can go with a VS-Sup720-3CXL. Either one is going to force you off of 12.2SXF. Since the difference between 3B and 3C mainly seems to be number of MAC addresses, a Sup720-3BXL will usually do the job well enough. PFC-3BXL is a fine EARL, but MSFC4 has much more memory and processing power, which is something that the years to come might prove useful. Rubens ___ 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] Dreaded FIB Exception on Sup2
On Wed, Sep 3, 2008 at 2:58 PM, Rick Kunkel [EMAIL PROTECTED] wrote: Well, I've hit the dreaded error message on my Sup2: %MLSCEF-SP-7-FIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched 1) Try filtering on anything less than /24s and pointing default routes to your providers, see if that helps. 2) Try filtering on RIR boundaries, if (1) has failed. 3) Try filtering on overlapping prefixes (will need software to find those), if (2) has failed 4) Try filtering on longer AS paths, which means you are likely to be very far off to do useful traffic engineering, if (3) or (2) failed Beware that pointing a defaul-route might do some damage if you use uRPF, but you use uRPF, you would have probably posted this message some years ago... :-) Rubens ___ 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] separation of transit, peerings and this-AS traffic (long)
my apologies, i seem to have read through your original to quickly 2008/9/14 Tomas Hlavacek [EMAIL PROTECTED]: Hello Christian, thanks for reply! Maybe I do not see some obvious solution with MED... The point is, that I need to route traffic from all of my upstreams to my customer AS2 via one path and any other traffic from my AS or from my other customers via another path facing AS2 too. So the problem is not which of two routes with the same prefix and different next-hops should be installed into routing table - that is, what the MED solves, AFAIK. The problem is how to use concurrently on a one single box two routes with the same prefix and different next-hops and select which of routes is to be used based on where the traffic comes from (not src IP address but interface). Tomas Christian Koch wrote: use meds On Sun, Sep 14, 2008 at 5:48 PM, Tomas Hlavacek [EMAIL PROTECTED] wrote: Greetings! I am thinking about a scenario, which is maybe quite common, but I do not know how to make that work. Say that an AS1 is receiving full BGP table from multiple upstreams, for example AS100 and AS200. AS1 has a customer, say AS2. There is one Ethernet physical connection between border routers of AS1 and AS2. AS2 is paying to AS1 for upstream and receives full BGP feed. AS1 has another customer AS3, paying for upstream also. Besides that AS1 and AS2 has a peering via some IX. AS2 is stub, so it is announcing only prefixes with as-path ^2$. AS1 is announcing ^1$ and ^1 3$ prefixes to its peers in the IX. AS1 preferres paths via IX by local-preferrence. The point is how to make packets traveling from upstreams of AS1 to AS2 not to take path via IX, but via direct Ethernet connection while traffic originating in AS1 and traffic from AS3 traveling trough AS1 take path via IX? I have two ideas: 1) policy based routing, bind some route-map to AS1's upstream-facing interfaces and set ip next-hop or set interface... But it does not scale well of course. 2) put transit neighbors (upstream and customers also) into vrf, for example: ip vrf transit rd 1:100 export map EXPORT_ALL import map IMPORT_ALL ! router bgp 1 network 1.1.1.0 mask 255.255.255.0 neighbor 2.2.2.1 remote-as 2 neighbor 2.2.2.1 route-map SET_IX_LOCPREF in neighbor 2.2.2.1 filter-list 1 ! address-family ipv4 vrf transit neighbor 1.1.0.1 remote-as 100 neighbor 1.1.0.1 route-map SET_TRANSIT_LOCPREF in neighbor 1.1.0.1 description UPSTREAM1 neighbor 1.1.0.2 remote-as 200 neighbor 1.1.0.2 route-map SET_TRANSIT_LOCPREF in neighbor 1.1.0.2 description UPSTREAM2 neighbor 2.2.2.2 remote-as 2 neighbor 2.2.2.2 route-map SET_TRANSIT_LOCPREF in neighbor 2.2.2.2 description CUSTOMER AS2 neighbor 3.3.3.1 remote-as 3 neighbor 3.3.3.1 route-map SET_TRANSIT_LOCPREF in neighbor 3.3.3.1 description CUSTOMER AS3 ! ! route-map SET_IX_LOCPREF permit 10 set local-preference 200 ! route-map SET_TRANSIT_LOCPREF permit 10 set local-preference 100 ! route-map EXPORT_ALL permit 10 ! route-map IMPORT_ALL permit 10 ! I spent few hours in lab experimenting with this configuration. I am using old Cisco 1600, so there is possibility that issues I had could come from some bug in this EoL platform... For reference, I used IOS (tm) 1600 Software (C1600-SY-M), Version 12.2(37) RELEASE SOFTWARE (fc1) for experiments. Problems: 1) routes in vrf transit are learned to into vrf routing table and are announced in both directions from AS100 to AS2 and AS3 and vice-versa, as expected. But routes from vrf transit are not exported into global routing table nor imported from global into vrf. I tried everything (I put some prefix- or access-list to match ip address clause in IMPORT_ALL and EXPORT_ALL maps,...), but nothing appeared in the global table. It should be some misconfiguration over there but I do not see that. Any help would be appreciated. 2) Let's assume that the import and export works, so I have all transit routes in my global table and route 1.1.1.0/24 inside vrf transit (this is a route originated in AS2). Those routes are therefore in fact duplicated... Is there any mechanism or chance to overcome that? Something like default route in global table pointing into transit VRF and triggering one extra routing decission inside VRF? Or is the duplication somehow optimized and it won't be any problem even for full BGP table? (O course I mean full table on real routers... 7200 or 7600.) Is there any best-practice or common approach to that? Maybe something completly different which I am not aware of? Tomas -- Tomáš Hlaváček [EMAIL PROTECTED] ___ 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/ -- Tomáš Hlaváček [EMAIL PROTECTED] ___ cisco-nsp mailing list
Re: [c-nsp] Dreaded FIB Exception on Sup2
I got curious last week when I saw this thread. From my (AS 26296) point of view, there aren't a whole lot of routes in the /25 to /29 range, maybe a couple hundred total when I looked at it last week. The /24s were huge, about 142,000. I'm curious how many of those /24s are covered by larger aggregates. Might be a fun experiment figuring out a safe way to filter those. Probably involve AS path length, maybe RIR allocations. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rubens Kuhl Jr. Sent: Sunday, September 14, 2008 8:12 PM To: Rick Kunkel Cc: Cisco-nsp Subject: Re: [c-nsp] Dreaded FIB Exception on Sup2 On Wed, Sep 3, 2008 at 2:58 PM, Rick Kunkel [EMAIL PROTECTED] wrote: Well, I've hit the dreaded error message on my Sup2: %MLSCEF-SP-7-FIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched 1) Try filtering on anything less than /24s and pointing default routes to your providers, see if that helps. 2) Try filtering on RIR boundaries, if (1) has failed. 3) Try filtering on overlapping prefixes (will need software to find those), if (2) has failed 4) Try filtering on longer AS paths, which means you are likely to be very far off to do useful traffic engineering, if (3) or (2) failed Beware that pointing a defaul-route might do some damage if you use uRPF, but you use uRPF, you would have probably posted this message some years ago... :-) Rubens ___ 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] Dreaded FIB Exception on Sup2
I would be interested in the results of such an experiment (I was about to research this this week myself). Church, Charles wrote: I got curious last week when I saw this thread. From my (AS 26296) point of view, there aren't a whole lot of routes in the /25 to /29 range, maybe a couple hundred total when I looked at it last week. The /24s were huge, about 142,000. I'm curious how many of those /24s are covered by larger aggregates. Might be a fun experiment figuring out a safe way to filter those. Probably involve AS path length, maybe RIR allocations. ___ 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] c7604 starter kit - Update!
On Monday 15 September 2008 10:48:41 Mark Tinka wrote: The x in 100x is not the number of slots, but simply the RU size. Not sure what you're getting at. Disregard. Mark. signature.asc Description: This is a digitally signed message part. ___ 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] Dreaded FIB Exception on Sup2
On a 7600, you can use Sup720 or RSP720, but you can't use Sup720-10Gs, which are quite nice... But you can use RSP720-10G, which IMO are even more nice, because they have the MSFC4. -A ___ 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] separation of transit, peerings and this-AS traffic (long)
Hello Christian, thanks for reply! Maybe I do not see some obvious solution with MED... The point is, that I need to route traffic from all of my upstreams to my customer AS2 via one path and any other traffic from my AS or from my other customers via another path facing AS2 too. So the problem is not which of two routes with the same prefix and different next-hops should be installed into routing table - that is, what the MED solves, AFAIK. The problem is how to use concurrently on a one single box two routes with the same prefix and different next-hops and select which of routes is to be used based on where the traffic comes from (not src IP address but interface). Tomas Christian Koch wrote: use meds On Sun, Sep 14, 2008 at 5:48 PM, Tomas Hlavacek [EMAIL PROTECTED] wrote: Greetings! I am thinking about a scenario, which is maybe quite common, but I do not know how to make that work. Say that an AS1 is receiving full BGP table from multiple upstreams, for example AS100 and AS200. AS1 has a customer, say AS2. There is one Ethernet physical connection between border routers of AS1 and AS2. AS2 is paying to AS1 for upstream and receives full BGP feed. AS1 has another customer AS3, paying for upstream also. Besides that AS1 and AS2 has a peering via some IX. AS2 is stub, so it is announcing only prefixes with as-path ^2$. AS1 is announcing ^1$ and ^1 3$ prefixes to its peers in the IX. AS1 preferres paths via IX by local-preferrence. The point is how to make packets traveling from upstreams of AS1 to AS2 not to take path via IX, but via direct Ethernet connection while traffic originating in AS1 and traffic from AS3 traveling trough AS1 take path via IX? I have two ideas: 1) policy based routing, bind some route-map to AS1's upstream-facing interfaces and set ip next-hop or set interface... But it does not scale well of course. 2) put transit neighbors (upstream and customers also) into vrf, for example: ip vrf transit rd 1:100 export map EXPORT_ALL import map IMPORT_ALL ! router bgp 1 network 1.1.1.0 mask 255.255.255.0 neighbor 2.2.2.1 remote-as 2 neighbor 2.2.2.1 route-map SET_IX_LOCPREF in neighbor 2.2.2.1 filter-list 1 ! address-family ipv4 vrf transit neighbor 1.1.0.1 remote-as 100 neighbor 1.1.0.1 route-map SET_TRANSIT_LOCPREF in neighbor 1.1.0.1 description UPSTREAM1 neighbor 1.1.0.2 remote-as 200 neighbor 1.1.0.2 route-map SET_TRANSIT_LOCPREF in neighbor 1.1.0.2 description UPSTREAM2 neighbor 2.2.2.2 remote-as 2 neighbor 2.2.2.2 route-map SET_TRANSIT_LOCPREF in neighbor 2.2.2.2 description CUSTOMER AS2 neighbor 3.3.3.1 remote-as 3 neighbor 3.3.3.1 route-map SET_TRANSIT_LOCPREF in neighbor 3.3.3.1 description CUSTOMER AS3 ! ! route-map SET_IX_LOCPREF permit 10 set local-preference 200 ! route-map SET_TRANSIT_LOCPREF permit 10 set local-preference 100 ! route-map EXPORT_ALL permit 10 ! route-map IMPORT_ALL permit 10 ! I spent few hours in lab experimenting with this configuration. I am using old Cisco 1600, so there is possibility that issues I had could come from some bug in this EoL platform... For reference, I used IOS (tm) 1600 Software (C1600-SY-M), Version 12.2(37) RELEASE SOFTWARE (fc1) for experiments. Problems: 1) routes in vrf transit are learned to into vrf routing table and are announced in both directions from AS100 to AS2 and AS3 and vice-versa, as expected. But routes from vrf transit are not exported into global routing table nor imported from global into vrf. I tried everything (I put some prefix- or access-list to match ip address clause in IMPORT_ALL and EXPORT_ALL maps,...), but nothing appeared in the global table. It should be some misconfiguration over there but I do not see that. Any help would be appreciated. 2) Let's assume that the import and export works, so I have all transit routes in my global table and route 1.1.1.0/24 inside vrf transit (this is a route originated in AS2). Those routes are therefore in fact duplicated... Is there any mechanism or chance to overcome that? Something like default route in global table pointing into transit VRF and triggering one extra routing decission inside VRF? Or is the duplication somehow optimized and it won't be any problem even for full BGP table? (O course I mean full table on real routers... 7200 or 7600.) Is there any best-practice or common approach to that? Maybe something completly different which I am not aware of? Tomas -- Tomáš Hlaváček [EMAIL PROTECTED] ___ 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/ -- Tomáš Hlaváček [EMAIL PROTECTED] ___ 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] c7604 starter kit
On Monday 15 September 2008 04:52:40 Asbjorn Hojmark - Lists wrote: AFAIK, Cisco don't have a 3-slot model of the ASR1000. The x in 100x is not the number of slots, but simply the RU size. Not sure what you're getting at. Mark. signature.asc Description: This is a digitally signed message part. ___ 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] separation of transit, peerings and this-AS traffic (long)
use meds On Sun, Sep 14, 2008 at 5:48 PM, Tomas Hlavacek [EMAIL PROTECTED] wrote: Greetings! I am thinking about a scenario, which is maybe quite common, but I do not know how to make that work. Say that an AS1 is receiving full BGP table from multiple upstreams, for example AS100 and AS200. AS1 has a customer, say AS2. There is one Ethernet physical connection between border routers of AS1 and AS2. AS2 is paying to AS1 for upstream and receives full BGP feed. AS1 has another customer AS3, paying for upstream also. Besides that AS1 and AS2 has a peering via some IX. AS2 is stub, so it is announcing only prefixes with as-path ^2$. AS1 is announcing ^1$ and ^1 3$ prefixes to its peers in the IX. AS1 preferres paths via IX by local-preferrence. The point is how to make packets traveling from upstreams of AS1 to AS2 not to take path via IX, but via direct Ethernet connection while traffic originating in AS1 and traffic from AS3 traveling trough AS1 take path via IX? I have two ideas: 1) policy based routing, bind some route-map to AS1's upstream-facing interfaces and set ip next-hop or set interface... But it does not scale well of course. 2) put transit neighbors (upstream and customers also) into vrf, for example: ip vrf transit rd 1:100 export map EXPORT_ALL import map IMPORT_ALL ! router bgp 1 network 1.1.1.0 mask 255.255.255.0 neighbor 2.2.2.1 remote-as 2 neighbor 2.2.2.1 route-map SET_IX_LOCPREF in neighbor 2.2.2.1 filter-list 1 ! address-family ipv4 vrf transit neighbor 1.1.0.1 remote-as 100 neighbor 1.1.0.1 route-map SET_TRANSIT_LOCPREF in neighbor 1.1.0.1 description UPSTREAM1 neighbor 1.1.0.2 remote-as 200 neighbor 1.1.0.2 route-map SET_TRANSIT_LOCPREF in neighbor 1.1.0.2 description UPSTREAM2 neighbor 2.2.2.2 remote-as 2 neighbor 2.2.2.2 route-map SET_TRANSIT_LOCPREF in neighbor 2.2.2.2 description CUSTOMER AS2 neighbor 3.3.3.1 remote-as 3 neighbor 3.3.3.1 route-map SET_TRANSIT_LOCPREF in neighbor 3.3.3.1 description CUSTOMER AS3 ! ! route-map SET_IX_LOCPREF permit 10 set local-preference 200 ! route-map SET_TRANSIT_LOCPREF permit 10 set local-preference 100 ! route-map EXPORT_ALL permit 10 ! route-map IMPORT_ALL permit 10 ! I spent few hours in lab experimenting with this configuration. I am using old Cisco 1600, so there is possibility that issues I had could come from some bug in this EoL platform... For reference, I used IOS (tm) 1600 Software (C1600-SY-M), Version 12.2(37) RELEASE SOFTWARE (fc1) for experiments. Problems: 1) routes in vrf transit are learned to into vrf routing table and are announced in both directions from AS100 to AS2 and AS3 and vice-versa, as expected. But routes from vrf transit are not exported into global routing table nor imported from global into vrf. I tried everything (I put some prefix- or access-list to match ip address clause in IMPORT_ALL and EXPORT_ALL maps,...), but nothing appeared in the global table. It should be some misconfiguration over there but I do not see that. Any help would be appreciated. 2) Let's assume that the import and export works, so I have all transit routes in my global table and route 1.1.1.0/24 inside vrf transit (this is a route originated in AS2). Those routes are therefore in fact duplicated... Is there any mechanism or chance to overcome that? Something like default route in global table pointing into transit VRF and triggering one extra routing decission inside VRF? Or is the duplication somehow optimized and it won't be any problem even for full BGP table? (O course I mean full table on real routers... 7200 or 7600.) Is there any best-practice or common approach to that? Maybe something completly different which I am not aware of? Tomas -- Tomáš Hlaváček [EMAIL PROTECTED] ___ 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] separation of transit, peerings and this-AS traffic (long)
MED isn't going to solve this problem. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Koch Sent: Monday, 15 September 2008 9:01 AM To: Tomas Hlavacek Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] separation of transit, peerings and this-AS traffic (long) use meds On Sun, Sep 14, 2008 at 5:48 PM, Tomas Hlavacek [EMAIL PROTECTED] wrote: Greetings! I am thinking about a scenario, which is maybe quite common, but I do not know how to make that work. Say that an AS1 is receiving full BGP table from multiple upstreams, for example AS100 and AS200. AS1 has a customer, say AS2. There is one Ethernet physical connection between border routers of AS1 and AS2. AS2 is paying to AS1 for upstream and receives full BGP feed. AS1 has another customer AS3, paying for upstream also. Besides that AS1 and AS2 has a peering via some IX. AS2 is stub, so it is announcing only prefixes with as-path ^2$. AS1 is announcing ^1$ and ^1 3$ prefixes to its peers in the IX. AS1 preferres paths via IX by local-preferrence. The point is how to make packets traveling from upstreams of AS1 to AS2 not to take path via IX, but via direct Ethernet connection while traffic originating in AS1 and traffic from AS3 traveling trough AS1 take path via IX? I have two ideas: 1) policy based routing, bind some route-map to AS1's upstream-facing interfaces and set ip next-hop or set interface... But it does not scale well of course. 2) put transit neighbors (upstream and customers also) into vrf, for example: ip vrf transit rd 1:100 export map EXPORT_ALL import map IMPORT_ALL ! router bgp 1 network 1.1.1.0 mask 255.255.255.0 neighbor 2.2.2.1 remote-as 2 neighbor 2.2.2.1 route-map SET_IX_LOCPREF in neighbor 2.2.2.1 filter-list 1 ! address-family ipv4 vrf transit neighbor 1.1.0.1 remote-as 100 neighbor 1.1.0.1 route-map SET_TRANSIT_LOCPREF in neighbor 1.1.0.1 description UPSTREAM1 neighbor 1.1.0.2 remote-as 200 neighbor 1.1.0.2 route-map SET_TRANSIT_LOCPREF in neighbor 1.1.0.2 description UPSTREAM2 neighbor 2.2.2.2 remote-as 2 neighbor 2.2.2.2 route-map SET_TRANSIT_LOCPREF in neighbor 2.2.2.2 description CUSTOMER AS2 neighbor 3.3.3.1 remote-as 3 neighbor 3.3.3.1 route-map SET_TRANSIT_LOCPREF in neighbor 3.3.3.1 description CUSTOMER AS3 ! ! route-map SET_IX_LOCPREF permit 10 set local-preference 200 ! route-map SET_TRANSIT_LOCPREF permit 10 set local-preference 100 ! route-map EXPORT_ALL permit 10 ! route-map IMPORT_ALL permit 10 ! I spent few hours in lab experimenting with this configuration. I am using old Cisco 1600, so there is possibility that issues I had could come from some bug in this EoL platform... For reference, I used IOS (tm) 1600 Software (C1600-SY-M), Version 12.2(37) RELEASE SOFTWARE (fc1) for experiments. Problems: 1) routes in vrf transit are learned to into vrf routing table and are announced in both directions from AS100 to AS2 and AS3 and vice-versa, as expected. But routes from vrf transit are not exported into global routing table nor imported from global into vrf. I tried everything (I put some prefix- or access-list to match ip address clause in IMPORT_ALL and EXPORT_ALL maps,...), but nothing appeared in the global table. It should be some misconfiguration over there but I do not see that. Any help would be appreciated. 2) Let's assume that the import and export works, so I have all transit routes in my global table and route 1.1.1.0/24 inside vrf transit (this is a route originated in AS2). Those routes are therefore in fact duplicated... Is there any mechanism or chance to overcome that? Something like default route in global table pointing into transit VRF and triggering one extra routing decission inside VRF? Or is the duplication somehow optimized and it won't be any problem even for full BGP table? (O course I mean full table on real routers... 7200 or 7600.) Is there any best-practice or common approach to that? Maybe something completly different which I am not aware of? Tomas -- Tomáš Hlaváček [EMAIL PROTECTED] ___ 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] separation of transit, peerings and this-AS traffic (long)
Hello Ben and all, thanks for reply. First thing is that I am only trying to set up a proof-of-concept using small old boxes which are not doing MPLS at all. In my lab scenario one box stays for one AS. When it comes to deployment of the solution - whatever it is - to my real network, it will be all done by a single 7600, which has connected upstreams, peerings and customers into one single box. In real life my network will stay for AS2. As I am new to MPLS (I only did several labs and read theory) I could be wrong, but I think that sice I have only one box involved, I have only one RIB and so I can not use your solution now. And yes, you are right. I don't like solution with policy based routing despite that I know how to achive what I need using PBR. But I am scared by eventual future expanding of PBR for more customers and more sites. Tomas Ben Steele wrote: Is your network MPLS enabled? You could do TE from your bdr of YOUR upstreams to your PE that connects to AS1 and set a bgp weight (not local pref) on that router to prefer the directly connected Ethernet bgp peer, this solution will also give you some redundancy in should the TE tunnel go down or the bgp relationship over the ethernet it will just take the natural path of the IX. More static options like policy route-maps and static routing next hops etc have the consequence of leaving your neighbour with a broken network in the event of a failure through that policy, sure you can add sla tracking to your next hop but you mentioned scalability etc. So you don't want to be configuring ip sla all over the place and route-maps. Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tomas Hlavacek Sent: Monday, 15 September 2008 7:19 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] separation of transit, peerings and this-AS traffic (long) Greetings! I am thinking about a scenario, which is maybe quite common, but I do not know how to make that work. Say that an AS1 is receiving full BGP table from multiple upstreams, for example AS100 and AS200. AS1 has a customer, say AS2. There is one Ethernet physical connection between border routers of AS1 and AS2. AS2 is paying to AS1 for upstream and receives full BGP feed. AS1 has another customer AS3, paying for upstream also. Besides that AS1 and AS2 has a peering via some IX. AS2 is stub, so it is announcing only prefixes with as-path ^2$. AS1 is announcing ^1$ and ^1 3$ prefixes to its peers in the IX. AS1 preferres paths via IX by local-preferrence. The point is how to make packets traveling from upstreams of AS1 to AS2 not to take path via IX, but via direct Ethernet connection while traffic originating in AS1 and traffic from AS3 traveling trough AS1 take path via IX? I have two ideas: 1) policy based routing, bind some route-map to AS1's upstream-facing interfaces and set ip next-hop or set interface... But it does not scale well of course. 2) put transit neighbors (upstream and customers also) into vrf, for example: ip vrf transit rd 1:100 export map EXPORT_ALL import map IMPORT_ALL ! router bgp 1 network 1.1.1.0 mask 255.255.255.0 neighbor 2.2.2.1 remote-as 2 neighbor 2.2.2.1 route-map SET_IX_LOCPREF in neighbor 2.2.2.1 filter-list 1 ! address-family ipv4 vrf transit neighbor 1.1.0.1 remote-as 100 neighbor 1.1.0.1 route-map SET_TRANSIT_LOCPREF in neighbor 1.1.0.1 description UPSTREAM1 neighbor 1.1.0.2 remote-as 200 neighbor 1.1.0.2 route-map SET_TRANSIT_LOCPREF in neighbor 1.1.0.2 description UPSTREAM2 neighbor 2.2.2.2 remote-as 2 neighbor 2.2.2.2 route-map SET_TRANSIT_LOCPREF in neighbor 2.2.2.2 description CUSTOMER AS2 neighbor 3.3.3.1 remote-as 3 neighbor 3.3.3.1 route-map SET_TRANSIT_LOCPREF in neighbor 3.3.3.1 description CUSTOMER AS3 ! ! route-map SET_IX_LOCPREF permit 10 set local-preference 200 ! route-map SET_TRANSIT_LOCPREF permit 10 set local-preference 100 ! route-map EXPORT_ALL permit 10 ! route-map IMPORT_ALL permit 10 ! I spent few hours in lab experimenting with this configuration. I am using old Cisco 1600, so there is possibility that issues I had could come from some bug in this EoL platform... For reference, I used IOS (tm) 1600 Software (C1600-SY-M), Version 12.2(37) RELEASE SOFTWARE (fc1) for experiments. Problems: 1) routes in vrf transit are learned to into vrf routing table and are announced in both directions from AS100 to AS2 and AS3 and vice-versa, as expected. But routes from vrf transit are not exported into global routing table nor imported from global into vrf. I tried everything (I put some prefix- or access-list to match ip address clause in IMPORT_ALL and EXPORT_ALL maps,...), but nothing appeared in the global table. It should be some misconfiguration over there but I do not see that. Any help would be appreciated. 2) Let's assume that the import and export works, so I have all transit routes in my global table and
Re: [c-nsp] separation of transit, peerings and this-AS traffic (long)
Dean Rasheed [EMAIL PROTECTED] writes: foo.char and foo.varchar have similarly unexpected behavior; I think that's probably the end of it, though, since those are the only types that CoerceViaIO will take as targets. ... and also any user defined domains based on those, which is what I actually had. Ouch. That makes the scope for unexpected behavior wider than I thought. Maybe we do need some restriction here? The ideas I had involved not considering the cast interpretation when the actual syntax is table.column and some-set-of-other-conditions. While this is certainly possible to implement, any variant of it will break the existing 100% equivalence of foo.bar and bar(foo); which seems to me to be a nice principle, though I grant you won't find it anywhere in the SQL standard. The other-conditions are a bit up for grabs. The narrowest restriction that would serve the purpose is table variable is of composite type and the cast would be a CoerceViaIO cast, but that definitely seems like a wart. However, cleaner-seeming restrictions like no casts on composites at all could potentially break applications that worked okay before 8.3. Comments anyone? Should we try to change this, or leave well enough alone? regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [c-nsp] c7604 starter kit
Just out of curiosity what were main points that left you wanting? QinQ termination, EoMPLS, VPLS. -A ___ 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] c7604 starter kit
AFAIK, Cisco don't have a 3-slot model of the ASR1000. The x in 100x is not the number of slots, but simply the RU size. -A ___ 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/
