[c-nsp] Can ASA 5550 do BGP
Matt Thompson
mthompson at brightsolid.com
Thu Feb 14 04:24:49 EST 2013
I was advised at Cisco Live London that BGP is on the roadmap for the ASA platform and should be available in 2013.
Matt
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of cisco-nsp-request at puck.nether.net
Sent: 14 February 2013 04:29
To: cisco-nsp at puck.nether.net
Subject: cisco-nsp Digest, Vol 123, Issue 34
Send cisco-nsp mailing list submissions to
cisco-nsp at puck.nether.net
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-nsp
or, via email, send a message with subject or body 'help' to
cisco-nsp-request at puck.nether.net
You can reach the person managing the list at
cisco-nsp-owner at puck.nether.net
When replying, please edit your Subject line so it is more specific than "Re: Contents of cisco-nsp digest..."
Today's Topics:
1. Re: sup720 ICMP redirects "once per second" (Phil Mayers)
2. Re: Can ASA 5550 do BGP (Phil Mayers)
3. Re: Can ASA 5550 do BGP (Nick Hilliard)
4. Re: ip tcp adjust-mss (Alexander Arseniev)
5. Re: sup720 ICMP redirects "once per second" (Pete Lumbis)
6. Re: ip tcp adjust-mss (Richard Clayton)
7. Re: Cisco 6509 LACP (Denis F)
----------------------------------------------------------------------
Message: 1
Date: Tue, 12 Feb 2013 13:08:51 +0000
From: Phil Mayers <p.mayers at imperial.ac.uk>
To: Pete Lumbis <alumbis at gmail.com>
Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at PUCK.NETHER.NET>
Subject: Re: [c-nsp] sup720 ICMP redirects "once per second"
Message-ID: <511A3EE3.4040401 at imperial.ac.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 12/02/13 13:06, Pete Lumbis wrote:
> From what I could dig up, yes, 1 per second, rate limited on a
> per-interface basis.
>
> From a CEF point of view, when we do the lookup and realize we have
> to do a redirect we punt to process switching. From the 6k perspective
> this would be a specific punt to software that would be matched
> against the MLS rate limiter. At that point the ICMP code looks at the
> input interface and the last time a redirect was generated on that
> interface to determine if a new redirect should be generated.
Cool, that explains the behaviour. Now I just need to get the box rebooted so I can get RP SPAN working again, and maybe I can get back to tracking the actual underlying problem!
Cheers,
Phil
------------------------------
Message: 2
Date: Tue, 12 Feb 2013 09:38:11 +0000
From: Phil Mayers <p.mayers at imperial.ac.uk>
To: cisco-nsp at PUCK.NETHER.NET
Subject: Re: [c-nsp] Can ASA 5550 do BGP
Message-ID: <511A0D83.7080609 at imperial.ac.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 02/11/2013 08:36 PM, Nick Hilliard wrote:
> nope, it doesn't do BGP. Categorically not and last time I asked,
> there were no plans to put it on the roadmap either. BGP is seen as a
> service provider protocol; the ASA is seen as an enterprise product.
I had a discussion with some ASA BU people about BGP on firewalls, and I explained how we used it (routing between L3VPN for enterprise network segmentation). They seemed interested, and didn't categorically rule out the notion of adding BGP, but I wouldn't bet on it...
> As a secondary issue, I would recommend very strongly against the idea
> of using a firewall as a border edge router. It is incredibly easy to
> take out a firewall via a DoS attack, but not at all as easy with a router.
Surely that depends on the router; I keep hearing how crappy the sup720 is now that the new shiny is out, for example ;o)
Joking aside, I agree that having a router on the link generally allows first-line filtering (e.g. iACLs) with more predictable and consistent performance characteristics. Firewalls fall over at the funniest things; they'll happily handle 30k TCP connections/sec but can't handle 1k PPS of UDP dst port 80, or something equally random.
[OT, but that's one reason I like the Catalyst/hardware platforms - slightly more consistent performance characteristics, at the cost of fewer features and awkward config]
------------------------------
Message: 3
Date: Tue, 12 Feb 2013 10:20:35 +0000
From: Nick Hilliard <nick at foobar.org>
To: Juergen Marenda <cnsp at marenda.net>
Cc: pamela pomary <ppomary at ug.edu.gh>, cisco-nsp at PUCK.NETHER.NET
Subject: Re: [c-nsp] Can ASA 5550 do BGP
Message-ID: <511A1773.7090101 at foobar.org>
Content-Type: text/plain; charset=ISO-8859-1
On 11/02/2013 19:36, Juergen Marenda wrote:
> pix and asa did and do not "route" very well.
They both forward packets. The main difference between the two is that a firewall maintains the state of each traffic flow passing through it, while a router does not. Each of these network flows takes up a small amount of resources on the firewall; on an asa5550 you can have up to 600,000 of these sessions.
The problem is that these flow states are easy to generate. Each DNS request will take up a slot. On a 100mbit client link, you can push out about 200k DNS requests per second (each of ~70 bytes), which means that if you have a random punter either inside or outside the firewall with 100Mbit connectivity to the firewall, it will take them about three seconds to knock it offline. Obviously, if you have a GE connection, this drops to less than half a second.
Also the packet rate will kill the box. I don't have any 5550s around, but it's trivial to kill a smaller box stone dead with even a relatively low pps rate.
For a university configuration, the OP really needs to consider a hardware forwarding router which can withstand high packet rates and as you pointed out, filtering should be done with packet filters rather than firewall rules. Otherwise it's downtime and lack of sleep waiting to happen.
Nick
------------------------------
Message: 4
Date: Tue, 12 Feb 2013 16:02:39 +0000
From: Alexander Arseniev <ecralar at hotmail.com>
To: <mack.mcbride at viawest.com>, <moua0100 at umn.edu>,
"cisco-nsp at puck.nether.net" <cisco-nsp at PUCK.NETHER.NET>
Subject: Re: [c-nsp] ip tcp adjust-mss
Message-ID: <DUB119-W3978B0B601AF7A1BCA79FBA5090 at phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"
> From: mack.mcbride at viawest.com
> To: moua0100 at umn.edu; cisco-nsp at puck.nether.net
> Date: Mon, 11 Feb 2013 16:19:35 -0800
> Subject: Re: [c-nsp] ip tcp adjust-mss
>
> Most UDP should not hit the MTU limitation.
> The common ones that come to mind are streaming audio/video and DNS.
>
> LR Mack McBride
> Network Architect
>
Wrt "streaming audio/video" - it depends on client/server combo.I recently saw an issue with RTSP video streaming from repubblica.it website using Samsung Galaxy RSTP client.If UDP video packets are fragmented due to too small MTU in the path, video does not play at all.And DNS is somewhat invalid example since when DNS reply does not fit into 512 bytes, then DNS server will set a Truncated bit in the packet, forcing client to use TCP.http://serverfault.com/questions/348399/force-forwarder-dns-requests-to-tcp-mode No one uses 512B MTU (apart from miltary who use even smaller MTU) and DNS over UDP would not be experiencing issues due to too small MTU because own DNS payload limit is smaller than smallest real MTUs out there (except military as I mentioned).ThanksAlex
------------------------------
Message: 5
Date: Tue, 12 Feb 2013 08:06:16 -0500
From: Pete Lumbis <alumbis at gmail.com>
To: Phil Mayers <p.mayers at imperial.ac.uk>
Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at PUCK.NETHER.NET>
Subject: Re: [c-nsp] sup720 ICMP redirects "once per second"
Message-ID:
<CAB0xJrOeUPfhj7xgq4JizBGMU+7pOvkdsA1N60m2+G532h4iGw at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
>From what I could dig up, yes, 1 per second, rate limited on a
per-interface basis.
>From a CEF point of view, when we do the lookup and realize we have to
>do a
redirect we punt to process switching. From the 6k perspective this would be a specific punt to software that would be matched against the MLS rate limiter. At that point the ICMP code looks at the input interface and the last time a redirect was generated on that interface to determine if a new redirect should be generated.
-Pete
On Tue, Feb 12, 2013 at 4:46 AM, Phil Mayers <p.mayers at imperial.ac.uk>wrote:
> On 02/12/2013 02:34 AM, Pete Lumbis wrote:
>
>> I'm pretty sure this is statically defined within IOS for all
>> redirects on an given interface.
>>
>
> So it's 1 redirect per second per input-interface, not configurable?
>
> If it's an IOS-wide behaviour, that implies it's not platform
> specific, which would make sense, and ties with my original
> understanding of the way redirects are handled on this platform (all
> packets to sup, sup forwards in software).
>
------------------------------
Message: 6
Date: Tue, 12 Feb 2013 13:04:06 +0000
From: Richard Clayton <sledge121 at gmail.com>
To: Eric A Louie <elouie at yahoo.com>
Cc: Cisco NSP <cisco-nsp at PUCK.NETHER.NET>
Subject: Re: [c-nsp] ip tcp adjust-mss
Message-ID:
<CAEjRv+-Tna_NyUCz30aUBTXN_3FMRBZOu=N+26j4Fbay8swZYQ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Eric
I needed to use this command the other day, I have an 887VA-M and the BT FTTC product, I bypassed the BT modem and connected directly into the BT wall socket with the 887VA-M as it has a VDSL interface (just a config
tweek)
The config I was using was PPPOE which adds 8 bytes to the frame so on my
dialer0 I set the mtu to 1492, without the 'ip tcp adjust-mss 1452' I could not open web pages or run speed tests as my local host's mtu defaulted to their local setting (1500) and was dropped.
After adding the command to the LAN interface the router intercepts the SYN packet from the local host and changes the maximum segment size to the value stated before passing on to the remote host, the TCP 3 way handshake is then completed with the two hosts agreeing on the lowest of their 2 values, obviously it doesnt help if you have large UDP packets but there shouldn't be too many of those around anyway.
Using this command reduces the mtu size for TCP traffic flowing through the configured router but in your case I would be more interested in why you think you need it and where, do you think you have mtu bottlenecks in your network that are causing fragmentation and if so can you just fix those areas rather than adding this to lots of other routers.
Thanks
Sledge
On 11 February 2013 19:56, Eric A Louie <elouie at yahoo.com> wrote:
> I just put in this command on my upstream interfaces to help my mpls
> network pass traffic - that is, my effort to eliminate fragmentation
> in my backbone.
>
> Is anyone else using this method of "mtu control"? I need some
> support - my CEO is asking why I have to do this, and who else does
> it, and is it a common practice, etc, so I'm looking for evidence,
> more than just "The Cisco TAC told me to do it".
>
> thanks
>
> Much appreciated, Eric
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
------------------------------
Message: 7
Date: Tue, 12 Feb 2013 08:45:36 +0400
From: Denis F <fedodv at gmail.com>
To: Mike Glass <MGlass at lccountymt.gov>
Cc: cisco-nsp at PUCK.NETHER.NET
Subject: Re: [c-nsp] Cisco 6509 LACP
Message-ID: <529922D7-80F4-4345-AC4E-0D78DA3EAC6D at gmail.com>
Content-Type: text/plain; charset=us-ascii
Hi Mike.
I think the problem is that you trying to connect 10G port to 1G port, it is no LACP ...
On Feb 9, 2013, at 12:25 AM, Mike Glass <MGlass at lccountymt.gov> wrote:
> I hope somebody can help me, I am trying to configure a 6509 as the passive receiver from a Dell Force10 10Ge switch with 2 sfp to 2 gig ports on our 6509 switch, I see LACP is up on both sides but cannot pass traffic, I have only 2 vlans that will carry across the aggregate link from our vmware boxes, this is just a temp until I get a 10ge in our 6509 chassis.
>
> Attached is the config on both sides.
>
> Make sense?
>
> -------------------------------------------------------
> Cisco 6509 Config
> -------------------------------------------------------
>
> interface GigabitEthernet6/7
> switchport
> no ip address
> spanning-tree portfast
> switchport mode trunk
> channel-protocol lacp
> channel-group 1 mode passive
> !
> interface GigabitEthernet6/8
> switchport
> no ip address
> spanning-tree portfast
> switchport mode trunk
> channel-protocol lacp
> channel-group 1 mode passive
>
>
> interface Port-channel1
> description lacp Force10
> switchport
> switchport trunk encapsulation dot1q
> Switchport mode trunk
> no ip address
> logging event link-status
> --------------------------------------------------------
>
> ----------------------------------------------------------------------
> -------------
> show etherchannel detail
> ----------------------------------------------------------------------
> -------------
>
> Channel-group listing:
> -----------------------
>
> Group: 1
> ----------
> Group state = L2
> Ports: 2 Maxports = 16
> Port-channels: 1 Max Port-channels = 16
> Protocol: LACP
> Minimum Links: 0
> Ports in the group:
> -------------------
> Port: Gi6/7
> ------------
>
> Port state = Up Mstr In-Bndl
> Channel group = 1 Mode = Active Gcchange = -
> Port-channel = Po1 GC = - Pseudo port-channel = Po1
> Port index = 0 Load = 0x55 Protocol = LACP
>
> Flags: S - Device is sending Slow LACPDUs F - Device is sending fast LACPDUs.
> A - Device is in active mode. P - Device is in passive mode.
>
> Local information:
> LACP port Admin Oper Port Port
> Port Flags State Priority Key Key Number State
> Gi6/7 SA bndl 32768 0x1 0x1 0x607 0x3D
>
> Partner's information:
>
> Partner Partner LACP Partner Partner Partner Partner Partner
> Port Flags State Port Priority Admin Key Oper Key Port Number Port State
> Gi6/7 FA bndl 32768 0x0 0x1 0xA5 0x3F
>
> Age of the port in the current state: 0d:00h:08m:06s
>
> Port: Gi6/8
> ------------
>
> Port state = Up Mstr In-Bndl
> Channel group = 1 Mode = Active Gcchange = -
> Port-channel = Po1 GC = - Pseudo port-channel = Po1
> Port index = 1 Load = 0xAA Protocol = LACP
>
> Flags: S - Device is sending Slow LACPDUs F - Device is sending fast LACPDUs.
> A - Device is in active mode. P - Device is in passive mode.
>
> Local information:
> LACP port Admin Oper Port Port
> Port Flags State Priority Key Key Number State
> Gi6/8 SA bndl 32768 0x1 0x1 0x608 0x3D
>
> Partner's information:
>
> Partner Partner LACP Partner Partner Partner Partner Partner
> Port Flags State Port Priority Admin Key Oper Key Port Number Port State
> Gi6/8 FA bndl 32768 0x0 0x1 0xA4 0x3F
>
> Age of the port in the current state: 0d:00h:08m:06s
>
> Port-channels in the group:
> ----------------------
>
> Port-channel: Po1 (Primary Aggregator)
>
> ------------
>
> Age of the Port-channel = 1d:01h:24m:05s
> Logical slot/port = 14/1 Number of ports = 2
> Port state = Port-channel Ag-Inuse
> Protocol = LACP
>
> Ports in the Port-channel:
>
> Index Load Port EC state No of bits
> ------+------+------+------------------+-----------
> 0 55 Gi6/7 Active 4
> 1 AA Gi6/8 Active 4
> ----------------------------------------------------------------------
> ----------
>
>
>
> ----------------------------------------------------------------------
> ------------------------
> Force 10 Config
> ----------------------------------------------------------------------
> ------------------------
>
> interface TenGigabitEthernet 0/24
> description LAG to VMWARE servers
> no ip address
> !
> port-channel-protocol LACP
> port-channel 2 mode active
> no shutdown
> !
> interface TenGigabitEthernet 0/25
> description LAG to VMWARE servers
> no ip address
> !
> port-channel-protocol LACP
> port-channel 2 mode active
> no shutdown
>
>
> interface TenGigabitEthernet 0/34
> description LAG to Cisco 6905
> no ip address
> !
> port-channel-protocol LACP
> port-channel 1 mode active
> no shutdown
> !
> interface TenGigabitEthernet 0/35
> description LAG to Cisco 6905
> no ip address
> !
> port-channel-protocol LACP
> port-channel 1 mode active
> no shutdown
>
> interface Port-channel 1
> description LAG to Cisco 6905
> no ip address
> switchport
> no shutdown
> !
> interface Port-channel 2
> description LAG to VMWARE Servers
> no ip address
> switchport
> no shutdown
> !
> interface Vlan 1
> !
> interface Vlan 2
> name VMWARE Data VLAN
> no ip address
> tagged Port-channel 1-2
> no shutdown
> !
> interface Vlan 4
> no ip address
> tagged Port-channel 1-2
> no shutdown
> ---------------------------------------------------------
>
>
> --------------------------------------------------------------
> AIS-Prod-1#sh lacp 1
> --------------------------------------------------------------
>
> Port-channel 1 admin up, oper up, mode lacp
> Actor System ID: Priority 32768, Address 0001.e88b.52b8
> Partner System ID: Priority 32768, Address 00d0.0345.8800 Actor Admin
> Key 1, Oper Key 1, Partner Oper Key 1 LACP LAG 1 is an aggregatable
> link
>
> A - Active LACP, B - Passive LACP, C - Short Timeout, D - Long Timeout
> E - Aggregatable Link, F - Individual Link, G - IN_SYNC, H -
> OUT_OF_SYNC I - Collection enabled, J - Collection disabled, K -
> Distribution enabled L - Distribution disabled, M - Partner Defaulted,
> N - Partner Non-defaulted, O - Receiver is in expired state, P -
> Receiver is not in expired state
>
> Port Te 0/34 is enabled, LACP is enabled and mode is lacp
> Actor Admin: State ACEHJLMP Key 1 Priority 32768
> Oper: State ACEGIKNP Key 1 Priority 32768 Partner Admin:
> State BDFHJLMP Key 0 Priority 0
> Oper: State ADEGIKNP Key 1 Priority 32768
>
> Port Te 0/35 is enabled, LACP is enabled and mode is lacp
> Actor Admin: State ACEHJLMP Key 1 Priority 32768
> Oper: State ACEGIKNP Key 1 Priority 32768 Partner Admin:
> State BDFHJLMP Key 0 Priority 0
> Oper: State ADEGIKNP Key 1 Priority 32768
> ---------------------------------------------------------------
>
> ------------------------------------------------------------------
> AIS-Prod-1#sh lacp 2
> ------------------------------------------------------------------
> Port-channel 2 admin up, oper up, mode lacp
> Actor System ID: Priority 32768, Address 0001.e88b.52b8
> Partner System ID: Priority 65535, Address ac16.2d73.1cdc Actor Admin
> Key 2, Oper Key 2, Partner Oper Key 11 LACP LAG 2 is an aggregatable
> link
>
> A - Active LACP, B - Passive LACP, C - Short Timeout, D - Long Timeout
> E - Aggregatable Link, F - Individual Link, G - IN_SYNC, H -
> OUT_OF_SYNC I - Collection enabled, J - Collection disabled, K -
> Distribution enabled L - Distribution disabled, M - Partner Defaulted,
> N - Partner Non-defaulted, O - Receiver is in expired state, P -
> Receiver is not in expired state
>
> Port Te 0/24 is enabled, LACP is enabled and mode is lacp
> Actor Admin: State ACEHJLMP Key 2 Priority 32768
> Oper: State ACEGIKNP Key 2 Priority 32768 Partner Admin:
> State BDFHJLMP Key 0 Priority 0
> Oper: State ADEGIKNP Key 11 Priority 255
>
> Port Te 0/25 is enabled, LACP is enabled and mode is lacp
> Actor Admin: State ACEHJLMP Key 2 Priority 32768
> Oper: State ACEGIKNP Key 2 Priority 32768 Partner Admin:
> State BDFHJLMP Key 0 Priority 0
> Oper: State ADEGIKNP Key 11 Priority 255
>
>
> Thanks
> Mike
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at 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 at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
End of cisco-nsp Digest, Vol 123, Issue 34
******************************************
______________________________________________________________________
This email has been scanned by the brightsolid Email Security System. Powered by MessageLabs ______________________________________________________________________
______________________________________________________________________
"brightsolid" is used in this email to collectively mean brightsolid online innovation limited and its subsidiary companies brightsolid online publishing limited and brightsolid online technology limited.
findmypast.co.uk is a brand of brightsolid online publishing limited.
brightsolid online innovation limited, Gateway House, Luna Place, Dundee Technology Park, Dundee DD2 1TP. Registered in Scotland No. SC274983.
brightsolid online publishing limited, The Glebe, 6 Chapel Place, Rivington Street, London EC2A 3DQ. Registered in England No. 04369607.
brightsolid online technology limited, Gateway House, Luna Place, Dundee Technology Park, Dundee DD2 1TP. Registered in Scotland No. SC161678.
Email Disclaimer
This message is confidential and may contain privileged information. You should not disclose its contents to any other person. If you are not the intended recipient, please notify the sender named above immediately. It is expressly declared that this e-mail does not constitute nor form part of a contract or unilateral obligation. Opinions, conclusions and other information in this message that do not relate to the official business of brightsolid shall be understood as neither given nor endorsed by it.
______________________________________________________________________
This email has been scanned by the brightsolid Email Security System. Powered by MessageLabs
______________________________________________________________________
More information about the cisco-nsp
mailing list