[c-nsp] [Slightly OT]: Silly Question
Sorry for the slightly OT question, but my google-fu can't seem to find a definitive answer for this. We recently replaced our Checkpoint firewall with a Fortigate FW and our business requirements have grown for the FW. We need to setup an virtual domain with a new network to meet the new requirements, and I want to create this using the existing external interface and add a .1q tagged vlan for the virtual domain. According to the Fortigate documentation, there should be no problem configuring this on the firewall. The firewall is directly connected to a Cisco 3845 using the built in gig 0/0 port. If it is possible, I would like to leave the existing subnet as untagged so we don't need to interrupt traffic to the firewall. I would like to add the second subnet on a dot1q tagged sub interface. If memory serves me correctly, the configuration below should accomplish this but it has been quite a while since the last time I worked with a Cisco router. interface gigabitEthernet 0/0 ip address 10.1.10.1 255.255.255.0 ! interface gigabitEthernet 0/0.20 encapsulation dot1q 20 ip address 10.1.20.1 255.255.255.0 ! In the end, it all boils down to a couple questions. Can the internal Gigabit interfaces on the 3845 support VLAN tagging, or would I need the HWIC-1GE-SFP which states it supports vlan trunking in the data sheet? Do routed interfaces on the 3845 offer the ability to support tagged and untagged traffic as configured above? Thank you, Tim Donahue ___ 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] 3/11 (invalid or corrupt AS path)
Joe Provo wrote: > On Mon, Feb 16, 2009 at 06:14:08PM +0100, Grzegorz Janoszka wrote: >> Ozar wrote: >>> I am starting to see random BGP neighbor messages from multiple neighbors >>> on >>> different boxes. >>> >>> %BGP-3-NOTIFICATION: received from neighbor X.X.X.X 3/11 (invalid or >>> corrupt >>> AS path) 516 bytes > [snip] >> No, it is not software error, it is extremly long as-path: > > The message itself, correct. The flapping sessions observed on some > code, the long path is indeed triggering some bug. It is immaterial > if it is the revival of an ld bug or a new one, there are folks > flapping over this (and related) paths. Providers without some level > of sanity filters (really need many-multiples the current diameter of > the net?) should be shamed into limiting their customer's prepends. > According to the NANOG thread on this, it would seem that the bug would be CSCdr54230. Tim ___ 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] multilink frame relay configuration examples
Scott, although not specifically for the 2600 series, try the first link when you search for "site:cisco.com multilink frame relay" on Google. According to the Feature Navigator, Frame Relay Multilink is supported on the 2600s in the 12.2T which is the release the document at the first link that Google returns is using, but you will need the the IP Plus feature set. Tim Donahue Quoting Scott Granados <[EMAIL PROTECTED]>: I've been googling and searching on the cisco site but many of the documents point to broken links. I'm looking for pointers for configuring (if possible) multilink frame relay on a 2600 series. We want to terminate 2 Frame Relay T1's on a single 2600 series if possible. Any pointers would be appreciated. Thank you Scott ___ 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/ -- Tim Donahue This message was sent using IMP, the Internet Messaging Program. ___ 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] Nexus 7000
Quoting Justin Shore <[EMAIL PROTECTED]>: > Tim Stevenson wrote: >> At 10:18 PM 1/28/2008 -0600, mack observed: >>> No mention of MPLS though which gives the CRS-1 a leg up on the >>> backbone routing market. >> >> NO MPLS (though the h/w is capable). No immediate plans for it either. > > This would be a show-stopper for us in our Data Center. We have to have > MPLS support for MPLS VPN. How else are they planning on maintaining > VRF separation between customers across multiple chassis in a hosted > environment? [snip] > Say it with me everyone, MPLS MPLS MPLS. It's silly to build any device > without MPLS support. > I think that you and Cisco are using different definitions of the term 'Data Center'. From my understanding, this product is targeted at the Enterprise Data Center, not for a Service Provider Data Center. I agree that it would be silly to build a device that targets the SP market without MPLS, however, your average 'Enterprise' data center environment does not use MPLS throughout. For a device that targets this market, I think it would be silly for them to waste resources putting a MPLS feature set into a device that would typically never need it. In the Enterprise, MPLS typically exists on the network edge for WAN connections, not throughout the network like a Service Provider would require. -- Tim Donahue This message was sent using IMP, the Internet Messaging Program. ___ 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/
